On Thu, Jan 17, 2013 at 4:38 PM, Casper Bang <[email protected]> wrote:
> >> I do not see how basic hashing of the password is worth much. It simply >> changes your password from what you typed, to something hashed off of what >> you typed. Right? I suppose you could have some sort of handshake to >> determine the salts on a per connection basis, that would help. But, at >> this point, it sounds like you are describing a poor attempt at recreating >> SSL. >> >> > HTTPS can prevent man-in-the-middle attacks, but it can not in any way be > used to guarantee that your entered credentials is not logged or stored > improperly at the receiving end. My point is that, as long as everyone > agrees about the algorithms, whether you do hash(password) on the server or > hash(hash(password)) split between the client and the server, is irrelevant > in practice... but only the latter mechanism guarantees that > no clear-text password ever enters the remote system. This could be build > into HTTP (added to RFC). > I guess my problem is with the "everyone agreeing on the algorithms." If it is just a hashing system where everyone agrees to just send the hash instead of the typed text, doesn't this simply shift what the thiefs are looking to steal into the hash? And... since that is the first phase of creating a rainbow table, I'm not sure it actually changes anything. I am curious if you have readings/links that have this idea fleshed out more. I hate to feel like I'm just rejecting it. That is not my intent. I do side with Fabrizio, though. Certs seem like they would be much stronger. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
