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.