Hi, Watson commented:
#Passwords are fine provided they are not reused, and transmitted over #secure channels. Has that really been everyone's experience? From my POV, passwords really seem to be inherently badly broken: -- if the user's system is botted, single channel authentication systems (including passwords) are toast out of the box; you really need a second channel, such as auth confirmation via a user's smart phone -- unless we get broad adoption of federated authentication, we'll always have *too many* usernames and passwords (and solutions like Shibboleth tend to treat mobile apps and non-web scenarios as an after thought) -- if you care about formal NIST SP800-63-1 style assurance, implementing throttling as required at section 8.2.3 can be tricky: "the Verifier shall effectively limit online Attackers to 100 failed attempts on a single account in any 30 day period." [I should probably clarify that this is "tricky" *IF* you care about avoiding denial of service attack scenarios] -- and the list goes on... #Client certificates are already supported and widely deployed. The DOD #uses them on smartcards for just about everything. The big problem is #a UI issue. I think the problems with client certs goes far beyond just issues with the user interface. While the CAC/PIV cards you mention are a nice existence proof that client cert PKI is "possible," I invite you to review https://militarycac.com/ for a practical indication of where CAC/PIV implementation is at. There are an awful lot of arcane workarounds and exception cases, and trying to use CAC/PIV cards on alternative operating systems is particularly tricky. On a scale of 1 to 100, where 100 is "perfect, painless, just works" and 1 is "totally broken, unusable," there are many scenarios where CAC/PIV cards are closer to the bottom of the thermometer than the top. If you truly believe that client certs are the answer, I invite those with that belief to begin using client certs with S/MIME to routinely sign all their email. I've got a document that walks you through the process of using client certs that I put together for the Educause/Internet2 Security Professionals Preconference Seminars, and it walks you through the process. If you want to try it, see http://pages.uoregon.edu/joe/secprof2012/sec-prof-2012-client-certs.pdf I'd also note that if you really care about the security of your client certificate credentials, and you want a public/private keypair that was created on a PKI hard token or smart card in non-exportable form, that's great, but it poses some issues if you want to use those credentials on mobile devices (such as smart phones or tablets). Yes, there are things like "CAC sleds" for some mobile devices, but they aren't cheap, which means that this is NOT a ready-for-mass-market solution as it currently stands. Regards, Joe _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
