Slashdot Mirror
Ask Slashdot: How Do You Create A Highly-Secure Password? (securitymagazine.com)
An anonymous reader writes: A security lab at Carnegie Mellon performed a study on password security recently, and issued a warning about common user misconceptions. For example, 'ieatkale88' would require 4 billion more guesses than 'iloveyou', because 'iloveyou' is one of the most common strings in passwords. And the word 'pAsswOrd' would take 4,000 times more guesses than 'p@ssw0rd', simply because "In modern day password-cracking tools, replacing letters with numbers or symbols is predictable."
But then what passwords are secure in the face of these modern password-cracking tools? As professionals in the IT industry, what advice would you give?
Leave your answers in the comments. How do you create a highly-secure password?
But then what passwords are secure in the face of these modern password-cracking tools? As professionals in the IT industry, what advice would you give?
Leave your answers in the comments. How do you create a highly-secure password?
https://www.random.org/passwords/
With a length of at least 10, preferably 20 or more.
20 character random password generated by KeePass. I have a fairly long 20+ character master password for my password file. Generate a new password for every site in case of a breach. Use 2-Factor authentication wherever possible, especially your email address is this is basically a master key to all your other accounts due to the password reset feature.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
All of my passwords are 32 char random strings using all the available chars.
The only drawback is that I have to write them down on a yellow sticky.
Fortunately, none of the hackers have physical access to my collection of yellow stickies...
If you want news from today, you have to come back tomorrow.
#1. No password re-use. Ever.
#2. Not formulaic.
#3. Not in a dictionary list.
#4. Long. I prefer 32 characters long.
Using a very long passphrase rather than a password is the safest thing. How is anyone going to crack "Mydogateachickenandnowisi$ickwiththegout". It is very easy to remember. You have to make sure the app/OS uses the whole thing, not just silently truncates it.
Star Trek, there maybe hope.
echo -n "<mypassword>|<username>+example.org" | sha256sum | cut -c1-20
Need to change all my passwords? Change the cut or my password.
Rot13.
For real security, use it twice.
I'm Swede (29 characters in the alphabet.)
ROT14.5?
It's simple. I come up with a short word. Then I translate the word into morse code, with SHIT as the the dot and FUCK as the dash. For example, HORSE becomes SHITSHITSHITSHITFUCKFUCKFUCKSHITFUCKSHITSHITSHITSHITSHIT. That's actually a very strong password.
In an offline cracking scenario, the number of possibilities is what counts, not which possibility you used. That means users should have the option of simple or short passwords, but should use long ones. For ease of use (more on this later), a passphrase of several words and punctuation is appropriate. Don't mandate the use or exclusion of any particular symbols, because that reduces the search space, and similarly reduces the time to break the password. In a famous example, "correct horse battery staple" is far more resistant to brute-force attacks than something complex like "Tr0ub4dor&3".
In an online cracking scenario, uniqueness is what counts. If an attacker has harvested your password from one location, they will try to use it to access another. Make sure every password you use is unique. Dumb tricks like appending the site name to a common password are easily caught by attackers, so they don't improve security much. The best way to mitigate the risk of an online attack, then, is use a trusted password manager to create and store your passwords, so every location has a long unique password. This is the approach I use, and most of my passwords are 24+ characters, randomly generated, and all unique.
For universal access, I keep my password manager's encrypted database files in a cloud storage service that my phone can access. Even if that storage is compromised and my file is stolen, it's useless without my master password, which is of course different from every other password for any other purpose.
If you're ever designing a system to handle authentication, the best solution is to not do it. Thanks to standards like OpenID and OAuth, you can connect your services to someone else's authentication, because they're far more likely to handle it correctly.
If you must do your own authentication, use sane policies. Require long (10+ characters) passwords, but don't force numbers or symbols. Requiring a number in a password cuts the password's resistance to brute-forcing by about half (very roughly speaking, and noted in TFS). Make sure nothing in your application interferes with the use of password managers, which often use the system clipboard to copy/paste passwords. To improve user experience, avoid asking for the password at all, instead using an expiring authentication token to reinstate a previous session. The less often a user has to type their password, the less averse they'll be to having a long and secure one.
On the back end, if you must store passwords, make sure they are hashed using a modern secure algorithm (AES-256, SHA-2 or SHA-3) and salted, and do that as soon as possible in your back-end processes. No, your users do not need a way to recover their old passwords. They need a way to reset their password to a new value, and that should only happen by using two separate forms of ID (like a phone call to customer support verbally confirming security questions and an email to the address on file). Those security questions should also be as unrestricted as passwords. Allowing the user to enter open-ended prompts allow the user to use prompts that are only meaningful to them, and are thus much more difficult to find an answer on social media.
Above all else, do not take advice from others, including me and this post, without understanding the reasoning behind it. Computer security is steeped in several decades of little more than superstition, relying on "common knowledge" that often turns out to be incorrect. It may start out well-intentioned, but the implementation is usually missing a key detail, undermining the security of the whole system.
You do not have a moral or legal right to do absolutely anything you want.
What I find is the hardest part about changing passwords is getting my kids and dog to accept their new names.
Is there a more interesting question to ask here?
Have we reached the point where the concept of the password itself is no longer either appropriate, or adequately secure? For example, should we be recommending use of multi-factor and/or multi-channel solutions?
A useful question to ask is, "Where do you have to place your trust?" For example, many respondents to this thread recommend using a password manager.cOK, but how many of those people are aware of the emergence of specific threats targeting password managers, or that some solutions have been found to be insecure? How many people come to rely more and more heavily on a smartphone or similar personal device - a single object that can give access to web, email and voice authentication vectors - yet which is one of the most heavily-targeted platforms from a threat perspective?
I am not trying to denigrate the many excellent answers given here, but I wish to point out the risk that we are taking by asking this as a closed question ("How do you create a highly-secure password?") when changing the question slightly (for example, to "What are the most pragmatic and reliable secure authentication mechanisms available?").
As technology consumers, maybe we should be a bit more demanding about the solutions we are offered. Maybe it would be nice if we had a trustworthy and independent third party that offered a security audit rating system for commonly used service providers, like banks? This alone would drive down a lot of the risk, because to so e extent breaches can be facilitated by bad practices on the part of the service providers...
But other options could consider available variation on the themes of something you have, something you are and something you know. Services should allow us to set our security based on a selection of two or more of that trinity, with a range of options for each... Here's a bad example... Suppose that the fingerprint reader on new Apple iDevices had an exposed API. Then suppose that a web site authentication engine integrated with this, over a secure SSL channel. You go to the site, you tap the option for fingerprint reader, then you put your pinky on the sensor.... What would it take to engineer that securely? In a combination with even the most basic of known passwords, wouldn't that be much more secure?
Or what about something you have? How many people drive a vehicle with a remote control unlock mechanism? One German manufacturer uses a supposedly very secure rotating key mechanism that never sends the same release code twice... What if we used the same principle and allowed people to connect their car key to their keyboard via Bluetooth, using the same or similar principle to integrate an everyday object like a car key as a "something you have" factor?
Both of these are spur-of-the-moment suggestions and likely flawed, but I just wanted to push us past the idea that the right solution is still a password. Respectfully, that's still only single-factor and thus still implicitly weak.
The first thing you need to do is stop listening to statistics someone else faked.
Of all the various ways in which attackers can gain passwords, only two involve cracking them (brute-force and cracking a password database). One of them should be a non-issue, because any software or service that doesn't protect against brute-force is fundamentally broken and shouldn't be trusted with your password anyway. Make your password "a", save everyone the trouble. For a password database crack, firstly the security of the server already failed, and then you're at their mercy a second time because if the password is stored unencrypted, you're fucked. If the password is stored hashed but not salted, you are pretty much fucked. And if the password is properly hashed and salted, congratulations you have the one scenario where a good password actually matters.
In all other attacks on your password, from phishing to shoulder-surfing and keyloggers, it doesn't matter how good your password is, how long it is or how complex it is.
So, if you are really so concerned about the one scenario that you are ready to type V9AnKH5Crpfukuy5gAFB till the end of your days, go to https://www.random.org/passwor... and fire it up. Because all the hints you find on making a "good" password are also known to the people writing password crackers and coded into the pertubation algorithms. True randomness is your best bet.
The one thing that matters, and there's an article about it but I'm too lazy to google it, is length. Length > Complexity. "aaaaaaaaaaaaaaa" is more secure than any variation of 8 characters ever will be, simply because, at least until this post, no password cracker would run the chain like a, aa, aaa, aaaa, ... to arbitrary length.
IMHO, and I am an expert in the field and given speeches about password security, forget all the "password complexity" rules, they are all bullshit. They're the safety net that makes sure that "password" is not a legal password on your system. But the world continuously invents better idiots, so "password1!" is and you're fucked anyway.
Assorted stuff I do sometimes: Lemuria.org