Re: [fossil-users] SHA-1 in user.pw field

[Andy Bradford]

Thus said Warren Young on Fri, 30 Oct 2015 15:02:40 -0600:

> Are there Fossil  passwords worth that much? I think  so, and the cost
> is continually falling.

Fossil does have  the option of using  SSH and it can be  secured with a
variety  of  mechanisms that  are  more  secure than  Fossil's  built-in
password mechanism.

Andyk
-- 
TAI64 timestamp: 400056377a5b


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] SHA-1 in user.pw field

[Warren Young]

The current stored password algorithm hashes the user’s cleartext password, the 
project code, and the user name with SHA-1.  This will defeat a rainbow table, 
but it means the security of this scheme relies solely on the complexity of 
executing a preimage attack.

Today such an attack would cost about $700k, assuming you’re using publicly 
known techniques:

  https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

Maybe others have better techniques.

Are there Fossil passwords worth that much?  I think so, and the cost is 
continually falling.

Replacing SHA-1 with $BetterHash would help, but to execute such an attack, you 
have to have access to the Fossil server.  If you have that, I don’t see why it 
isn’t less work to just replace the Fossil binary with one that invalidates all 
cookies and saves the plaintext password from the HTTP login transaction 
somewhere.

There are algorithms that allow the server to verify a password without storing 
either it or its hash, and which do not require that the password be 
transmitted in plaintext:

 http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
 
https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism

There are C and JavaScript implementations of both protocols, readily found 
with a search engine.

That’s as much as I know about this.  I have not tried to implement either one.

I’m purposely not covering HTTPS here since the attack requires local access to 
the server, so HTTPS doesn’t help.  That said, SRP and SCRAM remove the need to 
use HTTPS in the first place, at least for maintaining password security in the 
face of a MITM attack.  You should still use HTTPS, though, since a MITM could 
substitute bad deltas into a checkin, for example.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] SHA-1 in user.pw field

[Scott Robison]

On Fri, Oct 30, 2015 at 3:02 PM, Warren Young  wrote:

> The current stored password algorithm hashes the user’s cleartext
> password, the project code, and the user name with SHA-1.  This will defeat
> a rainbow table, but it means the security of this scheme relies solely on
> the complexity of executing a preimage attack.
>
> Today such an attack would cost about $700k, assuming you’re using
> publicly known techniques:
>
>   https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
>
> Maybe others have better techniques.
>
> Are there Fossil passwords worth that much?  I think so, and the cost is
> continually falling.
>
> Replacing SHA-1 with $BetterHash would help, but to execute such an
> attack, you have to have access to the Fossil server.  If you have that, I
> don’t see why it isn’t less work to just replace the Fossil binary with one
> that invalidates all cookies and saves the plaintext password from the HTTP
> login transaction somewhere.
>
> There are algorithms that allow the server to verify a password without
> storing either it or its hash, and which do not require that the password
> be transmitted in plaintext:
>
>  http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
>
> https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism
>
> There are C and JavaScript implementations of both protocols, readily
> found with a search engine.
>
> That’s as much as I know about this.  I have not tried to implement either
> one.
>
> I’m purposely not covering HTTPS here since the attack requires local
> access to the server, so HTTPS doesn’t help.  That said, SRP and SCRAM
> remove the need to use HTTPS in the first place, at least for maintaining
> password security in the face of a MITM attack.  You should still use
> HTTPS, though, since a MITM could substitute bad deltas into a checkin, for
> example.
>

I think this is a more reasonable example of how SHA1 is used in a security
context, and why it might be desirable to change it. Still, it is only
there to control remote access to the repo. Once you have access to the
actual repository file (as you observe) all bets are off. This is similar
to how user and group permissions only work until someone pulls a drive
from a computer and completely circumvents the operating system's access
control mechanisms. Doesn't matter how the password file hashes are
generated if no one needs to look at them to gain access to all files.

In the case of an OS enforcing protections to files, it is possible to
apply encryption to the data so that the operating system only decrypts
data on demand. This isn't perfect, and unfortunately, the point to a DVCS
is to share the data with anyone who has access (assuming the access is
permitted and not fraudulently obtained). Encrypting the data isn't really
an option in this case.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users