News for hackers. Stuff that matters.

A comment on Important Kickstarter Security Notice. Parent comment

Re:Important Kickstarter Security Notice by akerl_ on Saturday February 15, 2014 @05:00PM (#7245550)
In theory you could, but then the code has to support both login procedures forever (hashing once with scrypt or hashing with SHA1 and then scrypt). That's why, if it were me, I'd likely set it up so if someone with a SHA1-hashed password logged in, it first did the SHA1 comparison, and if that succeeded the login process dropped an scrypted version into the DB.
[ Parent | on HN ]
Re:Important Kickstarter Security Notice by cmircea on Saturday February 15, 2014 @05:28PM (#7245710)
You could just always do a hash using SHA1 then feed that to bcrypt. This way you only have one code path, for all users.
[ Parent | on HN ]
Re:Important Kickstarter Security Notice by akerl_ on Saturday February 15, 2014 @05:31PM (#7245729)
Except that for some people, you only have a SHA1 hash, and for others, you only have an scrypt hash. Since they (I hope) weren't storing the plaintext (pre-hash) passwords alongside the hashed versions, the only time they can change the initial hashing mechanism is when passwords are provided to them during a password change or user login.
[ Parent | on HN ]
Re:Important Kickstarter Security Notice by ErrantX on Saturday February 15, 2014 @05:47PM (#7245798)
Hash all the sha1 passwords with scrypt. Hash all new passwords with sha1 then scrypt.

Your new hash mechanism is sha1 then scrypt.

There is no excuse to do otherwise :)

[ Parent | on HN ]