Even 140 characters can speak volumes



  • Saw this the other day on Twitter:

    "@troyhunt Passwords are stored in a secure way. They’re only copied into plain text when pasted automatically into a password reminder mail."
    http://twitter.com/UKTesco/status/229542141012107265



  • It's like haiku, for stupidity.

    Passwords stored safely.
    Only decrypted for mail.
    Uh-oh—inside job.



  • So, (at best) they're using reversible encryption instead of a hashing-function? Or do you just automatically assume they're storing them in plain text anyway?

    As for emailing you your password, meh. Yes, in theory some man in the middle can grab a hold of a couple of passwords but what I'm really interested in is: How often does that actually happen? Each and every stoy in the news is about either losing USB sticks or having your database compromised, I hardly (if) ever hear anything about a mitm attacks in the wild.



  • Before hashing: password

    After: #p#a#s#s#w#o#r#d#


  • Discourse touched me in a no-no place

    @pnieuwkamp said:

    So, (at best) they're using reversible encryption instead of a hashing-function? Or do you just automatically assume they're storing them in plain text anyway?
    There's little discernible difference between the two.



  • One of the biggest WTFs is when I am forced to sign up to some site or other to post a comment, then they e-mail me back the password I have entered.

    They should, by law, enforce that if a site is going to e-mail you back your password, they at least warn you first.

    Ideally have a checkbox to disable the feature if they insist they can't remove it entirely.

    Insecurity questions are, of course, the other major WTF.

     

     



  • @pnieuwkamp said:

    So, (at best) they're using reversible encryption instead of a hashing-function? Or do you just automatically assume they're storing them in plain text anyway?

    As for emailing you your password, meh. Yes, in theory some man in the middle can grab a hold of a couple of passwords but what I'm really interested in is: How often does that actually happen? Each and every stoy in the news is about either losing USB sticks or having your database compromised, I hardly (if) ever hear anything about a mitm attacks in the wild.

    It's not the man-in-the-middle attack that I'm worried about. I'm more concerned about what will happen when their password database gets stolen. (I say "when", not "if", because any company that talks about "securely" storing passwords like this doesn't understand security).

    Once the password database is in hand, it's a simple matter to retrieve the passwords. They're likely storing them in plaintext or using some kind of rot13 obfuscation. If they are actually encrypted, then the attacker just has one additional step: retrieve the key - which is probably easy if they can get the password database. (This is the step that is prevented by storing passwords as a salted hash - even if the attacker got the database and all the source code for the website, they still can't get the passwords).

    At that point, the attacker has everyone's password. And how many people do you know who use multiple strong passwords? Most likely, the majority of passwords in this database are the same passwords used for bank accounts. Bonus points if the same database has name and address information.

    And that's why any company that emails your password in plaintext needs a security audit.



  • @Cbuttius said:

    They should, by law, enforce that if a site is going to e-mail you back your password, they at least warn you first.
     

    The company I work for offers clients the choice whether they want to use hashed passwords or reversable-encrypted passwords. We require a signed indemnity form before setting up the latter.

    Honestly I don't think we should even offer the option, but some people really like those password reminder e-mails.

     



  • @StephenCleary said:

    (This is the step that is prevented by storing passwords as a salted hash - even if the attacker got the database and all the source code for the website, they still can't get the passwords).
     

    orly? paraphrasing from a webapp I've been working on recently, specifically this is from a procedure that changed password/created new upon user registration:

    $this->db->insert(array('username' => $user, 'password' => sha1('saltwithweirdchars_+ľášíýčžť' + $password)));

    ...seems to me that in this case having the source code is the same as if site had no salting at all?



  • No it is slightly better, because you can not use normal rainbow tables. It's even better to combine salt with user id.


  • Trolleybus Mechanic

    @pnieuwkamp said:

    As for emailing you your password, meh.
     

    Meh?

    Attacker gets access to the DB with hashed, salted passwords:  Bad, but probably won't get anything good out of it.

    Attacker gets access to the DB with weakly encrypted passwords: Will quickly crack the easy ones, and eventually get more.

    Attacks gets access to the DB with weakly encrypted passwords AND a built-in function function to decrypt the passwords: Very bad.

    @Pseudocode said:


    UPDATE users SET email = REPLACE(email, '@', '+++') + '@CatchAllHackerDomain.com'

    FOR EACH $email IN (SELECT email FROM users)

         HttpRequest("FuckedSite.Com/ForgotPassword?email=$email").Send()


    You now have the email address and password for every user, and according to the Milholland Bureau of Pulling Statistics Out Of My Ass, 99.76% of those users will have the same password for their email account/every other forum they're on.



  • @SEMI-HYBRID code said:

    @StephenCleary said:

    (This is the step that is prevented by storing passwords as a salted hash - even if the attacker got the database and all the source code for the website, they still can't get the passwords).
     

    orly? paraphrasing from a webapp I've been working on recently, specifically this is from a procedure that changed password/created new upon user registration:

    $this->db->insert(array('username' => $user, 'password' => sha1('saltwithweirdchars_+ľášíýčžť' + $password)));

    ...seems to me that in this case having the source code is the same as if site had no salting at all?

    Not a salted hash then. Salts are supposed to be a) completely random, and b) bytes, not just characters (which don't encode every possible stream of bytes, even if you do use "weird chars").

    Since you then need to store the salt into the database (every password will have a unique salt), you can either base64encode them to store into a varchar, or just use a binary column.



  • @curtmack said:

    Not a salted hash then. Salts are supposed to be a) completely random, and b) bytes, not just characters (which don't encode every possible stream of bytes, even if you do use "weird chars").

    Since you then need to store the salt into the database (every password will have a unique salt), you can either base64encode them to store into a varchar, or just use a binary column.

    I'm a little confuzzled. How is this different from a hash?

    Will the unique and random salts be stored in a plain-text field for easy retrieval, or will we encrypt those as well?



  • Rainbows are made of pure water and sunlight. Pure water does not contain salt. Have you ever heard of a salty rainbow? No, of course not.



  • @Evilweasil said:

    Will the unique and random salts be stored in a plain-text field for easy retrieval, or will we encrypt those as well?

    Salts are used with the hashing function and alter its output. They are generally stored as plain text; the main point of salts is to screw over rainbow tables and make it hard for people to brute force their way in, which they accomplish simply by being used.
    How salts are used varies slightly, but the general idea is something like: hash(salt.concat(password)).



  • @Evilweasil said:

    @curtmack said:
    Not a salted hash then. Salts are supposed to be a) completely random, and b) bytes, not just characters (which don't encode every possible stream of bytes, even if you do use "weird chars").

    Since you then need to store the salt into the database (every password will have a unique salt), you can either base64encode them to store into a varchar, or just use a binary column.

    I'm a little confuzzled. How is this different from a hash?

    Will the unique and random salts be stored in a plain-text field for easy retrieval, or will we encrypt those as well?

     

    The salt prevents any kind of precomputed attack (e.g. rainbow tables), because it's impossible to account for the salt until you've seen it. Precomputed rainbow tables can invert hashes fairly quickly. Random inversions? Not so much.

    Edit: Also, what Salamander said above.

     



  • Salts also mean you can't determine whether two users have the same password or not, making frequency analysis of the password database useless.

    For example, User A is a complete moron and uses '12345' as his password. His salt is 45, so the hashed output hash(salt + password) is '194ndf8ASDFx'.

    User B is also a complete moron and also uses '12345' as his password. His salt is 673 so his hashed output hash(salt + password) is 'nnmffj347544'.

    Given that 12345 could statistically account for 30% of all passwords, this scheme makes it impossible to determine that 30% of the passwords are in fact identical and so could be '12345' with fair probability.

    This might actually be a case against using salted hashes, because it prevents IT from determining who the complete morons are so they can be forcefully removed from the system.



  • @StephenCleary said:

    Saw this the other day on [REDACTED]

    Quiet! if you speak about that 140-character-driven product you'll wake up the Lotus Notes Mercenary.



  •  @mott555 said:

    This might actually be a case against using salted hashes, because it prevents IT from determining who the complete morons are so they can be forcefully removed from the system.

    Solution:

    • Create a neural network that guesses weak passwords given the first two characters and the length of the password.
    • Feed it a few million sample passwords to train it.
    • Whenever a new user is created, before hashing the password, give the first two characters and length to the network
    • If one of the first three guesses the network outputs is the actual password, return error to the user: "Sorry, your password is too stupid."
    • Otherwise, create the user as normal.

    It's foolproof!!

     


  • Discourse touched me in a no-no place

    @SEMI-HYBRID code said:

    $this->db->insert(array('username' => $user, 'password' => sha1('saltwithweirdchars_+ľášíýčžť' + $password)));
    They use the same hash with all users? Little better, but still not right.


  • Discourse touched me in a no-no place

    @Evilweasil said:

    I'm a little confuzzled. How is this different from a hash?

    Will the unique and random salts be stored in a plain-text field for easy retrieval, or will we encrypt those as well?

    No salt and (say) SHA1 requires a bog-standard rainbow table to reverse the encryption.



    Common salt among all users requires a rainbow table keyed to the salt, or a list of common passwords encrypted with that single salt and see which passwords in the database match that encryption.



    A different salt for each user (which is stored in 'plaintext' in the database) means you need the equivalent of a rainbow table for each different salt. Or you need to run that list of common passwords for each different salt.



  • @Lorne Kates said:

    Meh?

     

    You misinterpret my 'meh' (at least, that is what you're quoting so I presume it is the target of your wrath) :) What I meant was: Is sending you your password (specifically!) THAT bad?

     



  • @pnieuwkamp said:

    @Lorne Kates said:

    Meh?

     

    You misinterpret my 'meh' (at least, that is what you're quoting so I presume it is the target of your wrath) :) What I meant was: Is sending you your password (specifically!) THAT bad?

     

    YES.

    Because it means they store it somewhere, and they really shouldn't.

     


  • Trolleybus Mechanic

    @pnieuwkamp said:

    @Lorne Kates said:

    Meh?

     

    You misinterpret my 'meh' (at least, that is what you're quoting so I presume it is the target of your wrath) :) What I meant was: Is sending you your password (specifically!) THAT bad?

     

     

    Yes. As above, because it means they're either storing it plaintext, or in a way that can be decrypted to plaintext (read: it might as well be plaintext).

    In this day and age, there's no reason a developer should chose to store passwords as plaintext. In all the systems I've worked on, password resets are done via a password reset link to the user's email. Except for one system where one client insisted on plaintext passwords, so they could send forgot password emails with the password, because they believed their users were too stupid to click a reset hyperlink.  Only after a fifteen minute lecture on information security, and having them agree (in writing) that they would be culpable for any data loss/violations that could incur from storing plaintext passwords, did I code that.

     



  • @Lorne Kates said:

    @pnieuwkamp said:

    @Lorne Kates said:

    Meh?

     

    You misinterpret my 'meh' (at least, that is what you're quoting so I presume it is the target of your wrath) :) What I meant was: Is sending you your password (specifically!) THAT bad?

     

     

    Yes. As above, because it means they're either storing it plaintext, or in a way that can be decrypted to plaintext (read: it might as well be plaintext).

    In this day and age, there's no reason a developer should chose to store passwords as plaintext. In all the systems I've worked on, password resets are done via a password reset link to the user's email. Except for one system where one client insisted on plaintext passwords, so they could send forgot password emails with the password, because they believed their users were too stupid to click a reset hyperlink.  Only after a fifteen minute lecture on information security, and having them agree (in writing) that they would be culpable for any data loss/violations that could incur from storing plaintext passwords, did I code that.

     

    There is ONE case for plain text passwords: configuration files. Imagine if Community Server asked for the database password on every pageload.



  • So much discussion about salts and nobody has yet mentioned using slower hashing functions (like bcrypt) instead of MD5 and SHA1?



  • @Ben L. said:

    There is ONE case for plain text passwords: configuration files. Imagine if Community Server asked for the database password on every pageload.

    Community server is asp .NET which means it should be using integrated security using the service/apppool account.



  • @Lorne Kates said:

    Yes. As above, because it means they're either storing it plaintext, or in a way that can be decrypted to plaintext (read: it might as well be plaintext).

    So, NO, there is nothing opposed to sending you your password via email, ok, thanks for clarifying that.

    Yes, I do get it is wrong to store the password in plain text, but that is not what I asked, I (specifically) asked for sending it via email. The way I see it, password reminder e-mails get sent at account creation or when changing your password and neither of those prevent you from storing the password 'The Right Way(TM)'. This does open you up to two mitm-attachs (once when creating or changing your password, can be avoided using SSL, and once when sending you the e-mail) but this doesn't seem to be a concern?


  • Discourse touched me in a no-no place

    @pnieuwkamp said:

    @Lorne Kates said:

    Yes. As above, because it means they're either storing it plaintext, or in a way that can be decrypted to plaintext (read: it might as well be plaintext).

    So, NO, there is nothing opposed to sending you your password via email, ok, thanks for clarifying that.

    Are you hard of reading or something? The thing opposing sending passwords via email is that it's wrong to be able to obtain that password in order to send it. And the only 'reason' to store passwords in plain-text is the desire to send such emails, ergo ,sending passwords via email is bad.

    Now email as a medium by which to obtain access to an account whereby you've forgotten the password is different (and is probably what you're trying desperately to grab at) and the solution to this is account-recovery tokens - one-time randomly generated URLs sent to the registered email address associated with the account, which lead the user to a page where they can change the password to one they hopefully won't forget this time.

  • Discourse touched me in a no-no place

    @Shinhan7 said:

    So much discussion about salts and nobody has yet mentioned using slower hashing functions (like bcrypt) instead of MD5 and SHA1?
    Not yet. Maybe someone will soon...



  • @t-bone said:

    @Ben L. said:
    There is ONE case for plain text passwords: configuration files. Imagine if Community Server asked for the database password on every pageload.

    Community server is asp .NET which means it should be using integrated security using the service/apppool account.

    I totally agree, there is possibly no other scenario. Now if the UN could just agree on how to call the Planetary Windows Domain so people could access ASP.Net applications from outside private organizations, things could move forward and ASP.Net could take over internet, smoking java and php.



  • @Shinhan7 said:

    So much discussion about salts and nobody has yet mentioned using slower hashing functions (like bcrypt) instead of MD5 and SHA1?

    Would bcrypt still be slower if everybody had multicore CPUs?



  • @Speakerphone Dude said:

    @Shinhan7 said:
    So much discussion about salts and nobody has yet mentioned using slower hashing functions (like bcrypt) instead of MD5 and SHA1?

    Would bcrypt still be slower if everybody had multicore CPUs?

    Assuming you can't parallelize rounds, yes I think it would.



  • @pnieuwkamp said:

    So, NO, there is nothing opposed to sending you your password via email, ok, thanks for clarifying that.

    Yes, I do get it is wrong to store the password in plain text, but that is not what I asked, I (specifically) asked for sending it via email. The way I see it, password reminder e-mails get sent at account creation or when changing your password and neither of those prevent you from storing the password 'The Right Way(TM)'. This does open you up to two mitm-attachs (once when creating or changing your password, can be avoided using SSL, and once when sending you the e-mail) but this doesn't seem to be a concern?

    The problem with them being able of sending someone their password is two-fold:

    1. If they can retrieve someone's password, their password is vulnerable to inside-job attacks.
      Does it make a difference, since an inside man can already do much more damage even without knowing users' passwords?
      Yes it does, because now that the attacker knows people's password and other data, he may be able to do damage elsewhere, because in general people recycle their passwords.
    2. If they send you your password, your password can now be retrieved by anyone with access to your email account. So a hacked account will turn into several hacked accounts very quickly.

     



  • @PJH said:

    Are you hard of reading or something?
    I could ask you the same. Read the second paragraph please. Or read it again, but I doubt you did that already or you would have seen I covered storing passwords in plain text already.@PJH said:
    (and is probably what you're trying desperately to grab at)
    Again, please read the second paragraph, more specifically the second sentence there.
    @Zecc said:
    The problem with them being able of sending someone their password is two-fold:

    1) Then, if you must (note that I don't necessarily agree, just trying to learn something), only send them on account creation or after the user changes their password. Like: Receive request, send mail, salt+hash password, store password...
    2)Ah, but then it is the user getting hacked and the problem lies solely on the receiving end. At least the user is free to delete the received email :)


  • ♿ (Parody)

    @pnieuwkamp said:

    ...

    4/10. Your trolling needs serious work to be more interesting, but you are getting results. You might try throwing in some operating system or Lotus Notes red herrings.


  • Discourse touched me in a no-no place

    @pnieuwkamp said:

    1) Then, if you must (note that I don't necessarily agree, just trying to learn something), only send them on account creation or after the user changes their password. Like: Receive request, send mail, salt+hash password, store password...
    Why? Why send the password? There's no need to send the password.[1]
    2)Ah, but then it is the user getting hacked and the problem lies solely on the receiving end. At least the user is free to delete the received email :)
    Why create more effort, when sending the passwords in the first place is not required?



    What is this fetish you seem to have about requiring/wanting passwords to be sent via email to all and sundry, when there is no discernible benefit[1] and lots of downsides[2] from doing so? Apart from trying to troll this forum about passwords of course.



    [1] What is the point in sending an email with the password to the newly created account/newly changed password? Do people using your software have the memory spans of goldfish?

    [2] People forgetting to delete said emails leaving them in history for MOTAS/kids/crackers to find if they're unwary. People putting wrong email addresses in. Hanging around in server logs. Programmers who think "well if I send them at account creation and on password changes, people are going to want reminders. I know what, I'll store the passwords rather than encrypting them..."





    Instead of demanding answers to your MiTM question (of which I've given plausible examples of in [2] above,) how about you give us a damn good reason for sending passwords in plaintext over an unsecure transport protocol to begin with?



  • @PJH said:

    @Shinhan7 said:
    So much discussion about salts and nobody has yet mentioned using slower hashing functions (like bcrypt) instead of MD5 and SHA1?
    Not yet. Maybe someone will soon...

    I wonder if Shinhan7 would mention something like that.



  • I don't know why someone would send me the password in an email, the same password I just entered on the website not 5 minutes ago. However, that is not the discussion, and I really don't know why you are attacking me about it? I was asking for reasons not to send it, I never advocated to DO send it. I never[1] told anyone here how I feel about those emails... The assumption about my feelings toward those is just that: an assumption, an irrelevant one at that. Neither opponents nor proponents can change the rational arguments, they just weigh them differently.

    Now that we have cleared the grounds of my perceived troll (Trolling is not my intention. Your opinion about that may vary of course) and hopefully your anger about it we can get to the case: Reasons not to send it.

    - Your users generally don't have memory spans of goldfish (as a sysadmin I tend to disagree though ;) )
    - Compromised email stores (webmail, PST, Thunderbird, whatever)
    - Wrong email addresses entered
    - Server logs
    - Back to plain-text server-side storage...

    Thanks for your input :)

    [1] Well, maybe in another thread? Contrary to your assumption, I'm an opponent as well.



  • ... It's like you're crowsourcing an explanation you need to give to your boss.


  • BINNED

    @pnieuwkamp said:

    I really don't know why you are attacking me about it?
    Because asking a question and subsequently arguing with all of the answers given is simply the most endearing thing ever.



  • Oh, pardon. I thought that was what forums were about; sharing knowledge and having discussions...

    Ok, nothing here to see, move along.... Oh, look over there, Snoofle's posted another one!



  • @PedanticCurmudgeon said:

    @pnieuwkamp said:
    I really don't know why you are attacking me about it?
    Because asking a question and subsequently arguing with all of the answers given is simply the most endearing thing ever.
     

    IS NOT.



  • @PedanticCurmudgeon said:

    @pnieuwkamp said:
    I really don't know why you are attacking me about it?
    Because asking a question and subsequently arguing with all of the answers given is simply the most endearing thing ever.

    This could be construed as meta-attacking him


  • BINNED

    @Speakerphone Dude said:

    @PedanticCurmudgeon said:
    @pnieuwkamp said:
    I really don't know why you are attacking me about it?
    Because asking a question and subsequently arguing with all of the answers given is simply the most endearing thing ever.

    This could be construed as meta-attacking him

    Yes, but given his response: @pnieuwkamp said:
    Oh, pardon. I thought that was what forums were about; sharing knowledge and having discussions...
    I'm OK with joining the horde of attackers. In my opinion, the difference between trolls and the willfully ignorant isn't worth worrying about.



  • @PedanticCurmudgeon said:

    @pnieuwkamp said:
    Oh, pardon. I thought that was what forums were about; sharing knowledge and having discussions...
    I'm OK with joining the horde of attackers. In my opinion, the difference between trolls and the willfully ignorant isn't worth worrying about.

    Willful ignorance is über-trollism. And by joining the attackers you become an über-enabler. Shame on you and the next three generations in your family.


  • BINNED

    @Speakerphone Dude said:


    Willful ignorance is über-trollism. And by joining the attackers you become an über-enabler. Shame on you and the next three generations in your family.

    Amateur. Everyone knows the elite trolls start with a seemingly innocent statement that ignites a pages-long flamewar which continues long after the troll has stopped posting.


  • @Shinhan7 said:

    So much discussion about salts and nobody has yet mentioned using slower hashing functions (like bcrypt) instead of MD5 and SHA1?

    function crypt_password_sooper_secure(password)

    {

        sleep(500);

        return crypt_password(password);

    }



  • @ekolis said:

    @Shinhan7 said:
    So much discussion about salts and nobody has yet mentioned using slower hashing functions (like bcrypt) instead of MD5 and SHA1?

    function crypt_password_sooper_secure(password)

    {

        sleep(500);

        return crypt_password(password);

    }

    I can't see how this could possibly go wrong.


  • Considered Harmful

    @Ben L. said:

    @ekolis said:
    @Shinhan7 said:
    So much discussion about salts and nobody has yet mentioned using slower hashing functions (like bcrypt) instead of MD5 and SHA1?

    function crypt_password_sooper_secure(password)

    {

        sleep(500);

        return crypt_password(password);

    }

    I can't see how this could possibly go wrong.

    I cleverly reverse-engineered your sooper secure algorithm in order to optimize away the inefficiency:

    function crypt_password_sooper_secure_optimized( password ) {
        try {
            sleep( 100 );
        } catch( ex ) { }
        try {
            sleep( 100 );
        } catch( ex ) { }
        try {
            sleep( 100 );
        } catch( ex ) { }
        try {
            sleep( 100 );
        } catch( ex ) { }
        return crypt_password( password );
    }
    

Log in to reply