Page 1 of 1

Opinions needed

Posted: Mon Jan 17, 2005 8:07 pm
by crc
Given the following, please give feedback, all welcome.

----------------
Database that holds user information (ie. id, username, password etc..).
When the users log on to site a random 32 character string is generated, then ran through md5.

The original 32 character hash is stored in the database. The 32 character hash with the user id appended to the end of it is placed in a cookie and stored on the user's system.

After this happens the login page refreshes(any security problems with meta refreshes?), finds the set cookie which redirects the user to the index page.

When the index page and all sub pages (member section) find the cookie they seperate the cookie value into the original hash and the user id. Then, attempts to verify the hash with the hash stored in the database.

The cookies last as long as the session. So a new hash is generated every time the user logs in.

I would like some feedback as far as security is concerned. Also, how much do you think this will effect server performance? As the hash's are checked everytime a user refreshes the page, or goes to another part of the member section.

Any better idea's, with the exception of sessions?

Thank you everyone.

, crc

Posted: Mon Jan 17, 2005 8:13 pm
by crc
My bad, posted in wrong section :roll:

Posted: Mon Jan 17, 2005 8:45 pm
by rehfeld
maybe im missing something, but how is that any better than a session?

if a session id is able to be stolen from the user somehow, so can your special hash.

and for situations where its not stolen, i dont see anything significantly superior than to just adding additional entropy to a regular session id.

Posted: Mon Jan 17, 2005 8:47 pm
by feyd
md5 and sha1 are both very fast hashes, so the time spent isn't much an issue. You may have some problems with the cookies being detected if cookies are off or other circumstances..

Moved to Security.

Posted: Tue Jan 18, 2005 4:41 am
by McGruff
The user id ought to be in the hash - also expiry time if you want to protect that from tampering.

Code: Select all

$mac = md5($expire . '+' . $user . '+' . $private_string);
$cookie_value = $expire . '+' . $user . '+' . $mac;
When you get a cookie back hash the submitted values for $expire and $user along with your private string, then compare that to the submitted $mac value. If the cookie has been tampered, and $expire or $user have changed, they won't match.

Posted: Tue Jan 18, 2005 6:56 am
by patrikG
MD5 is not necessarily secure - SHA has, so far, not been compromised. Recent article on Slashdot:
Slashdot wrote:Effugas writes "I've completed an applied security analysis (pdf) of MD5 given Xiaoyun Wang et al's collision attack (covered here and here). From an applied perspective, the attack itself is pretty limited -- essentially, we can create 'doppelganger' blocks (my term) anywhere inside a file that may be swapped out, one for another, without altering the final MD5 hash. This lets us create any number of binary-inequal files with the same md5sum. But MD5 uses an appendable cascade construction -- in other words, if you happen to find yourself with two files that MD5 to the same hash, an arbitrary payload can be applied to both files and they'll still have the same hash. Wang released the two files needed (but not the collision finder itself). A tool, Stripwire, demonstrates the use of colliding datasets to create two executable packages with wildly different behavior but the same MD5 hash. The faults discovered are problematic but not yet fatal; developers (particularly of P2P software) who claim they'd like advance notice that their systems will fail should take note."
Source: http://developers.slashdot.org/develope ... =172&tid=8

Posted: Tue Jan 18, 2005 9:43 am
by pickle
Seems pretty straightforward. One thing you didn't mention is a timeout. The way it seems, I could login and walk away - leaving my window open. While that would be my own dang problem, you might want to put in some timeout functionality to protect users from themselves.

Posted: Tue Jan 18, 2005 9:46 am
by jason
Something else to consider, and this will help resolve the timeout issue. Basically, before the user does anything that is "critical", force them to re-enter their password. For example, they can be logged in, but when they finally go to make a purchase, you ask them for a password again.

