Another non-user-facing change. Password hashes are stored in SQL now. Hopefully you won't notice any changes. If you notice any login bugs, make a case or a post tagged #bugski.
But this is a huge deal behind the scenes. It lets us add logging in to the API (which is still down, I know, we're working on it). Which in turn lets us write API endpoints for private data, like mail.
Which is the very next thing on my list.
As always, questions welcome.
If you're curious how passwords are stored in the Hubski app: The logic comes from the original Hacker News source Hubski was forked from. New passwords, from new user creation or password changes, have a unique salt generated. The password is then concatenated with the salt, and hashed with Sha512. The username, salt, hash, and 'Sha512' are inserted into the database (previously, it was a s-expression file). Passwords themselves are never stored. The text 'Sha512' is inserted, because the Arc app formerly used Sha1, which is less secure. But, because passwords themselves are never stored, we can't simply generate a Sha512, because we don't have the original password, unless we required all users with old passwords to make new ones. The solution is to Sha512 the Sha1. So, the database stores the hash type, Sha1, Sha512, or Sha1_Sha512. If a user tries to log in and their password is stored as Sha1, we let them log in, and then hash the Sha1 hash with Sha512, and store the result with 'Sha1_Sha512' in the database. If a password is stored as Sha512, we hash the password+salt with Sha512 and compare it to the hash in the database. If a password is stored as Sha1_Sha512, we hash the password+salt with Sha1, then hash the result with Sha512, then compare that to the hash in the database. Awkward, but it works. If you're not familiar with security programming: the point of all this is to prevent someone who breaks into the Hubski server from getting your passwords. If we stored passwords themselves, and someone hacked the server, they'd have all your passwords. These hashes are not reversible. So, if someone hacks the Hubski server and steals the database, the only way to get users' passwords would be to compare every hash to every possible combination of characters—mathematically impossible. (The salt prevents Rainbow Table attacks [pre-computing common passwords].) Eventually this will all be open-sourced.
I would love an open-behind-the-scenes-source Hubski! Just found Pyski, wondered if I should fork it, but then I saw that the API prototype is down (hasn't been here for about a year or so); so when the API is up server-side, I'm ready to help with the client-side bindings :) Again all the respect for your work! Anyway, as a hobbyist cryptographer, may I ask if there is a plan/option to upgrade to SHA3 (Keccak) - I would like to see that feature, although I don't know much about Arc programming? Nevertheless, SHA2 is still treated as secure but with the slow rise of quantum giants, it wouldn't be anymore impossible to break it. Although it's a rather silly, paranoid idea, I know.
Aren't the old passwords vulnerable as long as the Sha1 value is still around? Does it get deleted when converted to 512? Also, any reason you didn't switch to something like bcrypt, scrypt, or PBKDF2? Modern best practices generally recommend one of those, although for a site like Hubski Sha512 is probably good enough with proper salting.
Yes, the old Sha1 is deleted on conversion. Time. I only converted the data, I wasn't in the hashing code. At some point we'll upgrade the encoding to bcrypt or a successor. Time is always against us. We all have full time jobs, and my life in particular has been incredibly busy for the last nine months. Once all the code is converted to Racket, this kind of thing will be much faster. Every Arc change requires painstakingly figuring out what each poorly-documented function and macro does.Aren't the old passwords vulnerable as long as the Sha1 value is still around? Does it get deleted when converted to 512?
any reason you didn't switch to something like bcrypt, scrypt, or PBKDF2?