-
Notifications
You must be signed in to change notification settings - Fork 0
Capstone Proposal
This page is the master include for a linear reading of the capstone proposal.
Passwords are the most commonly used method of authentication. Until the pain caused by the fragility of using passwords exceeds the pain of replacing them with better systems, this will not change. While there are many issues with the way passwords are used today, the most serious are social, not technical problems:
- Many people select weak passwords.
- Many people reuse those weak passwords in different security contexts.
- Many system administrators, designers, and application programmers are unaware of or simply choose not to follow known best practices for protecting passwords.
Alice chooses a weak password ("monkey10") to authenticate her access to The Primate Forum. To her, the consequences of someone impersonating her are low -- she really doesn't care if someone makes a monkey out of her. In fact she also uses this same password for Twitter and Facebook.
Bob (a.k.a. Dr. Do Much), however, takes The Primate Forum very seriously. His professional reputation could suffer if someone impersonated him. So he chooses a very hard to guess password "you#can!t@make1MONKeyOFme:TPF". To construct this password he followed all of the advice of the password experts. He even changes it slightly for each site he visits. His Bank of America password, for example, is "you#can!t@make1MONKeyOFme:BofA". These passwords are for the sites that he considers high-value.
Unfortunately, Ishmael, the administrator of The Primate Forum is more skilled in philosophy than in cryptography. He doesn't know that you should never store plaintext passwords on a server. He also doesn't know you should rate-limit failed login attempts. He can't understand why humans treat each other so poorly, especially since they consider themselves the "superior species".
Eve randomly tries a few passwords on the Primate Forum, and after only eleven attempts, breaks into Alice's account. She soon learns Alice's Facebook and Twitter usernames, and spends the next few hours monkeying with Alice's friends.
When she gets bored with that she jumps on IRC and finds a nice exploit for the software that Ishmael is using on the forum, and soon has the password list. She is delighted to discover that it is only base64 encoded instead of salted and hashed. She is about to share the list with her friends on IRC when she spots Bob's password and realizes that he takes his monkey business seriously. She snips Bob out for herself and posts the rest of the list.
After a bit of poking around, she is reading email sent to drdomuch@yahoo.com ("Y!:you#can!t@make1MONKeyOFme") and discovers that he is a Bank of America customer. BofA accepts the easily guessed password, but requires two-factor authentication because Eve's browser doesn't have the special cookie. No problem: send the verification code to my Yahoo email. Done. Now, what should she do with all of that money? Open an account on mtGox and buy some BitCoin. How else would Dr. Do Much get money to the primate rights activists in Africa?
Eve still could have hacked The Primate Forum without Alice's easy password, but if Ishmael had stored hashed passwords, Eve would have needed to use a dictionary attack to find monkey10, and she wouldn't have learned Bob's password before the heat death of the universe. If Bob had been using a password manager and unique random passwords for each site, instead of an ad hoc padding trick, Eve would never have gotten into his bank account even though Ishmael didn't know the difference between SHA-1 and Base64.
So we end with a perfect storm, and a perfect failure of the security system. While attempting technical solutions to social problems is frustrating at best, we can educate users about best practices and design user interfaces to support users in following them.
A report published by Gartner Research in 2004 suggested that
There have been many attempts to reduce or eliminate the use of passwords. Most involve some public key infrastructure, and many include multi-factor authentications with hardware tokens or smartcards ("something you have")
- OpenID is an attempt to replace site-specific login systems with a federated single-sign-on system. Instead of each site storing a new set of credentials to be remembered, the site (a relying party RP) simply stores a user-specified URL to his chosen OpenID provider (OP). To authenticate the user, the RP uses this URL to have the OP authenticate the user and send back a success or failure code. In 2013, the deployment of OpenID seems stalled. While there are many providers, relatively few sites are willing to rely on an arbitrary third party OP. There are valid reasons for not wanting to do so, mainly 1) a naive OP implementation is vulnerable to trivial phishing attacks, and 2) it is trivial to establish an OP the does no authentication at all, simply returning success to any request. At the risk of losing some of the benefits of decentralization, a trusted vetting service that rates the reliability of providers could help in overcoming these barriers to wider deployment. Instability of identifiers is another serious problem (Connery, 2010).
- Very little information on FIDO seems to be available to the public. The effort was initiated by PayPal in an attempt to increase security without impairing the user experience.
"There were many other early realizations too: we would need some sort of attestation service to trust the authenticity of devices during registration, we'd need trusted hardware storage for the local key store, we'd need client–side software running in the browsers and native apps in order to broker the user experience in a trusted interface, and we'd need a server implementation that could tie into existing infrastructure behind the firewall while still capable of receiving public keys from an attestation service provider." http://www.fidoalliance.org/about.html
- These are excellent goals. Many of them seem to be directly related to the problems discovered during the development of OpenID. As the supposedly public phase of development is very young, we will have to wait to judge the implementation and industry adoption.
- Persona seems very similar to OpenID, with one important difference:
"Persona also takes a novel approach to protecting user privacy by putting the user's browser in the middle of the authentication process: the browser obtains credentials from the user's email provider, and then turns around and presents those credentials to a website. The email provider can't track the user, but websites can still be confident in the user's identity by cryptographically verifying the credentials. Most other systems, even distributed ones like OpenID, require that the sites "phone home" before allowing a user to log in."
- While requiring user agent support is a barrier to adoption, because user agent upgrades have historically been very slow, the resulting user experience is very clean. Major modern browsers do support the protocol via a javascript library. This implementation may be an issue for security conscious users who disable javascript on low-trust sites.
- A W3C standard. Compatible with OpenID but much more extensible. Because it uses client certificates, it can be used with existing user agents and servers. Unfortunately, existing browsers have poor user interface support for selecting client certificates.
While many of the above standards can complement and minimize the use of passwords, none will eliminate them entirely, so we are left with the problem of properly managing the passwords we need.
http://keepass.info/help/base/security.html
Pilar DR, Jaeger A, Gomes CFA, Stein LM (2012) Passwords Usage and Human Memory Limitations: A Survey across Age and Educational Background. PLoS ONE 7(12): e51067. doi:10.1371/journal.pone.0051067
[A] The researchers used an extremely small sample (20 people, divided into two groups) to reach their conclusions. Also, while "perceived security" may be valuable in terms of marketing and education efforts, it is dangerous basis for technical decisions. The security and privacy track record of handset vendors certainly does not suggest that the perceived security of the phone-based password manager has any basis in reality.
LastPass does indeed have two security weaknesses that should concern privacy conscious users: 1) the source code is not available for auditing, and (2) a recent exploit revealed that the server does store unencrypted metadata about logins. Roboform is also not open source. On the other hand, Keepass is opensource, so it is auditable. However the current state of the "brand" with multiple forks does little to inspire confidence in an informed user. This suggests that any new opensource password manager must carefully manage it's brand: it must be clear that forks may not use the name of the original project in their marketing material.
http://raidersec.blogspot.com/2013/06/how-browsers-store-your-passwords-and.html
Anyone who claims that a system is "secure" must define the expected threat model and what constitutes a failure of the system. The goal for this project is to protect against an attacker with the following capabilities:
- attacker has complete control of the network between client and server
- attacker has access to hardware that can perform MD5/SHA hashes very quickly
- attacker may be able to obtain hashed password file from a server
- attacker may be able to obtain a copy of the encrypted vault.
- minimal - attacker obtains credentials sufficient to impersonate user in one low-value security domain.
- serious - attacker obtains credentials sufficient to impersonate user in multiple security domains, or a single high-value domain.
- complete - attacker is able to obtain and decrypt the password vault.
See [Appendix] for other realistic threats not addressed.
For this project, we assume that the client is unassailable. This is not a realistic assumption. Securing client devices is an active research area. Because most hardware and software vendors are far more concerned about profits than about security and confidentiality of customer data, a reasonably trustworthy computing base will probably never be available to those who do not actively seek it. Indeed, it is a hard problem for anyone. Constant vigilance and defense in depth are essential, but probably not sufficient when protecting against a powerful and determined attacker. The attacker has to succeed only once, while the defender has to succeed every time. A determined attacker will not stop when technical attacks fail.
For this project, we defend against a brute-force attack on the password vault and leave all other client security issues to other researchers:
This is law #1 of the 10 Immutable Laws of Security [4] [5]: "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore".