am building a webapp and want to implement a simple custom authentication as a login (->user/password). i would prefer to hash the password to identify the user, but in webapps it's usual to send passwords to an user in case he forgets it.
so i need to keep unhashed passwords (hashed ones cannot be reconstructed) in my database. is it usual to still keep hashed passwords, to use it for identification? or would it be overengineered/unneccessary if i chose both "password-saving" strategies?
or maybe in case user forgets password, i should send a default password he can change afterwards?
but in webapps it's usual to send passwords to an user in case he forgets it.
Absolutely not! In a well-engineered (from a security point of view) web app, a password is never sent to the user. Unfortunately, it is common that cleartext passwords are stored, but it is not necessary. If a user forgets a password, it should be considered comprised, and the user should pick a new one. This can happen through a link that was sent by email to an address associated with a username the user entered before - not to an address the user can enter just then!
Joined: Dec 29, 2005
well, i do think the same.
but just wondered and found it really strange, how many webapps are sending passwords (even in shopping webapps).
i think it is considered more "user-friendly" and can be used in webapps, where no money can be lost or no critical data is submitted (like forums etc.).
in my first post i of course did not mean default-password like "abc123"!! i merely meant a "good" random password computed by the server application.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com