exoban Posted November 19, 2008 Share Posted November 19, 2008 I have some questions that need to be cleared up. I often find that tutorials and books never seem to answer these specific questions: Why is hashing used (ex md5)? From what I understand, hashed strings can be cracked. How are hashed passwords "dehashed"? If I store a user's password in a database as a hashed value, how can I convert it back to the regular password for comparison during login? If this could be done, then doesn't it defeat the purpose of hashing in the first place? How does an ideally secure login system work? I know about basic cookies and sessions, but that's it. Thanks to whoever clears these up. Link to comment https://forums.phpfreaks.com/topic/133328-solved-some-security-questions/ Share on other sites More sharing options...
Mark Baker Posted November 19, 2008 Share Posted November 19, 2008 Why is hashing used (ex md5)? From what I understand, hashed strings can be cracked. Hashing is used because hashed values can't be reversed to recreate the password. You don't crack the password, you find a text value that generates the same hash... and while there are some hacker tools and methods (rainbow tables) to simplify this, it isn't easy to crak. There are also some databases that are populated with plaintext values and the hashes that they generate for easier lookup by crackers. Some hashing algorithms (such as md5) are intrinsically weaker than others. I use ripemd256. How are hashed passwords "dehashed"? If I store a user's password in a database as a hashed value, how can I convert it back to the regular password for comparison during login? If this could be done, then doesn't it defeat the purpose of hashing in the first place? As stated above, they can't. You don't convert the password stored on the database back to plaintext to compare it with the user-entered password. You has the user-entered password and compare that against the hashed password on the database. Link to comment https://forums.phpfreaks.com/topic/133328-solved-some-security-questions/#findComment-693407 Share on other sites More sharing options...
exoban Posted November 19, 2008 Author Share Posted November 19, 2008 Why is hashing used (ex md5)? From what I understand, hashed strings can be cracked. Hashing is used because hashed values can't be reversed to recreate the password. You don't crack the password, you find a text value that generates the same hash... and while there are some hacker tools and methods (rainbow tables) to simplify this, it isn't easy to crak. There are also some databases that are populated with plaintext values and the hashes that they generate for easier lookup by crackers. Some hashing algorithms (such as md5) are intrinsically weaker than others. I use ripemd256. How are hashed passwords "dehashed"? If I store a user's password in a database as a hashed value, how can I convert it back to the regular password for comparison during login? If this could be done, then doesn't it defeat the purpose of hashing in the first place? As stated above, they can't. You don't convert the password stored on the database back to plaintext to compare it with the user-entered password. You has the user-entered password and compare that against the hashed password on the database. Ah, that makes sense. So I'd hash the password attempt and compare that hash to the one stored in the database. Thanks. Now that those are cleared up, does anyone want to answer the last question? Link to comment https://forums.phpfreaks.com/topic/133328-solved-some-security-questions/#findComment-693411 Share on other sites More sharing options...
Mchl Posted November 19, 2008 Share Posted November 19, 2008 There are no ideally secure systems... All you can do is be smarter than most 'bad guys' out there. Just some addition to what Mark said. To make password hashes more secure, scripts usually add some random characters to password before they're hashed and saved to database. This reduces the possibility that a hash can be cracked using rainbow tables and such. (Especially for passwords like '1234') Lookup 'salt' in security tutorials for more details on how it works and how it is implemented. Link to comment https://forums.phpfreaks.com/topic/133328-solved-some-security-questions/#findComment-693413 Share on other sites More sharing options...
ILMV Posted November 19, 2008 Share Posted November 19, 2008 Last Question: 1) Always store passwords encrypted 2) Where you have input boxes, prevent a hacker exploiting weak code. Change your MySQL code to include this.. http://us.php.net/mysql_real_escape_string 3) Never say "Incorrect Password" or "Incorrect Username"... Instead just say "Incorrect Username/Password Combination". You do not want to give any hints to an unauthorized user. Maybe someone else can comment on sessions/cookies... ILMV Link to comment https://forums.phpfreaks.com/topic/133328-solved-some-security-questions/#findComment-693416 Share on other sites More sharing options...
Mchl Posted November 19, 2008 Share Posted November 19, 2008 Maybe someone else can comment on sessions/cookies... Don't store sensitive information in cookies (they're stored on user's computer after all) On shared host make sure, that session files are saved in your private directory and outside of document root. If it is not possible to do this, set up sessions to be stored in database. There's also good tutorial on security here on www.phpfreaks.com Link to comment https://forums.phpfreaks.com/topic/133328-solved-some-security-questions/#findComment-693427 Share on other sites More sharing options...
exoban Posted November 19, 2008 Author Share Posted November 19, 2008 Alright, so taking into account everything that's been stated, I would store the username in a session for reference when a user logs in. What is the purpose of using cookies? In order for a user to be remembered, the password would have to be given. Since I shouldn't store the password in a cookie, how would it be remembered? Link to comment https://forums.phpfreaks.com/topic/133328-solved-some-security-questions/#findComment-693441 Share on other sites More sharing options...
Mchl Posted November 19, 2008 Share Posted November 19, 2008 You can live without cookies at all if you use sessions. With sessions the only thing that gets (automatically) stored in cookie is unique session ID (and this is what identifies user). Link to comment https://forums.phpfreaks.com/topic/133328-solved-some-security-questions/#findComment-693445 Share on other sites More sharing options...
PFMaBiSmAd Posted November 19, 2008 Share Posted November 19, 2008 If you are using a cookie for a long term "remember me" login, you should not store any direct identifying information in the cookie, such as a username, user id, row number in a database table... Instead, you should generate and store a unique id in the cookie and store this value in your user table for that user. This unique id will indirectly point to the user in the user table. You should also regenerate this unique id (and if you are using sessions, regenerate the session id) so that the value is not static. This will help prevent someone else from impersonating the actual visitor if they get a hold of the cookie value (or the session id.) A login is only as secure as the data being sent back and forth between the browser and the server. For a truly secure login system, you must use https/ssl so that the authentication form data (username/passeord) and any identifying cookie or session id cookie cannot be monitored by looking at the data packets (for example when someone is using a wireless Internet connection that is not encrypted.) Link to comment https://forums.phpfreaks.com/topic/133328-solved-some-security-questions/#findComment-693453 Share on other sites More sharing options...
exoban Posted November 19, 2008 Author Share Posted November 19, 2008 It seems like such a hassle to use cookies just because users are too lazy to log in again. Link to comment https://forums.phpfreaks.com/topic/133328-solved-some-security-questions/#findComment-693470 Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.