5 ms·
Hashed and salted means almost nothing. It could be one invocation of SHA-256 (or SHA512, or SHA-3) with a salt, which is fairly meaningless unless the key/pass
by thirsteh 14y ago
Hashed and salted means almost nothing. It could be one invocation of SHA-256 (or SHA512, or SHA-3) with a salt, which is fairly meaningless unless the key/password contains a large amount of entropy (almost no passwords do.)
It's much more important to know what algorithm they were actually using, e.g. scrypt, bcrypt or PBKDF2, and what the settings/work factors/iteration counts for them are/were. If a company is reluctant to disclose that, they're likely using something that's highly vulnerable to parallelization/efficient brute force cracking, regardless of what kind or size of salt was used.
- StavrosK 14y agoI like how everybody is optimistic. It could have been MD5!
- integraton 14y agoSince, AFAIK, it's built on Rails, that's unlikely. However, it's possible that it's SHA-1 since popular Rails auth solutions used that by default at the time the company was founded (2007), assuming that's what they started with and never switched from.
- ukd1 14y agoI'd be very surprised if Rails didn't support upgrading the hash over time - anyone know if it does with has_secure_password?
- integraton 14y agoPrior to 3.1, Rails didn't have built-in support for password hashing or user auth beyond http auth, so it was handled by libraries (like devise or authlogic), generated code (such as with restful-auth, which was popular in 2007), or custom code. I don't think it's very common for legacy codebases to be migrated to has_secure_password, but it's not impossible. There is not built in migration for has_secure_password, AFAIK. LivingSocial is a big enough company I wouldn't be surprised if their authentication code was all or mostly custom.