4 ms·

I don't get why they used SHA-1. I mean, LivingSocial has been sending people to speak and attend a lot of developer conferences. They hire a lot of bright peop

by swanson 13y ago

I don't get why they used SHA-1. I mean, LivingSocial has been sending people to speak and attend a lot of developer conferences. They hire a lot of bright people. Did none of the Rails devs raise an alert of like "Uhh hey guys, why don't we use Rails-community standard bcrypt?". I suppose it could be corporate bureaucracy or something, but it seems weird that a company with at least 30+ developers (based on public members on the github org) no one would point out that this is a Bad Idea.

cheald 13y ago
If I had to guess - it was done long ago when SHA-1 was what you used because it wasn't MD5, and nobody thought to change it since it was working.
- swanson 13y ago
  Maybe - but you would think that a company with "Tech Leads" would think to check that kind of stuff. Or some new hire would come in and ask innocently "Hey what do we use for password hashing". I find it pretty hard to believe that no one would ever poke around the User model in a Rails app :)
- lawnchair_larry 13y ago
  There has really never been a time where SHA1 was appropriate.
  - cheald 13y ago
    Sure there was - before the debut of high-powered GPUs. Try cracking SHA1-hashed passwords on CPUs - even modern ones - and let me know how far that gets you. By comparison, today's bcrypt passwords at today's work factors are tomorrow's ASIC snacks. Doesn't mean that bcrypt at reasonable work factors are wrong today.
rmrfrmrf 13y ago
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 13y 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.
  - 13y ago

by swanson 13y ago

cheald 13y ago

If I had to guess - it was done long ago when SHA-1 was what you used because it wasn't MD5, and nobody thought to change it since it was working.

swanson 13y ago
Maybe - but you would think that a company with "Tech Leads" would think to check that kind of stuff. Or some new hire would come in and ask innocently "Hey what do we use for password hashing". I find it pretty hard to believe that no one would ever poke around the User model in a Rails app :)
lawnchair_larry 13y ago
There has really never been a time where SHA1 was appropriate.
- cheald 13y ago
  Sure there was - before the debut of high-powered GPUs. Try cracking SHA1-hashed passwords on CPUs - even modern ones - and let me know how far that gets you. By comparison, today's bcrypt passwords at today's work factors are tomorrow's ASIC snacks. Doesn't mean that bcrypt at reasonable work factors are wrong today.

rmrfrmrf 13y ago

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 13y 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.
- 13y ago