zingplex Wrote:I would be surprised to see LastPass adopt this because in its adoption, it is threatening thee business model. Also, I think the SQRL spec is done and now Steve is just writing an implementation in assembly.
I do not see SQRL as a threat to the LastPass business model. First, many sites are going to stick with usernames and passwords in spite of the hassle and the lowered security, simply because that is how they have worked for decades. Secondly, LastPass stores far more than just usernames and passwords. LastPass can hold almost anything that needs to be stored securely, like credit card numbers, answers to security questions, safe combinations, and far more. I've even used LastPass to securely exchange documentation for a mortgage. Even if all the websites I use started using SQRL, I would still need LastPass for storing all the other information I need to keep securely.
SQRL would be a superb addition to LastPass authentication. It would improve LastPass security without requiring users to purchase hardware to support second factor authentication. (yes, it could threaten Yubikey's business model, but that's a different story). Incorporating SQRL's user unique cryptographic into the processing used to create the actual LastPass master key would dramatically increase the entropy of the master key, and that would be great. SQRL's approach would allow a user to have a very secure login while enabling them to enter a very short key. One real hassle with secure use of LastPass is that the user's password needs to be long as well as hard to guess, and typing a long password repeatedly is certainly a pain. Using SQRL could eliminate that pain without reducing security.
It would be relatively easy to include SQRL as a user-selected optional second factor authenticator, much like Google Authenticator.