Re: Idea for securityfix in HTML

I think the bottom line here is, MD5 is not enough but we need an MD5 
function so that we can hash the password so that it will match the one 
in the database before doing another, more secure hash based on 
server-supplied text, like HMAC (thanks John).

--John

Bob Foster wrote:

>Of course, you are right, but there seems to be some talking at
>cross-purposes in this discussion.
>
>Mr. XatrOz talks about "saving" and others talk about "communicating". They
>are very different subjects.
>
>Yes, some applications hash a password (perhaps combined with some other
>data) with MD5 or another hash technique before saving it in a database, and
>in the future when a password is received, they hash it (perhaps combined
>with the same other data) before comparing it with the database. Hackers can
>read the database, even with the application source code, without gaining
>any passwords or the ability to log in.  This is a secure technique to the
>extent that the hash can't be reversed.
>
>But the security depends on the hashing being done on the server after the
>password has been received via a secure channel. If either the password or
>the hash are communicated between client and server by an insecure channel,
>there is no security. Zero. Zip. The hash doesn't add one iota more.
>
>Bob
>
>From: "Goetz Bock" <bock@blacknet.de>
>  
>
>>Dear Mr. Xatr0z,
>>
>>please get a copy of "secrets and lies" and read it to figure out why
>>what you suggest is A REALY BAD IDEA.
>>
>>On Sat, Nov 16 '02 at 12:28, Xatr0z wrote:
>>    
>>
>>>[ ... ] If someone is "sniffing" and get's the HTTP request
>>>instead of the HTTP server, he or she doesn't get the password, but it's
>>>encrypted (or with MD5, that depends on the HTTP request). Ofcourse, it
>>>isn't secure, he or she could trie an dictionary or brute-force attack,
>>>      
>>>
>but
>  
>
>>>is is more secure, and I think that's a good thing.
>>>      
>>>
>>I don't need to do and brute-force. I can just reuse the SAME md5
>>hash/checksum I just sniffed to reauthenticate as a valid user. As we
>>have discussed, an MD5 sum can not be "decrypted" into the real
>>password, it can only be compatred to a given MD5 sum in the database.
>>
>>In Unix, there is a SALT used to make the md5 sum for a given password
>>different if used by user A and B. When you log in, the password you
>>typed is salted (one possible salt is added), md5ed and compared to the
>>stored value. If it matched, youre logged in, otehrwise a different slat
>>is tried. If all possible salts (usually just a char, e.g. 256 tries)
>>were tried, and none matched, youre not logged in.
>>
>>This can not be done for HTML. There you can only store one value, and
>>than send THIS stored value. What you could do is to implment one of the
>>"no-secrets-told" authentication mechanisms, but than you'd better use
>>https. It's better understood and therefore more secure (it does not per
>>so add client authentication and is ususally open to man in the middle
>>attacs due to user errors ... oh well)
>>
>>    
>>
>>>What do you feel about the idea to create a attribute which allows the
>>>client to send an (MD5) checksum of the file, to determine if the
>>>      
>>>
>transport
>  
>
>>>went well?
>>>      
>>>
>>This does not even add integrity checks for anything but transport
>>errors. This should be handled by the transport protocoll (TCP/IP in
>>this case) but again read "secrets and lies".
>>--
>>Goetz Bock       (c) 2002 as     blacknet.de - Munich - Germany   /"\
>>IT Consultant    GNU FDL 1.1    secure mobile Linux everNETting   \ /
>>                                                                   X
>> ASCII Ribbon Campaign against HTML email & microsoft attachments / \
>>
>>
>>    
>>
>
>  
>