Posted: Tue Jan 18, 2005 10:15 am
by AGISB
patrikG wrote:MD5 is not necessarily secure - SHA has, so far, not been compromised. Recent article on Slashdot:
Slashdot wrote:Effugas writes "I've completed an applied security analysis (pdf) of MD5 given Xiaoyun Wang et al's collision attack (covered here and here). From an applied perspective, the attack itself is pretty limited -- essentially, we can create 'doppelganger' blocks (my term) anywhere inside a file that may be swapped out, one for another, without altering the final MD5 hash. This lets us create any number of binary-inequal files with the same md5sum. But MD5 uses an appendable cascade construction -- in other words, if you happen to find yourself with two files that MD5 to the same hash, an arbitrary payload can be applied to both files and they'll still have the same hash. Wang released the two files needed (but not the collision finder itself). A tool, Stripwire, demonstrates the use of colliding datasets to create two executable packages with wildly different behavior but the same MD5 hash. The faults discovered are problematic but not yet fatal; developers (particularly of P2P software) who claim they'd like advance notice that their systems will fail should take note."

Unless you are protecting the CIA database I would still consider Md5 safe.
Even more so if you include a private string. The chance that a forged user credential is like the passcode is very close to 0

For any web application I can think of this is secure enough. The hijacking part and the timeout problem is way more important.

Posted: Tue Jan 18, 2005 10:16 am
by AGISB
patrikG wrote:MD5 is not necessarily secure - SHA has, so far, not been compromised. Recent article on Slashdot:
Slashdot wrote:Effugas writes "I've completed an applied security analysis (pdf) of MD5 given Xiaoyun Wang et al's collision attack (covered here and here). From an applied perspective, the attack itself is pretty limited -- essentially, we can create 'doppelganger' blocks (my term) anywhere inside a file that may be swapped out, one for another, without altering the final MD5 hash. This lets us create any number of binary-inequal files with the same md5sum. But MD5 uses an appendable cascade construction -- in other words, if you happen to find yourself with two files that MD5 to the same hash, an arbitrary payload can be applied to both files and they'll still have the same hash. Wang released the two files needed (but not the collision finder itself). A tool, Stripwire, demonstrates the use of colliding datasets to create two executable packages with wildly different behavior but the same MD5 hash. The faults discovered are problematic but not yet fatal; developers (particularly of P2P software) who claim they'd like advance notice that their systems will fail should take note."

Unless you are protecting the CIA database I would still consider Md5 safe.
Even more so if you include a private string. The chance that a forged user credential is like the passcode is very close to 0

For any web application I can think of this is secure enough. The hijacking part and the timeout problem is way more important.

Posted: Tue Jan 18, 2005 10:27 am
by patrikG
AGISB wrote:
patrikG wrote:MD5 is not necessarily secure - SHA has, so far, not been compromised. Recent article on Slashdot:
Slashdot wrote:Effugas writes "I've completed an applied security analysis (pdf) of MD5 given Xiaoyun Wang et al's collision attack (covered here and here). From an applied perspective, the attack itself is pretty limited -- essentially, we can create 'doppelganger' blocks (my term) anywhere inside a file that may be swapped out, one for another, without altering the final MD5 hash. This lets us create any number of binary-inequal files with the same md5sum. But MD5 uses an appendable cascade construction -- in other words, if you happen to find yourself with two files that MD5 to the same hash, an arbitrary payload can be applied to both files and they'll still have the same hash. Wang released the two files needed (but not the collision finder itself). A tool, Stripwire, demonstrates the use of colliding datasets to create two executable packages with wildly different behavior but the same MD5 hash. The faults discovered are problematic but not yet fatal; developers (particularly of P2P software) who claim they'd like advance notice that their systems will fail should take note."

Unless you are protecting the CIA database I would still consider Md5 safe.
Even more so if you include a private string. The chance that a forged user credential is like the passcode is very close to 0

For any web application I can think of this is secure enough. The hijacking part and the timeout problem is way more important.
Naturally, security is always a compromise and I agree that timeout etc. is more important than MD5, but implementing SHA doesn't take more effort than MD5 and is more secure and that is the issue at hand.