• that other guy (unregistered)

    404 Frist not found

  • NOT Aaron K. (unregistered)

    There's a bug in your CMS - the picture and the caption don't match. :P

    I submitted the picture and it has nothing to do with advertising. It's a message on the german AUDI website.

  • Little Bobby Tables (unregistered)

    However much you nag people, and badger them into doing what you want them to do (for whatever specious political reasons), they can't be guaranteed to do that thing if they don't want to.

    This applies equally to getting people to go to church, getting people not to walk on the cracks in the pavement (US readers: "sidewalk"), and getting women to adopt courses in STEM subjects. Even in the exciting modern hi-tec world of scientific wizardry, it appears that the height of ambition for a significant percentage of young girls is to be a model.

  • Ben (unregistered)

    A password manager is able, at some point, to compare two passwords for equality? Hmm...

  • Ben (unregistered) in reply to Ben

    Now that I think about it maybe that isn't a bad thing lmao

  • Brian Boorman (google) in reply to Ben
    A password manager is able, at some point, to compare two passwords for equality?

    Why wouldn't it? The passwords have to be stored with a 2-way function, since it needs to be able to decrypt the password so you can input it into the other website you want to log into.

  • (nodebb) in reply to Little Bobby Tables

    Americans are quite familiar with the word "pavement", it's used almost as often as "sidewalk".

  • (nodebb) in reply to Brian Boorman

    Or, the password can be stored with a 1-way function, and the site can compare that value with the same 1-way function encryption of whatever you put in.

    But it is possible that whether it's a 1-way or a 2-way function, the encryption algorithm might come up with the same value for two different passwords. If this is the case, it's not a question of whether it is or should be 1-way encryption or 2-way encryption. It's a question of why is it cheap encryption? Probably home-grown because why would anyone use published libraries full of functions like Math, Date/Time, or Encryption when they can just write their own?

  • (nodebb) in reply to Brian Boorman

    No, not exactly. Only the hash is stored, and the hash of the password entered is compared to the hash of the one stored.

    But that shouldn't be the end of it. Even the hash shouldn't be stored. The hashes should be salted, and only the result stored, so that cracking one password doesn't allow the attacker to crack all of the passwords.

    Addendum 2018-09-07 10:09: So the fact that they're able to compare one password against someone else's password (even undefined) shows that they're doing it wrong.

  • (nodebb) in reply to tharpa

    ^^^^^ This! ^^^^^

  • Phlip (unregistered) in reply to Bananafish

    OK, so you enter your password into, again, your password manager, and it mangles it with a one-way hash and stores that. Neat.

    So now you visit the website that you've stored your password for, and your password manager wants to automatically log you in. So it takes your salted hash and does... what, exactly? What is the password manager going to do at this point to turn your hashed password into something it can use to log into some arbitrary website?

    I'm interested to hear your plan here.

  • Cole (unregistered) in reply to tharpa

    I agree that for a website, you want to have salted and hashed passwords. This isn't a website he's talking about. It's a password manager. It needs to be 2-way because if it's not, a couple things will happen

    • The user won't be able to see password's they've stored. This becomes an issue when they, for example, need to copy and paste their password into a website.
    • Some (poorly designed) websites have length limits on passwords. If a salt/hash function was used as a password, these will all be a standard, very long length, and thus be useless for these kind of sites.

    In this case, it's not checking if 2 user's hashed passwords are the same - it's checking if a user's 2 (decrypted) passwords are the same.

  • (nodebb) in reply to tharpa

    I'm guessing undefined isn't another user but a site, and James tried to use the password that he used on that site as his master password.

    Actually, I'm not guessing. I'm summarising my understanding of the message.

  • Ducky (unregistered) in reply to tharpa

    That's true for websites storing its own users' passwords. Lastpass is a password manager, though -- it helps you remember your passwords on other sites so you don't have to. Thus, in order to enter the passwords you need to get into other sites for you, it needs to know, exactly, your user name and password for that site.

    And this message is for when you're resetting your master password, So it knows the password you just entered + all the other ones it knew about.

  • Lew (unregistered) in reply to Brian Boorman

    No, passwords do not have to be stored with a two-way function.

    If you store only the encrypted password, then you can still determine whether or not a value entered in the password field matches the original, unencrypted password by encrypting the entered password, and comparing it to the stored (encrypted) value. If the two encrypted values match, then the unencrypted values also match.

  • Works as coded (unregistered)

    That's an unusually tall woman stick figure.

  • Wizofaus (unregistered) in reply to tharpa

    Password managers like LastPass have to use 2-way cryptography because they work by sending the actual password to whatever sites you use them for. But they certainly shouldn't be able to know the plain text of two different user's passwords at any time

  • Decius (unregistered)

    Lastpass keeps track of which other sites you have asked it to suppress notification if their website password matches the master password? Do they keep that list of vulnerabilities encrypted as strongly as it encrypts your password, or does it store that list along with your other non-password user data in a form that doesn't require keeping the keys to your secure information in server memory?

    Either way, it's a huge security flaw. Slightly larger than having an additional single point of failure for all your passwords.

  • WTFGuy (unregistered)

    @Decius ...

    Given the current reality of:
    Millions of websites demanding plain text user IDs and passwords keystroked into browser-based (or equivalent app-based) interfaces, AND
    Most such sites being hackable, AND
    Each individual human having dozens to hundreds of such userids and passwords, AND
    Each individual human being really bad at remembering large quantities of long arbitrary strings of characters THEN

    What exactly do you propose as the least bad way to square this n-dimensional irregular polyhedron?

    (clicks [Submit] hoping to have correctly appeased the very WTF-ly gods of Markdown.)

  • Decius (unregistered) in reply to WTFGuy

    1- have a two-step security system. Software running in the user’s browser or system takes the username and password, sends a salted hash of the password to the PM, along with username and 2fa token (who treats that hash as a password, salting and hashing it to authenticate). The the PM sends an encrypted package of passwords to the program the user is running, and that program decrypts the password. If a change is made, the updated passwords file is encrypted and uploaded to the server.

    Or just keep your passwords in a password encrypted.zip file in your Dropbox. It’s not quite as convenient but it’s less insecure than LastPass keeping track of which sites have login credentials for you equal to the data that they will release all of your passwords to.

  • Wow (unregistered) in reply to Little Bobby Tables

    Man, what's wrong with you? You need to have some serious issues, if you get so worked up from a single picture...

  • Your Name (unregistered)

    Software running in the user’s browser keep your passwords in a password encrypted.zip file in your Dropbox

    Sure. What could possibly go wrong?

    Use a fscking password manager which is FOSS and runs on your local hardware. It is not that hard.

  • Brian Boorman (google) in reply to tharpa

    Your lack of understanding of what we are even discussing is so very apparent.

    Please tell me how the password manager tells random website - "No, I'm not giving you the user's real password, but a hash of it that's been salted with some value you don't know about, and I expect you to accept it and log the user in."

  • Brian Boorman (google) in reply to Lew

    Lew - and then how does the password manager give the plaintext password to the website the user is trying to log into if it's only stored as a 1-way function?

  • (nodebb)

    Oh, the password must exceed 10 characters. Wow! Somewhen ago, the hospital information system "medico//s" By Siemens Medical Solutions allowed for passwords longer than 12 characters, but ignored all characters beyond 12...

  • nostalgic (unregistered)

    This is why SRP should have taken off in the 90's, so plaintext passwords wouldn't be sent to the server. We could have built it into the browser so not even javascript could get at the passwords. But nooo, we can't have nice things.

  • (nodebb) in reply to BernieTheBernie

    That reminds me of someone who shoulder-surfed the first few letters of someone's password and found that there were very few words that started with those letters, and those words were all longer than that particular system's silent password truncation length, and so although the other person thought they were being clever by combining two words they had actually ended up with a less secure password.

Leave a comment on “An Unfortunate Sign”

Log In or post as a guest

Replying to comment #499289:

« Return to Article