3 ms·

I could think of a few reasons: 1. user management is a pretty trivial thing to code and one of the first things you do when you set up any site. It could have

I could think of a few reasons: 1. user management is a pretty trivial thing to code and one of the first things you do when you set up any site. It could have been a simple oversight before a rushed launch. 2. Playing off of 1), once you have any users in a database using a particular system, you have to go through a bit of a process to convert people over (you can't convert from one hashing algo to another yourself since you don't have the original passwords). That involves creating a concurrent password table, creating login hooks that force the user to upgrade their password on login (especially a pain if they're using native apps -- i'm not sure if they are), etc. Making sure that 50 million users migrate over without a hitch is a potentially site-breaking undertaking that could have serious impact on the site's success. Given the rocky climate LS currently faces, you'd have to have nerves of steel to lead a n initiative like that. 3. Depending on how LivingSocial has their code management structure set up, there may only be a few devs who actually have access to the user login system (you really don't want an intern or freelancer to be able to modify those). Given that the same devs who have that access probably have more immediate issues to deal with day-to-day, something like the current hashing algorithm might not be on the top of their priority list. Not that any of these are very good excuses, but I could see how it could happen.

rurounijones 14y ago
I do not agree with your #2 regarding making users re-create their password. Assuming you haven't been hacked yet the old password is still secret. Therefore you modify your login system so that when the user next logs in: * Check password against old hash * If old hash exists and matches user's password then re-hash the password using new hash and save new hash in new field * If old hash does not exist then just check against new hash only. Run the above code for X time (X being the time it takes Y% (Defined by company) of your users to login at least once. After X time THEN you start forcing the remainder to switch over. Done properly for the vast majority of your users should not even know you have changed anything. [EDIT] - With some extra code you could probably avoid having to create a new field for the new hash by just checking against one hash field using old algorithm then new algorithm. This would avoid a potentially costly DB migration.
- jaf656s 14y ago
  It's much safer to just hash twice: the first time using your old hash function and again using a secure hash. Then to migrate you only have to update all your customer's password hashes in place. Additionally, if you lose your database, you don't lose all the old, weak password hashes.
  - rmrfrmrf 14y ago
    Ooo, I hadn't thought of that! For some reason, I had it in my mind that some insecure hashing algorithm as the base would result in an insecure resulting hash, but of course that all goes out the window when your whole password table is out in the open. I'm glad you mentioned "safer", because for some reason rurounijones's approach made me nervous, but I couldn't quite put my finger on it. Here's some more discussion on the issue: http://crypto.stackexchange.com/questions/2945/is-this-password-migration-strategy-secure http://crypto.stackexchange.com/questions/2945/is-this-passw... (I found that from here: http://stackoverflow.com/questions/3955223/password-hashing-how-to-upgrade http://stackoverflow.com/questions/3955223/password-hashing-...).
sk5t 14y ago
User management is not so trivial that the repercussions of doing it wrong are trivial (exactly as we're seeing now). Someone with a bit of experience in this field would know to include the hash algorithm in the stored data when processing a password set/change/reset. For example, good old Netscape LDAP server stored passwords in the general form "{ssha}xxxxxx", "{crypt}xxxxxx", or "{plain}xxxxx". This allows for easy comparison as users login, as well as for gradual upgrade to stronger algorithms in the future when accepting changes--one could extend with with "{bcrypt}", "{pbkdf2-10k}", etc., etc. Having only a small number of trusted ignoramuses working on the code is a pretty lame defense. Honestly this stuff is in the news all the time. How could nobody at such a massive site raise the question, "if our database is compromised, will we be exposed as careless oafs?"
- rmrfrmrf 14y ago
  I agree with you completely. I was hoping people would take my comment more as important lessons than excuses. 1) Always review the code for sensitive data before allowing it to go live (especially by someone well-versed in security). 2) Have a plan of attack in place for security upgrades so that they're not quite so painful. 3) Despite day-to-day responsibilities, there need to be regular reviews of security practices by management.

rurounijones 14y ago

I do not agree with your #2 regarding making users re-create their password. Assuming you haven't been hacked yet the old password is still secret. Therefore you modify your login system so that when the user next logs in: * Check password against old hash * If old hash exists and matches user's password then re-hash the password using new hash and save new hash in new field * If old hash does not exist then just check against new hash only. Run the above code for X time (X being the time it takes Y% (Defined by company) of your users to login at least once. After X time THEN you start forcing the remainder to switch over. Done properly for the vast majority of your users should not even know you have changed anything. [EDIT] - With some extra code you could probably avoid having to create a new field for the new hash by just checking against one hash field using old algorithm then new algorithm. This would avoid a potentially costly DB migration.

jaf656s 14y ago
It's much safer to just hash twice: the first time using your old hash function and again using a secure hash. Then to migrate you only have to update all your customer's password hashes in place. Additionally, if you lose your database, you don't lose all the old, weak password hashes.
- rmrfrmrf 14y ago
  Ooo, I hadn't thought of that! For some reason, I had it in my mind that some insecure hashing algorithm as the base would result in an insecure resulting hash, but of course that all goes out the window when your whole password table is out in the open. I'm glad you mentioned "safer", because for some reason rurounijones's approach made me nervous, but I couldn't quite put my finger on it. Here's some more discussion on the issue: http://crypto.stackexchange.com/questions/2945/is-this-password-migration-strategy-secure http://crypto.stackexchange.com/questions/2945/is-this-passw... (I found that from here: http://stackoverflow.com/questions/3955223/password-hashing-how-to-upgrade http://stackoverflow.com/questions/3955223/password-hashing-...).

sk5t 14y ago

User management is not so trivial that the repercussions of doing it wrong are trivial (exactly as we're seeing now). Someone with a bit of experience in this field would know to include the hash algorithm in the stored data when processing a password set/change/reset. For example, good old Netscape LDAP server stored passwords in the general form "{ssha}xxxxxx", "{crypt}xxxxxx", or "{plain}xxxxx". This allows for easy comparison as users login, as well as for gradual upgrade to stronger algorithms in the future when accepting changes--one could extend with with "{bcrypt}", "{pbkdf2-10k}", etc., etc. Having only a small number of trusted ignoramuses working on the code is a pretty lame defense. Honestly this stuff is in the news all the time. How could nobody at such a massive site raise the question, "if our database is compromised, will we be exposed as careless oafs?"

rmrfrmrf 14y ago
I agree with you completely. I was hoping people would take my comment more as important lessons than excuses. 1) Always review the code for sensitive data before allowing it to go live (especially by someone well-versed in security). 2) Have a plan of attack in place for security upgrades so that they're not quite so painful. 3) Despite day-to-day responsibilities, there need to be regular reviews of security practices by management.