Posts Tagged ‘password management’
paj28 posed a question that really fits better here as a blog post:
Security Stack Exchange gets a lot of questions about password strength, password best practices, attacks on passwords, and there’s quite a lot for both users and sites to do, to stay in line with “best practice”.
Web sites need a password strength policy, account lockout policy, and secure password storage with a slow, salted hash. Some of these requirements have usability impacts, denial of service risks, and other drawbacks. And it’s generally not possible for users to tell whether a site actually does all this (hence plaintextoffenders.com).
Users are supposed to pick a strong password that is unique to every site, change it regularly, and never write it down. And carefully verify the identity of the site every time you enter your password. I don’t think anyone actually follows this, but it is the supposed “best practice”.
In enterprise environments there’s usually a pretty comprehensive single sign-on system, which helps massively, as users only need one good work password. And with just one authentication to protect, using multi-factor is more practical. But on the web we do not have single sign-on; every attempt from Passport, through SAML, OpenID and OAuth has failed to gain a critical mass.
But there is a technology that presents to users just like single sign-on, and that is a password manager with browser integration. Most of these can be told to generate a unique, strong password for every site, and rotate it periodically. This keeps you safe even in the event that a particular web site is not following best practice. And the browser integration ties a password to a particular domain, making phishing all but impossible To be fair, there are risks with password managers “putting all your eggs in one basket” and they are particularly vulnerable to malware, which is the greatest threat at present.
But if we look at the technology available to us, it’s pretty clear that the current advice is barking up the wrong tree. We should be telling users to use a password manager, not remember loads of complex passwords. And sites could simply store an unsalted fast hash of the password, forget password strength rules and account lockouts.
A problem we have though is that banks tell customers never to write down passwords, and some explicitly include ‘storage on PC’ in this. Banking websites tend to disallow pasting into password fields, which also doesn’t help.
So what’s the solution? Do we go down the ‘all my eggs are in a nice secure basket’ route and use password managers?
I, like all the techies I know, use a password manager for everything. Of the 126 passwords I have in mine, I probably use 8 frequently. Another 20 monthly-ish. Some of the rest of them have been used only once or twice – and despite having a good memory for letters and numbers, I’m not going to be able to remember them so this password manager is essential for me.
I want to be able to easily open my password manager, copy the password and paste it directly into the password field.
I definitely don’t want this password manager to be part of the browser, however, as in the event of browser compromise I don’t wish all my passwords to be vacuumed up, so while functional interaction like copy and paste is essential, I’d like separation of executables.
What do you think – please comment below.
This blog post is inspired by a question on Information Security Stack Exchange about two weeks ago. The question seems to have attracted quite a bit of attention (some of it in an attempt to defend the flawed scheme) so I would like to write a more thorough analysis of the scheme.
Let us start by discussing the current standard for authentication. Passwords. No one is arguing that passwords are perfect. Far from it. Passwords, at least passwords in use by most people are incredibly weak. Short, predictable, easy to guess. This problem is made worse by the fact that most applications do not store passwords in a secure fashion. Instead of storing passwords in a secure fashion, many applications store passwords either in plaintext, unsalted or hashed with weak hashing algorithms.
However, passwords aren’t going anywhere because they do have several advantages that no other authentication scheme provides.
- Passwords are convenient. They do not require users to carry around additional equipment for authentication.
- Password authentication is easy to setup. There are countless libraries in every single programming language out there designed to assist you with the task.
- Most importantly, passwords can be secure if used in the right way. In this case, the “right way” involves users using long, unique and randomly generated passwords for each application and that the application stores passwords hashed with a strong algorithm like bcrypt, scrypt or pbkdf2.
So, let us compare Steve Gibson’s SQRL scheme against the golden standard of password authentication. Long, unique and randomly generated passwords hashed with bcrypt, scrypt or pbkdf2 in addition to a one time password generated using the HOTP or TOTP algorithms.
(I am going to be borrowing heavily from the answers to the original Information Security Stack Exchange answer since many excellent points have already been made.)
Authentication and identification is combined
No annoying account creation: Suppose you wish to simply comment on a blog posting. Rather than going through the annoying process of “creating an account” to uniquely identify yourself to a new website (which such websites know causes them to lose valuable feedback traffic), you can login using your SQRL identity. If the site hasn’t encountered your SQRL ID before, it might prompt you for a “handle name” to use for your postings. But either way, you immediately have an absolutely secure and unique identity on that system where no one can possibly impersonate you, and any time you ever return, you will be immediately and uniquely known. No account, no usernames or passwords. Nothing to remember or to forget. Your SQRL identity eliminates all of that.
What Gibson describes as an advantage to his scheme I consider a huge weakness. Consider a traditional username/password authentication process. What happens when my password gets compromised? I simply request for a password reset through another (hopefully still secure) medium such as my email address. This is impossible with Gibson’s scheme. If my SQRL master key gets compromised, there is absolutely no way for the application to verify my identity through another medium. Sure, the application could associate my SQRL key with a particular email address or similar, but that would defeat one of the supposed advantages of the SQRL scheme in the first place.
Single point of failure
The proposed SQRL scheme derives all application specific keys from a single master key. This essentially provides a single juicy target for attackers to go after. Remember how Mat Honan got his online life ruined due to interconnected accounts? Imagine that but with all your online identities. All your identities are belong to us.
So how is this master key to your online life stored? On a smartphone. Not exactly the safest of places what with all the malware out there targetting iOS or Android devices. You have bigger problems if you are using Windows Phone or Blackberry. 😉
People also have the tendency to misplace their smartphones. When combined with the previous point of no other means to identify yourself to the application, this would be a very good way of locking yourself out of your “house”
Not exactly very reassuring.
Social Engineering attacks
@tylerl has a very good point about this in his answer. I don’t see a way for me to write it in a clearer way to I will quote him verbatim.
So, for example, a phishing site can display an authentic login QR code which logs in the attacker instead of the user. Gibson is confident that users will see the name of the bank or store or site on the phone app during authentication and will therefore exercise sufficient vigilance to thwart attacks. History suggests this unlikely, and the more reasonable expectation is that seeing the correct name on the app will falsely reassure the user into thinking that the site is legitimate because it was able to trigger the familiar login request on the phone. The caution already beaten in to the heads of users regarding password security does not necessarily translate to new authentication techniques like this one, which is what makes this app likely inherently less resistant to social engineering.
The three major flaws I have pointed out is definitely enough to kill SQRL’s viability as a replacement for password authentication. The scheme not only fails to offer any benefits over conventional methods such as storing passwords in a password manager, it has several major flaws that Gibson fails to address in a satisfactory manner.
This blog post has been cross-posted on http://www.infosecstudent.com/2013/10/debunking-sqrl/
Question of the Week #1
How does changing your password every 90 days increase security? As selected by @HendrikBrummermann this has been one of our more popular posts, with discussion on the reasons for password expiration:
- To mitigate the problems that would occur if an attacker acquired the password hashes of your system
- It prevents people who use the same password for everything from getting your system compromised if their password is figured out somewhere else
- Compliance reduces the risk of penalties of non-compliance (thanks @AviD)
- By resetting password every X days we are telling the user – Hey, this is important and it should not be taken lightly
and Against password expiration:
- Your password, and the attacker’s guess at your password, are independent. The probability that the attacker’s next guess is correct is the same even if you change your password first.
- Nothing encourages passwords on post-its quite like frequent expiration, especially if there are also high complexity requirements
- It annoys users
- They end up having to work out a new password – which research shows is often is derived from the previous one in a way that is very easy to crack nearly half the time
- You can expect additional support costs to cover users who have forgotten
How to balance the pluses and minuses depends on your organisation’s risk profile and other requirements.
An alternative to password expirations is requiring stronger passwords, and we have questions and research on that also.
The associated question – Why do sites implement locking after 3 failed attempts – details another aspect of the defence against brute forcing, and discusses why 3 may or may not be a suitable number.
These questions, answers and commentary are well worth a read if you are trying to set a password expiry policy in your own organisation, or want some background as to the risks.
According to Rory Alsop’s post the most popular topic at our IT Security site is passwords. So in this post I’ll provide a tour of some relevant questions and answers, and a look at how it sparked further investigation of the sorry state of password protection in some current systems.
There is an amazing amount of confusion, disinformation and bad practice out there with respect to password management. This is all the more frustrating because the basics were worked out back in the dark ages (1978 to be precise) for Unix by Bob Morris and Ken Thompson (Password Security: A Case History, Morris & Thompson, 1978). They not only covered the importance of hashing passwords with salts and a slow algorithm, but they described what is now called a “pepper” (a second salt stored apart from the password database).
So if you peruse the dozens of ‘passwords’ questions you’ll find frequent reference to the basics. We’ve also tried to summarize some of the key points in the ‘passwords’ tag info. By the way, that’s one of the cool things about StackExchange sites in general – how they provide for a little “wiki” for each tag, to allow us to put key information just a mouse hover or one click away from readers.
Of course even among good practitioners, there are debates about the finer points, and that is another thing you’ll find here. See e.g. the spirited conversation about highly iterated password hashes for web apps vs the risk of DDoS attacks at Do any security experts recommend bcrypt for password storage?.
In the end, you’ll often find that the right approach depends on what kind of “security” you’re looking for. As our Frequently Asked Questions points out, this depends on context – what assets you’re trying to protect from what sorts of threats, how your different vulnerabilities compare, and how that all fits into your business plan.
I’ll end with a look at one question which demonstrates the kind of expertise we have already attracted to the site: MySQL OLD_PASSWORD cryptanalysis?. I asked this after stumbling across some other questions about how MySQL used to deal with passwords. To my amazement, within hours, noted cryptographer Thomas Pornin had not only cracked the old algorithm, but he included some code to demonstrate just how totally broken the OLD_PASSWORD scheme was. Subsequently we also found a paper from 2006 with more details. Evidently the folks at Oracle who work on MySQL hadn’t gotten the memo then, and still have a lot of work to do to improve their current scheme, as described at Looking for example of well-known app using unsalted hashes.
So stay ahead of the crowd: when you have a question about security, see if we have a good answer. If not, ask away. And if you see questions that need more work, please contribute to providing good answers!