On Tue, Nov 12, 2013 at 9:32 AM, Joe St Sauver <[email protected]>wrote:
> 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: > What is written is strictly accurate but misses the point that real users cannot and will not remember a different password for every site. I share the same password across all my low security sites and have no intention to change that. It is not worth my time to remember a different password to log into the Washington Post or the NYT or whatever. I am not going to use my brain cells to protect someone else's asset. Nope, not unless they are paying me to do so. All my Facebook accounts use the same password which is the same as my Twitter accounts and all the other social media accounts. Remembering my usernames is hard enough. When I am forced to change my password it takes me several months to get back to steady state which is only achieved when all the sites have the same password again. > -- 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] > I frequently rack up a dozen tries because I can't remember the username/password combination. > -- 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. > The main problem is that they expire. And the second problem is that none of the infrastructure expects one user to have multiple certs. So the cert has to be shared across devices which negates the security advantage. > 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. > The user experience is designed for checklist compliance. It isn't very good. People can be paid to use it but it really only works in closed enterprise environments right now. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
