Are there any plans on the table to add native support for two-factor authentication, such as password *and* public key? Visa PCI standards require two-factor authentication for remote access and if password+key was available in openssh it would be much easier to maintain and support than a full-blown vpn with all the cross-platform compatibility issues that come with one. Thanks! Jacob
jacob martinson wrote:> Are there any plans on the table to add native support for two-factor > authentication, such as password *and* public key? > > Visa PCI standards require two-factor authentication for remote access > and if password+key was available in openssh it would be much easier > to maintain and support than a full-blown vpn with all the > cross-platform compatibility issues that come with one.Well... This depends on interpretation of what is two factor authentication... The regular interpretation is "something you have" and "something you know". "something you have" is usually smartcard device, although using files for poor people can also be accepted if high security is not needed. "something you know" is usually a password for a server (when you use one factor authentication), or password to access the private key on two factor authentication. Since private key is stronger than password, there is no real sense in not protecting the private key it-self using "something you know", and negotiate remote authentication by the stronger mechanism, which resides on "something you have". There is a limited smartcard support in openssh for opensc cards. There is more generic PKCS#11 support available at external patch at http://alon.barlev.googlepages.com/openssh-pkcs11 Best Regards, Alon Bar-Lev.
On July 22, 2006 12:15:07 PM -0500 jacob martinson <martinson.jacob at gmail.com> wrote:> Are there any plans on the table to add native support for two-factor > authentication, such as password *and* public key?You can already do that. Public key is itself already 2-factor -- something you know (the pin/passcode) and something you have (the device on which the public key resides). Password, via PAM or BSDAUTH, allows any two factor device the host (server) system supports.> Visa PCI standards require two-factor authentication for remote access > and if password+key was available in openssh it would be much easier > to maintain and support than a full-blown vpn with all the > cross-platform compatibility issues that come with one.Well, requiring 2 *types* of authentication may not fulfill a 2-factor authentication requirement, at least not the intent. You are clearly trying to do away with a hardware token requirement (otherwise the hardward token alone is enough for 2-factor), so having a software public key is likely to be either protected by the same password as used for the password part of the authentication, or not protected at all. So if I obtained the password, for sure I would need at least temporary access to the client system to obtain the public key, but once that was achieved, I have the public key and that's that. Note the difference between "real" 2-factor auth, where temporary access to the device only gives me temporary access to the server (assuming the passcode/pin is already known). If we don't include windows, then it's pretty easy to deploy a token- based 2-factor system; all modern unices and network devices will work with either pam/bsdauth or radius and give you pretty easy to deploy 2-factor auth. If your reason to require password + public key is to avoid some implementation cost while meeting Visa standards, I suggest you consider that an audit (say post-compromise) will reveal that your method is really only 2-factor in name (given typical user behavior). The cost of deploying a cross-platform token solution is pretty low. If you got down this far, check out www.tri-dsystems.com (full disclosure: they are my employer) for 2- and 3-factor solutions. -frank
jacob martinson wrote:> Are there any plans on the table to add native support for two-factor > authentication, such as password *and* public key?Answering the second part first, yes, it's an open enhancement request (http://bugzilla.mindrot.org/show_bug.cgi?id=983). Going back to the first part: while requiring both password and public-key would probably improve security, personally I think the private key is another instance of "something you know" (although with the useful property of being able to prove you know it without disclosing it) since it can be copied, printed out, emailed... -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On July 23, 2006 8:57:21 AM +0000 Jefferson Ogata <Jefferson.Ogata at noaa.gov> wrote:> On 2006-07-23 07:34, Frank Cusack wrote: >> On July 23, 2006 1:50:20 AM +0000 Jefferson Ogata >> <Jefferson.Ogata at noaa.gov> wrote: >>> On 2006-07-23 01:27, Frank Cusack wrote: >>>> On July 22, 2006 7:08:59 PM -0500 jacob martinson >>>> <martinson.jacob at gmail.com> wrote: >>>>> On 7/22/06, Frank Cusack <fcusack at fcusack.com> wrote: >>>>>> On July 22, 2006 12:15:07 PM -0500 jacob martinson >>>>>> <martinson.jacob at gmail.com> wrote: >>>>>>> Are there any plans on the table to add native support for two-factor >>>>>>> authentication, such as password *and* public key? >>>>>> You can already do that. Public key is itself already 2-factor -- >>>>>> something you know (the pin/passcode) and something you have (the >>>>>> device on which the public key resides). Password, via PAM or >>>>>> BSDAUTH, >>>>>> allows any two factor device the host (server) system supports. >>>>>> >>>>> You can? How can you configure ssh to require both successful >>>>> password authentication (via the underlying OS password verification >>>>> mechanisms) and public key auth before the user is allowed onto the >>>>> system? >>>> >>>> Sorry, I meant you can already do native 2-factor auth via publickey >>>> or via password alone. >>> >>> Calling public-key "2-factor" is just spin. >> >> Not at all. >> >>> 1. You can't force people to put a passphrase on their private key. >>> >>> 2. You can't keep people from storing the key in ssh-agent. >>> >>> 3. If the private key--the actual factor--is compromised, it doesn't >>> matter if someone originally had a passphrase on it. >> >> None of those are correct in the case of smartcards, and ssh publickey >> auth is agnostic as to whether the publickey auth came from a smartcard >> or an on-disk (essentially single-factor) key. > > Your original statement was that "public key is itself already > 2-factor", which is generally untrue. The secret is the private key. > Compromise of the factor is compromise of the private key, plain and simple.True, my original statement was misleading/incorrect.> Public key using a smartcard with a passphrase, which is what you've > changed the topic to, is a much more specific (and expensive) strategy, > and I might grant that it technically involves two factors (though they > really are entangled), since the private key resides, by nature, on > separate media from the rest of the system, unlike public key auth in > general. > > But you appear to be playing word games with respect to two-factor > authentication. A management entity that says, "you must use two-factor > auth" won't be charmed by your fancy footwork--if you convince them that > public keys with smartcards is two-factor auth, they'll say, "fine, then > you have to do three-factor auth".Don't make me laugh. A "management entity" is likely only to be concerned about 2-factor auth because of input from internal IT (and then just as likely to be ignored as not) or from a 3rd-party audit, not because of experience with what 2-factor means and what it achieves. I do disagree with you on whether or not a smartcard is 2 factor ... ok techically yes, if you can get the key out of it, then the other factor is just shine, but at what cost? For the typical threat that has to be protected against, a smartcard is sufficiently 2-factor.> The real question that it would be nice to see answered is how to get > sshd to do n-factor authentication, rather than quibbling over how many > factors are involved in some particular authentication strategy. This > would be addressing the spirit of the original question, not trying to > use semantics to get out of solving the problem.I answered that twice: PAM/BSDAUTH with the correct backends, or publickey with smartcards. And to repeat myself, in the case where you can't change sshd (say sshd on a router) then as long as you can do RADIUS you can generally get multifactor auth via OTP tokens. I'm quite surprised that you would misread the smartcard part of my answer as trying to wrangle out of the question. It seems quite obvious how to have sshd do n-factor authentication in the way the OP suggested: modify the code to require this. I believe there are already patches out there to do just that. I suggested ways to do this without requiring changes to sshd.>>> Some time back I wrote a patch to allow sshd to require multiple >>> authentication passes to succeed, so, e.g. public key could be combined >>> with s/key to achieve something like two-factor without a smartcard; >>> here the thing you have is the piece of paper with the one-time >>> passwords written on it, and if it falls out of your pocket at the >>> convenience store, it presents no threat by itself because there's a >>> keypair somewhere that's also needed; conversely if your keypair is >>> compromised that doesn't give the intruder access to your pocket. >> >> Unless you let the user generate the S/Key seed, in which case it will >> probably be weak. > > It may--so what? The intruder doesn't automatically know what it is.The intruder can easily determine it from observation.> S/key is simply a convenient example because it is free and openssh > already supports it; someone is free to implement an OTP system that > relies on a list of random, unrelated, single-use passwords. The > specific implementation is irrelevant--the point is that OTP is a > distinct factor from publickey, by nature. > >> Even when it is strong, this is generally considered incovenient by users compared to a >> hardware token alone. > > Yes, some people believe more security often means less convenience.Well, it often does. -frank
Chris Rapier wrote:> > > Alon Bar-Lev wrote: > >> Smartcard *IS* two factor, this is why they exist. There is no >> better security solution than smartcards. > > Of course, smartcards can be easily defeated by a sufficiently scary > person holding a pair of garden shears. ;) >Well... I am not a native English speaker... What does it mean? Do you actually think there is a better security mechanism than smartcards? Do you actually think a private key file + password + server password is better than using smartcards? Adding a remote password to the smartcard strengthen the solution? Best Regards, Alon Bar-Lev.
Frank Cusack wrote:> On July 25, 2006 8:17:06 AM +0300 Alon Bar-Lev <alon.barlev at gmail.com> > wrote: >> You can also consider biometric enabled smartcards, and have 3 factors. >> But biometric is the worse from user perspective. > > Why is that? > > -frank >Since my testings showed that the low cost readers used in smartcard readers are too weak... The user usually should try an average 2 times to login... And there are 15% of people that cannot use these readers at all, since there biometric produces too much or too few heat. I also think that a computer software that sits between the reader and the driver can transmit a finger print without it being read from the reader... I know there is a new reader that update the APDU sent to the card with the fingerprint... When this will be available and the reader will be improved I think it would be nice. Best Regards, Alon Bar-Lev.