Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Secure Remote Password protocol

en.wikipedia.org

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Secure Remote Password protocol

#11

Post by nly »

tprynn wrote: post #8
tptacek wrote: post #5

Earlier quoted context omitted.

A nit: even compared to some recent designs, SRP is pretty thoughtful about offline password cracking. It's not as expensive to crack as a real password hash, but far more expensive than other PAKEs.

I haven't read enough about the other PAKEs to know what offline attacks look like there, but the fact that they are endemic to PAKEs is a total footgun. For example, one implementation of SRP I looked at used 8-digit codes (e.g. 12345678) to connect new devices to a network. Eight digits was enough to prevent brute-forcing by repeatedly sending codes to the server, but not enough to prevent an attacker from MITMing…

SRP completely prevents passive MITM attacks and requires online active attack (real time impersonation of either or both parties during the handshake), and even then you can't do anything if the real server and client impose their own rate limiting

Re: Secure Remote Password protocol

#12

Post by DorothySim »

tptacek wrote: post #6
alfalfasprout wrote: post #2

This sounds like ephemeral diffie hellman. Is that still protected by patents? I wouldn't think so seeing we've had robust implementations in openssl for a long time now.

It's not ephemeral Diffie-Hellman.

According to this [0] they are related ("SRP is related to Diffie-Hellman.").

[0]: http://web.archive.org/web/20130407190430/http://chargen.mat...

Re: Secure Remote Password protocol

#13

Post by tptacek »

DorothySim wrote: post #12
tptacek wrote: post #6

Earlier quoted context omitted.

It's not ephemeral Diffie-Hellman.

According to this [0] they are related ("SRP is related to Diffie-Hellman."). [0]: http://web.archive.org/web/20130407190430/http://chargen.mat...

They're related in that the derivation of session secrets is done through a simple modular exponentiation. Pretty much nothing else, from the generation of keypairs to the selection of groups to work in to the way parameters have to be checked, are the same.

Re: Secure Remote Password protocol

#14

Post by tprynn »

tptacek wrote: post #10
tprynn wrote: post #8

Earlier quoted context omitted.

I haven't read enough about the other PAKEs to know what offline attacks look like there, but the fact that they are endemic to PAKEs is a total footgun. For example, one implementation of SRP I looked at used 8-digit codes (e.g. 12345678) to connect new devices to a network. Eight digits was enough to prevent brute-forcing by repeatedly sending codes to the server, but not enough to prevent an attacker from MITMing…

Wait, what's the brute-force attack you're contemplating here? I'm thinking of the attack where you've compromised the servers and stolen the verifiers.

Looking back at my notes, I think my earlier comment was misleading. The offline brute force was due to an insecure random number generator, which allowed an attack against B to recover b (and from there crack the 8 digit code). So, uh, ... I'm wrong on the internet. I think we've talked about this attack before actually :P

Re: Secure Remote Password protocol

#15

Post by tptacek »

tprynn wrote: post #14
tptacek wrote: post #10

Earlier quoted context omitted.

Wait, what's the brute-force attack you're contemplating here? I'm thinking of the attack where you've compromised the servers and stolen the verifiers.

Looking back at my notes, I think my earlier comment was misleading. The offline brute force was due to an insecure random number generator, which allowed an attack against B to recover b (and from there crack the 8 digit code). So, uh, ... I'm wrong on the internet. I think we've talked about this attack before actually :P

Ok, that makes more sense! There are some pretty huge systems that would be very, very broken if the attack you accidentally described was viable. :)

I agree with you that SRP is worth avoiding.

Re: Secure Remote Password protocol

#16

Post by dfc »

alfalfasprout wrote: post #2

This sounds like ephemeral diffie hellman. Is that still protected by patents? I wouldn't think so seeing we've had robust implementations in openssl for a long time now.

> The Secure Remote Password protocol (SRP) is an augmented password-authenticated key agreement (PAKE) protocol, specifically designed to work around existing patents.[1]

Re: Secure Remote Password protocol

#18

Post by technion »

tprynn wrote: post #3

While this is interesting historical reading, SRP is badly outdated and should not be used for any newly built systems. It has a lot of non-obvious failure modes around parameter handling and offline password cracking that have broken the authentication mechanism in every implementation I've seen in the real world (new implementations, not when using large packages such as OpenSSL). Furthermore, PAKEs are of relative…

As always, a relevant demonstration:

https://cryptopals.com/sets/5/challenges/37

Re: Secure Remote Password protocol

#19

Post by MDrollette »

tprynn wrote: post #3

While this is interesting historical reading, SRP is badly outdated and should not be used for any newly built systems. It has a lot of non-obvious failure modes around parameter handling and offline password cracking that have broken the authentication mechanism in every implementation I've seen in the real world (new implementations, not when using large packages such as OpenSSL). Furthermore, PAKEs are of relative…

I'm curious why ProtonMail would have chosen SRP given your comments. https://protonmail.com/blog/encrypted_email_authentication/

Re: Secure Remote Password protocol

#20

Post by tprynn »

MDrollette wrote: post #19
tprynn wrote: post #3

While this is interesting historical reading, SRP is badly outdated and should not be used for any newly built systems. It has a lot of non-obvious failure modes around parameter handling and offline password cracking that have broken the authentication mechanism in every implementation I've seen in the real world (new implementations, not when using large packages such as OpenSSL). Furthermore, PAKEs are of relative…

I'm curious why ProtonMail would have chosen SRP given your comments. https://protonmail.com/blog/encrypted_email_authentication/

I don't think you'll find many people in the security industry who think ProtonMail is anything but a joke. I'll leave you with this (written by 'tptacek): https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
Post reply on HN