More information on salted and hashed passwords

In our email to Animoto customers we attempted to make our explanation of hashed and salted passwords more accessible to general users, but for those that would like a more in depth understanding of Animoto password management, below is a break down of what we do and why. There is no "key" in our password security procedures and no "encryption" per se.
Security best-practice is to never store passwords in a way that *anybody* can see them. Animoto follows this practice by using a standard password hashing scheme. In this context, "hashing" refers to an operation that transforms some input (here a password) into text that appears totally random. Every time the same input is supplied, the hash operation yields the same output. Crucially, this operation is "one way" - given the random-looking output it is virtually impossible to recover the input (the password) that was hashed to create it. The best-practice is to only store the hashed password (the random-looking text). When a user logs in, we hash the password and check it against the previously-stored hash that we computed when the user created their account. This means we never store our users' passwords but we can check if a user knows their own password.
But there is a weakness to this method that we attempt to mitigate. The problem comes down to users selecting weak passwords to begin with. If a hacker knows the hash function used by our system (and there are only a few that are commonly used), the hacker can simply try all common words, running each through the hash function and seeing if the result matches the hashed data they (hypothetically) stole. If there's a match, the hacker knows the password. The best defense against this is to use a strong password with no common words. But there's something else that Animoto does to help: when we initially hash the password we "salt" the password with some extra data. This means that the input of the hash function is more complex than just password and it means our hash input won't be in any dictionary or common list of passwords. Now in order to execute the attack, the hacker has to know three things in order to try and "brute force" guessing the password of a user: the extra "salt" data, the method by which we combine the salt with the password, and the hashed output. The "salt" is the part that was generically referred to as a "key" in our initial explanation. It's also worth noting that every user has a unique "salt", there is no "master salt".
So, given all this, it is unlikely that any passwords are recoverable even if hashed password data was accessed. All the same, updating your passwords and taking the time to use strong passwords and a password manager are a good precautions.
Have more questions? Submit a request


Article is closed for comments.
Powered by Zendesk