Dietrich Bollmann wrote:
Hi, As far as I remember, in all books I read about PHP and SQL, the password was stored in an encrypted form, even when all the data which should be protected by the password was stored in the same database. Can anybody tell me what is the motivation behind this approach? If somebody hacks the database, he has the data anyway; if he doesn't, he can't retrieve the password, encrypted or not. I am asking because I would like to implement a simple file server. A user would upload his files and get them listed on his user page. If he wants to allow some other person to download the file, he pushes a button beside the file entry in the listing and a page opens where he can enter the email of the other person. An email is send with the link where the file can be found and a password included... The person who asked me to write this file server wants everybody who to receive the same link together with the same password for the same file. In order to implement this approach, the password has to be stored somewhere... I thought about storing the password as it is in the database - but somehow wonder why this never was done in any of the books I read... By the way: in most cases, when pushing the "I forgot my password" button, an email with a user name and a link to activate the password is generated. Anybody who gets into the possession of the email could access the data... Should I rather send two emails, one with the link, one with the new password? Thanks for your help :) Dietrich
Assuming that noone will ever get direct access to your database or is able to access the password directly: there is no need for any type of encryption. However, people usually write code which may (and will most of the time) containt exploitable sections which might give a malicious user the ability to get a dump of the database. A password dump is always interesting, since it gives a LOT of information. People usually don't use 1 password per login, but rather have a "standard password" for most things. Now, if it were unprotected, the person getting the information can instantly log in as that user, or if he wants might even take over that person's identity in other places (rare, but it happens). If it were protected by encryption of some kind then it would first need to be decrypted to be usable (unless there is a designflaw which makes this unnecessery as has been the case in a few messageboards a few years ago). Now, you can either encrypt or hash your passwords. Hashes are one-way, encryption two-way. If the malicious user gets hold of a hash: he'll still not have anything useful in his hands. He might make a reverse lookup table and figure out the password from that (though there's an infinite number of possible inputs for each single [hash] output), but add a salt and don't put that in the database and the user has a low chance of ever finding out what it was. But, just as the malicious user can't figure out what the password was, neither can you: so goodby lost-password feature. Instead you'd have to regenerate a new password and send that over, or do some other fancy magic which doesn't involve sending the current password as-is, since you don't know it either. If you were to use encryption there, you could always decrypt it. If you have the key. Storing the key separately from the encrypted password would make this quite safe. enctpyed_string = (data + key), if you know neither the data nor the key, things get very tough. Because you know the key, you can figure out the password and make a forgot-password feature easily which sends out the actual password. But, because your key is publicly available (if your page has to use it, then it's automatically publicly available, maybe not easily, but a malicious user which managed to get hold of a full password table, could just aswell get hold of the key for the encryption)! Putting in neither, so just keeping the passwords in their plain form is safe. As long as noone _ever_ sees them. Guarantee that and you won't have to bother with hashing/encrypting. If you can't guarantee it, build in some extra safety in the form of hashing and/or encrypting.
hope that explains it all a bit, - tul -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
