Re: The right way to protect passwords?

On 30.06.12 17:35, Owen Jacobson wrote:
On 2012-06-28 14:56:23 +0000, Karl-Uwe Frank said:

On 28.06.12 08:12, Christoffer Lerno wrote:
In light of the LinkedIn breach, a lot of discussion has popped up
amongst server developers on how to secure passwords.

Most people are now repeating the "use a slower hash" mantra. But I
came across a page on scrypt which sort of suggests that not even
bcrypt might be safe in a somewhat near future

From a server developer point of view, the time cost for hashes is
also very harsh.

Is there some alternate way, say making the server take a password on
startup and use some regular encryption (as opposed to hashing)?

I would suggest that the client does the math. On the server side
nothing useful need to be stored nor any hardware encryption device is
necessary if you use the following algorithm


# Split Secret Login

(Preparation)

1) the Client generate a Client-Hash of Parameters only he know about

2) the Client split the Client-Hash in two Parts

3) the Client submit one Part of the Client-Hash to the Server

4) the Server store this partial Hash in his Database


(Log-in Process)

1) the Client send a Log-in Request

2) the Server send back a random Salt

3) the Client calculate a new Hash with the Salt and the complete
Client-Hash

4) the Client send back the Result and the other Half of his Client-Hash

At this point the server (or anyone able to observe the messages to the
server) now has enough information to impersonate the client. While this
is a problem most websites already have ("here's my password in plain
text, authenticate me" leaks enough information allow impersonation,
too), it's probably not something you want to design into a new
authentication protocol.

That's correct, the authentication process should be managed in a secure manner, either over SSL or as mentioned by David Eather in some sort of encryption protocol which is based on the complete client key and an additional security token.


I also don't see any provisions for determining whether the "other half"
being sent is authentic. Anyone who obtains the server's half of a given
client's hash can complete the "client hash" with any values they want,
allowing them to authenticate as that user without knowing their
original parameters.

That's correct again, but the hacker must find the valid "missing half" first. And now imagine the use of a 1024 hex digit as complete client secret for example. Remember we are not bound to use SHA hash values - in fact the client secret can be any kind of value, if it's big enough the hacker need a lot of computing power in order to find just one valid "missing half".

And if a hacker mount a dictionary-attack with plain text passwords there also is no authentication involved.

But, you're absolutely right in mentioning that some kind of authentication should be included in a new log-in scheme. Of course it should be easily manageable and not to complicated for the average internet user. Something purely simple must be found, I suggest.


If clients use the same hash for multiple sites,
then obtaining one server's half of the hash for a client lets you
impersonate that client on any other site using the same hash, trivially.

Here you point out a very important fact. Without any additional parameter apart from the password we would not gain any more security as using the same username and password over and over again on several different websites - somehow like un-salted MD5 hashes than.



What am I missing?

Hm, the hacker could try to generate some kind of rainbow table by generating for instance SHA-256 hashes from commonly known passwords together with the known email-address and an unknown username. Clearly the fact that the email-address of the user is involved as well as an unknown username and keyword will widen that range of possible hashes a lot. Lately he must find the valid combination where the last half of his hash matches the half he already has.

Or he could try to compute as many random SHA-512 hashes as necessary until one of those generated have a matching last part of the one he has stolen.

Or he could try to compute "dummy" SHA-512 hashes in filling up the "missing half" with random numbers and try to log-in using them - which is from my point of view quite a strange way - until the webserver is wide open for any kind of brute-force-dictionary-attack. Am I missing something here?

Currently I am unsure if hashing (username + email-address + keyword) is insufficient for generating SHA-512 hashes which than get split in two parts (of course the "re-use" problem still exist).

I still wonder how many computing power might be needed to find the "missing half" of such a hash (generated in 16384 re-hash runs each) if for example only the email-address and the last half of the hash is known?

And I am wondering what's more convenient for a hacker:

1) knowing how the hashes are computed on the server and having the username, the salt and the complete hash

2) knowing how the hashes are computed on the client and having the username, NO salt and an INCOMPLETE hash

.

Relevant Pages

  • Re: public key vs passwd authentication?
    ... > original salt and the sequence number. ... the client might possibly want to keep a log of all server "salts" ... if any client hash value leaks that is for an iteration less than ... currently be used by a server. ...
    (comp.security.ssh)
  • Re: Split Secret Login Scheme vs. salted Password Hashes
    ... Just reverting back somehow to the first idea, removing one hash stored on the server and still reducing the computing power of the server on each log-in request still a bit. ...
    (sci.crypt)
  • Re: The right way to protect passwords?
    ... Most people are now repeating the "use a slower hash" mantra. ... From a server developer point of view, the time cost for hashes is ... I would suggest that the client does the math. ... While this is a problem most websites already have ("here's my password in plain text, authenticate me" leaks enough information allow impersonation, too), it's probably not something you want to design into a new authentication protocol. ...
    (sci.crypt)
  • SOAP::Lite
    ... my $server = 'server.somewhere.com'; ... I have tried to return a hash. ... My client then looks like this: ... I actually want to pass the contents of several hashes back to the client, ...
    (comp.lang.perl.modules)
  • Re: Fragen zur Beurteilung der Passwortsicherheit
    ... der Client Seite gemacht wird aber die wenigsten ... Aber wenn du das Passwort erst auf der Serversiete hashed, ... potentiell gespoofte Server sendest. ... Paßwort aus dem Hash gar nicht rekonstruieren. ...
    (de.comp.security.misc)