New answers tagged storage
George has a good answer with some great information regarding this, however one thing you need to think about with all of this is your user experience, and attack theater. If it's on someone's phone, who would be the one to get that data? Local: A person with physical access to that device. With physical access to the device they can wait to watch the ...
I will assume you are using a Strong (slow) Password Hash such as BCrypt with a sufficiently high Work Factor. If you are using a general purpose (fast) hash then the security benefit is very thin. In most cases the Hash should be kept secret. There may be a vulnerability discovered some time in the future. The hash is a multiplier of password strength. ...
Sufficiently long passwords generated by a secure random number generator hashed by an algorithm with long output (at least 128 bit) and no known weakness (at least SHA256) will become infeasible to bruteforce (either against a single hash or compute a useful rainbow table) and salting will not be necessary. Your description of your implementation doesn't ...
Such strong passwords can be safely stored unsalted with a fast algorithm like SHA256, there is no problem in that. The problems are different, you have to trust the client, the secure transportation to the server, and you have to make sure that the generated passwords are indeed unpredictable.
Top 50 recent answers are included