Re: Idea for securityfix in HTML

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 / \
>
>

Received on Sunday, 17 November 2002 05:24:40 UTC