On 7/26/2015 2:38 PM, Alex Peshkoff wrote:
> On 07/26/2015 01:39 PM, James Starkey wrote:
>> If you were starting over from scratch, you wouldn't want to use SHA-1 to
>> avoid wasting time with discussions like this.  See also RC4.  But the
>> problem with SHA-1 doesn't justify the inconvenience of changing it.
> I do not see serious inconveniences with it. BTW, what hash can you
> suggest instead?

What is the application?  It matters.  The weakness of SHA-1 has to do 
with find collisions, which are any two strings with the same hash (to 
date, none have ever been found).  But collisions have nothing to do 
with passwords, where a stored version is held constant.  For passwords, 
SHA-1 is perfectly secure.

That said, any scheme based on stored passwords, hashed or not, is 
susceptible to a man in the middle attack.  It doesn't make any 
difference whether the man in the middle steals the password or the hash 
of the password -- either will do the trick.  Such a system is so 
hopelessly insecure that the security of the hash doesn't matter.  So 
rather than trying to improve the hash algorithm, if you're going to 
change anything, get rid of storing password hashes altogether in favor 
of only storing SRP verifiers.   A compromised SRP verifier with a 
proper salt can be broken only by brute force and dictionary attacks, 
and even if broken, doesn't compromise past sessions.

A better hash function is like a carbon fiber buggy whip.  The problem 
isn't the buggy whip, the problem is the horse.

There is a SHA-2 that is "better" than SHA-1.  There is a SHA-3 under 
going development.  SHA-2 is no more secure than SHA-1 was thought to be 
for its first 10 years.

The bottom line is this:  If you are going to change the password hash, 
you are going to invalidate all existing passwords.  But rather than 
start over with an already flawed architecture, punt on storing 
passwords at all and go exclusively with SRP.

>
>> Now, all that said, if the only use of SHA-1 is to flatten the "master key"
>> in SRP into a session key, then there is no dependency on SHA-1 as a
>> cryptographic hash, only as randomizing hash, and the weakness is
>> irrelevant.  But if it's used to store passwords, that's a security problem
>> so huge that any SHA-1 weakness doesn't even come into it.
>>
>> Context is everything.
>>
> Yes, SHA-1 is used to store password hashes. For SRP an exponent of
> SHA1(login, salt, password) modulus the prime is stored.
>
>
> ------------------------------------------------------------------------------
> Firebird-Devel mailing list, web interface at 
> https://lists.sourceforge.net/lists/listinfo/firebird-devel


------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to