I'd like to see the results too. SRP will tend to resist MITM attacks because of its design, so it seems unlikely that dsniff will be able to attack SRP Telnet (either classic or TLS-enabled) or SRP FTP with any effectiveness.
You're right - both SSH v1 and v2 currently have the same problem - you need to use some out-of-band mechanism like floppies, a telephone call, or FTP (!) to get a "safe" copy of the host key, or else you're vulnerable to MITM.
The other way around MITM is to use a strong password protocol to authenticate the key exchange. Since they reveal no information to a spoofing server, there are no known attacks that can be mounted, even if you can redirect the client to a hacked server, and even if the user knows nothing about security - protocols like SRP simply don't expose password information that way to the peer.
The point is that these MITM attacks can be prevented without inconveniencing the user or forcing him to get a copy of the host key fingerprint in advance. Strong password protocols resist MITM attacks by using a zero-knowledge password proof combined with the key exchange, instead of trusting a host key and sending the cleartext password encrypted with a key of dubious origin. Some versions of SSH (like LSH) have already incorporated strong password technology into their code - others should take their lead.
They don't show up the first time you connect to a new site
When the warning appears, the user doesn't have any way of knowing whether or not the key change is legitimate, and most will simply ignore it, rendering it useless.
You can always write down host key fingerprints, but a system that depends on this kind of user vigilance for user security will never scale.
SRP is free worldwide for both commercial and non-commercial use. And, AFAIK, now that people are becoming increasingly aware of the security advantages they offer when used with memorized passwords, they are starting to see increasingly widespread use in a variety of settings (not just secure Telnet/FTP).
What many people may not realize in this discussion is that the problem of MITM attacks against SSH1/SSH2 is the direct result of the host-based security model that SSH tries to impose on users. UserAuthentication is the worst because it discloses the password to anyone who convinces a client to accept his host key.
Strong password protocols like SRP are able to resist these MITM attacks because they are zero-knowledge, i.e. they don't reveal any information about the password while they prove their knowledge of it to the server.
There have been a number of postings that elaborately describe schemes to ensure that you have the right host key, be it by writing down the key fingerprint or FTP'ing around of file of known host keys. But this complexity makes it easier to screw things up, and is made unnecessary by strong password protocols.
srp-1.7.1 is now available at http://srp.stanford.edu/. It implements secure Telnet-over-TLS with SRP support as well as Kerberos V5 and X11-session-forwarding.
Regardless of whether or not a patent is issued, SRP will be available under the current Open Source-friendly license. There are *no* patent problems using SRP - enabling strong Open Source authentication was one of the major reasons I invented SRP.
Re:Value added for SRP?
on
SSH v. SRP
·
· Score: 1
SRP is listed as a "planned feature" of LSH. Look for it in the next release.
Re:SSH is somewhat secure against MTM
on
SSH v. SRP
·
· Score: 1
SSH *is* vulnerable to MITM, and not just on the first connection. If the host advertises a public key different from the stored key, ssh outputs a loud message to that effect, but allows the user to continue anyway. Here's the kicker - this also happens so often when connecting to legitimate servers that users are practically forced to say 'y' each time or else not get their work done.
SRP does not have this vulnerability, and does not require the user to make this tradeoff because it prevents the MITM attack with better cryptography.
Re:Who says SRP is not patented?
on
SSH v. SRP
·
· Score: 1
Even if a patent is granted for SRP, it will remain available on an Open Source-friendly basis.
Also keep in mind that any password-only system must keep its server database secure, since a compromise can lead to a dictionary attack. SRP offers the maximum possible level of security while still using re-usable passwords. If you want better security, you need to sacrifice the convenience of re-usable passwords.
Re:Keys tied to computers? Indivviduals? Try both!
on
SSH v. SRP
·
· Score: 1
SRP securely exchanges a session key in the process of authentication. This session key is used to encrypt session traffic.
With SSH, you trade security (RSA authentication) for convenience (user password authentication); SRP gives you both at the same time.
Re:Once again, name a major hack due to SSH flaws
on
SSH v. SRP
·
· Score: 1
Keep in mind that although SRP has a small (but rapidly growing) installed base, it is *cryptographically* more secure than SSH with password authentication. While SSH has had buffer overflows, this is not particularly relevant. SRP addresses design flaws and shortcomings in the SSH protocol and can in fact be added to SSH as an authentication mechanism.
Re:SRP is the secure one - cryptographic reasons
on
SSH v. SRP
·
· Score: 1
If you set this option, it sounds like either the administrator or the user has to go around manually maintaining the ssh_known_hosts file. The goal of SRP is to avoid having to trade off security for convenience - there's no known hosts file to maintain with SRP, yet the system still resists server spoofing. SSH can't offer that protection until it incorporates a ZK password method in its authentication stage, a la LSH-0.9.
I'm Tom Wu, the inventor/devloper who designed the SRP protocol and currently maintains the distribution. Some points that I think should be borne in mind:
Comparing SSH and SRP is a bit misleading. As others have pointed out, SRP is an authentication method, and while there are applications that support SRP directly, like secure Telnet and FTP, there is no reason that SRP can't be used, say, as an authentication mechanism for SSH.
SRP is supported by at least one version of SSH, namely LSH-0.9.
SRP offers the type of security one expects from SSH with RSA authentication (resistance to MITM attacks) with the convenience of standard passwords.
PAM modules are the preferred way to set up EPS/SRP on systems that support PAM. Then, it becomes no more difficult than supporting, say, MD5 passwords, and substantially more secure.
SRP Telnet and FTP encrypt the entire session, btw.
Re:Seems vulnerable to spoof atack
on
SSH v. SRP
·
· Score: 1
If you analyze the protocol, you'll find that if your spoof server doesn't have the user's verifier, the protocol will detect this and fail. Furthermore, your spoof server will be unable to mount even a *dictionary attack* against the password even under this circumstance. This is not true of SSH with ordinary password authentication.
Re:Value added for SRP?
on
SSH v. SRP
·
· Score: 3
In a sense, you are correct when you say that SSH when used with RSA authentication offers the same level of security as SRP. The big value-add is that SRP doesn't require you to keep an RSA key - it derives its security using only a password. You can sit down at any remote location, knowing only your password, and log in. At the same time, the session is fully protected against both active and passive attacks.
SRP is more secure than SSH+regular passwords.
SRP is more convenient than SSH+RSA authentication.
SRP can be integrated as an authentication mechanism for SSH (and it has, check out LSH).
Re:Comparing Apples to Oranges
on
SSH v. SRP
·
· Score: 1
SRP Telnet/FTP encrypts the entire login session.
Re:SSH - the only secure solution... for now
on
SSH v. SRP
·
· Score: 1
So how does one go about getting the world to use a better mousetrap? SRP is well-established as offering strong password security, yet I think most people are still using weak password authentication, either inside or outside ssh. This may become a moot point once ssh includes support for SRP authentication.
SRP has applications that support it, most notably Telnet and FTP. SSH does encryption first, authentication second, but this is exactly the wrong order of steps. If the anonymous encryption is attacked (e.g. MITM), then the weak authentication underneath it is exposed. SRP, and anything that does ZK password authentication, does not have this vulnerability. BTW, SRP uses somewhat different crypto primitives than ssh's RSA authentication method. RSA is based on IF, while SRP and other D-H methods are based on DL.
Re:Does it offer session encryption too?
on
SSH v. SRP
·
· Score: 1
SRP telnet/ftp both encrypt your session to protect data confidentiality and prevent session hijacking.
Re:SSH has been banged on for years
on
SSH v. SRP
·
· Score: 1
PAM modules are available for the EPS password format (which SRP uses on the backend) and are in fact the preferred way to set things up. If you have ideas for simplifying integration, I'd certainly like to hear about them.
Slashdot Mirror
I'd like to see the results too. SRP will tend to resist MITM attacks because of its design, so it seems unlikely that dsniff will be able to attack SRP Telnet (either classic or TLS-enabled) or SRP FTP with any effectiveness.
The other way around MITM is to use a strong password protocol to authenticate the key exchange. Since they reveal no information to a spoofing server, there are no known attacks that can be mounted, even if you can redirect the client to a hacked server, and even if the user knows nothing about security - protocols like SRP simply don't expose password information that way to the peer.
The point is that these MITM attacks can be prevented without inconveniencing the user or forcing him to get a copy of the host key fingerprint in advance. Strong password protocols resist MITM attacks by using a zero-knowledge password proof combined with the key exchange, instead of trusting a host key and sending the cleartext password encrypted with a key of dubious origin. Some versions of SSH (like LSH) have already incorporated strong password technology into their code - others should take their lead.
- They don't show up the first time you connect to a new site
- When the warning appears, the user doesn't have any way of knowing whether or not the key change is legitimate, and most will simply ignore it, rendering it useless.
You can always write down host key fingerprints, but a system that depends on this kind of user vigilance for user security will never scale.SRP is free worldwide for both commercial and non-commercial use. And, AFAIK, now that people are becoming increasingly aware of the security advantages they offer when used with memorized passwords, they are starting to see increasingly widespread use in a variety of settings (not just secure Telnet/FTP).
What many people may not realize in this discussion is that the problem of MITM attacks against SSH1/SSH2 is the direct result of the host-based security model that SSH tries to impose on users. UserAuthentication is the worst because it discloses the password to anyone who convinces a client to accept his host key. Strong password protocols like SRP are able to resist these MITM attacks because they are zero-knowledge, i.e. they don't reveal any information about the password while they prove their knowledge of it to the server. There have been a number of postings that elaborately describe schemes to ensure that you have the right host key, be it by writing down the key fingerprint or FTP'ing around of file of known host keys. But this complexity makes it easier to screw things up, and is made unnecessary by strong password protocols. srp-1.7.1 is now available at http://srp.stanford.edu/. It implements secure Telnet-over-TLS with SRP support as well as Kerberos V5 and X11-session-forwarding.
Regardless of whether or not a patent is issued, SRP will be available under the current Open Source-friendly license. There are *no* patent problems using SRP - enabling strong Open Source authentication was one of the major reasons I invented SRP.
SRP is listed as a "planned feature" of LSH. Look for it in the next release.
SSH *is* vulnerable to MITM, and not just on the first connection. If the host advertises a public key different from the stored key, ssh outputs a loud message to that effect, but allows the user to continue anyway. Here's the kicker - this also happens so often when connecting to legitimate servers that users are practically forced to say 'y' each time or else not get their work done.
SRP does not have this vulnerability, and does not require the user to make this tradeoff because it prevents the MITM attack with better cryptography.
Even if a patent is granted for SRP, it will remain available on an Open Source-friendly basis.
Also keep in mind that any password-only system must keep its server database secure, since a compromise can lead to a dictionary attack. SRP offers the maximum possible level of security while still using re-usable passwords. If you want better security, you need to sacrifice the convenience of re-usable passwords.
SRP securely exchanges a session key in the process of authentication. This session key is used to encrypt session traffic.
With SSH, you trade security (RSA authentication) for convenience (user password authentication); SRP gives you both at the same time.
Keep in mind that although SRP has a small (but rapidly growing) installed base, it is *cryptographically* more secure than SSH with password authentication. While SSH has had buffer overflows, this is not particularly relevant. SRP addresses design flaws and shortcomings in the SSH protocol and can in fact be added to SSH as an authentication mechanism.
If you set this option, it sounds like either the administrator or the user has to go around manually maintaining the ssh_known_hosts file. The goal of SRP is to avoid having to trade off security for convenience - there's no known hosts file to maintain with SRP, yet the system still resists server spoofing. SSH can't offer that protection until it incorporates a ZK password method in its authentication stage, a la LSH-0.9.
PAM modules are the preferred way to set up EPS/SRP on systems that support PAM. Then, it becomes no more difficult than supporting, say, MD5 passwords, and substantially more secure.
SRP Telnet and FTP encrypt the entire session, btw.
If you analyze the protocol, you'll find that if your spoof server doesn't have the user's verifier, the protocol will detect this and fail. Furthermore, your spoof server will be unable to mount even a *dictionary attack* against the password even under this circumstance. This is not true of SSH with ordinary password authentication.
In a sense, you are correct when you say that SSH when used with RSA authentication offers the same level of security as SRP. The big value-add is that SRP doesn't require you to keep an RSA key - it derives its security using only a password. You can sit down at any remote location, knowing only your password, and log in. At the same time, the session is fully protected against both active and passive attacks.
SRP is more secure than SSH+regular passwords.
SRP is more convenient than SSH+RSA authentication.
SRP can be integrated as an authentication mechanism for SSH (and it has, check out LSH).
SRP Telnet/FTP encrypts the entire login session.
So how does one go about getting the world to use a better mousetrap? SRP is well-established as offering strong password security, yet I think most people are still using weak password authentication, either inside or outside ssh. This may become a moot point once ssh includes support for SRP authentication.
SRP has applications that support it, most notably Telnet and FTP. SSH does encryption first, authentication second, but this is exactly the wrong order of steps. If the anonymous encryption is attacked (e.g. MITM), then the weak authentication underneath it is exposed. SRP, and anything that does ZK password authentication, does not have this vulnerability. BTW, SRP uses somewhat different crypto primitives than ssh's RSA authentication method. RSA is based on IF, while SRP and other D-H methods are based on DL.
SRP telnet/ftp both encrypt your session to protect data confidentiality and prevent session hijacking.
PAM modules are available for the EPS password format (which SRP uses on the backend) and are in fact the preferred way to set things up. If you have ideas for simplifying integration, I'd certainly like to hear about them.