Use an 8-char Windows NTLM password? Don't. Every single one can be cracked in under 2.5hrs HashCat, an open source password recovery tool, can now crack an eight-character Windows NTLM password hash in less time than it will take to watch Avengers: Endgame. In 2011 security researcher Steven Meyer demonstrated that an eight-character (53-bit) password could be brute forced in 44 days, or in 14 seconds if you use a …
*Use passphrases, not words, "AworldinwhichIdieonTuesday" is stronger in basically every way when compared to "trump3t"
*Make them nonsensical, mix case and use word and numeral representations, "TacosEngraveSixFlying9s" over "tacosengrave6flying9s" or "tacosengravesixflyingnines"
*Throw some punctuation and grammar in, "WhyIdon'tmindifU2!"
*And then use a local, opensource passphrase manager without cloud syncing or cloud backups.
Yeah who manages the password managers? Didn't one get hacked a few weeks after i raised this very question a couple of years ago?
I'd rather not. I keep mine on paper hidden in a book. That way the hackers at least have to have the balls to break into my home to get them.
I also use 16+ digit (usually around 25) passwords if the damn site/system will let me.
"I'd rather not. I keep mine on paper hidden in a book."
My sister's husband followed my advice to record his passwords in a private notebook. When he died in an accident, we recovered the passwords for his business and private investments. My sister would not have been affected immediately -- enough money around in current joint accounts. But the business could not have traded without stuff being written down.
"Throw some punctuation and grammar in"
Decent advice up to this point, but despite being all too common this is a terrible idea. Unless you're using a password vault (which as Baldrickk notes makes any rules about passwords basically irrelevant), a password needs to serve two equally important purposes - it needs to be secure, and you need to be able to remember it. Throwing in even fairly simple obfuscation like punctuation, odd grammar, replacing o with 0, and so on, does very little to increase security but makes things virtually impossible to remember.
The trick is to remember that there are far more words than there are characters. A random jumble of 10 alphanumeric characters has ~10^17 possible combinations*. Throw in a variety of punctuation and that goes up to ~10^19. The OED contains 171,476 English words currently in use (and a whole bunch more of obsolete, derivatives, and so on). A random selection of 4 words gives ~10^20 combinations. That's why the whole correcthorsebatterystable thing exists - just four words is better password than 10 random characters even if an attacker knows it's four words and attacks that rather than by character. 10 random words puts the possible combinations over 10^52, and is still easier to remember than a jumble of punctuation.
Using meaningful sentences reduces that quite a bit, but greatly improves the ability to remember it while still leaving far more combinations than even the kind of longer random passwords generated by password managers.You just have to look at how many hundreds of songs, film quotes, famous sayings, and so on, the average person can remember. Admittedly that approach can make things a little more vulnerable to social engineering, but given that by far the biggest threat these days comes from mass leaks of credentials where an attacker has no idea what a given username/password combination's favourite song might be, that's a pretty small tradeoff for a massive boost to both password security and memorability.
* Assuming no repetition, so essentially just n!/(n-m)!. Allowing repetition and variation in the exact character set might make an order of magnitude or two difference, but isn't really significant.
"If it is commonly used words that you are likely to remember, then isn't it a lot less than that."
Or it might be a lot more. Merriam-Webster lists nearly 500,000 words, and apparently some counts put it at over 1 million. Even that 171k is only those listed as in common usage, the OED actually contains around 230k. Plus dictionaries generally don't include proper nouns, so there's a huge additional pool as soon as you start using names. The thing is, the exact number really doesn't matter. All that's important is that there are a lot more words than there are characters (that is the entire point of an alphabet after all) and that it's generally easier to remember longer combinations of them. Even if you assume people only use their own vocabulary and don't look anything up or use a generator, that's around 30,000 common words, and a random selection of four of them provides about the same number of possible combinations as 10 random characters.
Essentially, there are two main factors involved in creating a strong password - length and character set. If you consider your character set to be actual single characters, you're limiting yourself to a few tens - basic alphanumeric gets you 36, adding cases and punctuation can push you up to maybe 100 at most. That means in order to get a strong password you need to make it long, and as this article shows the traditional 8 characters that still serves as a limit in many places simply isn't adequate.
If you instead you use whole words as your character set, you're looking at orders of magnitude larger - around 30,000 for the average person's working vocabulary, potentially into the millions using dictionaries, names, slang, and other languages. With your working character set orders of magnitude larger, a password doesn't need to be as long - four words being about equivalent to a reasonable strength password made of random characters. Quibbling over exactly how much bigger the character set is just doesn't matter. Maybe it's only 20,000, maybe it's a million. Maybe you need 5 words instead of just 4, maybe even 3 is good enough. It's the qualitative difference that's matters; as long as your working character set is orders of magnitude larger, exactly how many orders of magnitude just isn't that important.
Text has entropy, or something, of about 1 digital bit per letter: on average it's a fifty-fifty bet what the next character is. Some have more options, Q basically has no options - it's always u.
I've been using two random numerals and six consonants (one capital), usually with a little verbal reminder: for instance PDL5HTZ8 I'd remember as "pendulum height" and the rest does come from memory. (This isn't a current password.) So maybe time to upgrade now. What's "safe"?
>What's "safe"?
Well clearly "PDL5HTZ8" isn't because it is only 8 characters, whereas "pendulum height" - 15 characters (or variants using a special character instead of the space character) is.
However, if the website is using something other than NTLM then "PDL5HTZ8" is probably still "safe".
"However, if the website is using something other than NTLM then "PDL5HTZ8" is probably still "safe"."
I'm assuming that "safe" means "if the hashed password is found, it can not easily be recovered allowing other accounts that use the same password to be recovered or allowing other det".
In which case, it is purely down to entropy. While numbers, case and symbols allow you to increase entropy, I would argue that anything less than 12 characters will not contain sufficient entropy to protect you if you are not using random text (i.e. anything containing dictionary words, guessable numbers combinations at the start or end, common character-to-symbol swaps etc) so look for 14+ characters.
Also, corporate password rules (one or more numbers, one or more symbols and upper and lower case) can make a significant difference to password strength in a corporate environment. i.e. patterns like "Barclays2019!"
As others have said, use a password manager with a long, complex password to make it hard for the address space to be easily searched. For everything else, use a random password generator with very long passwords (20+ characters of random noise) and save them in the password manager. If you're signing up to a website that you are unlikely to use again, use a 10-minute e-mail site to register fake details and a made up password you use once and then abandon.
Unfortunately, this isn't being paranoid now, it's just avoiding the effort required to fix things when one of the websites you depend on coughs up your details :( If you're paranoid or think the government is out to get you (rather than everybody...) double the password lengths because you're likely trying to hide things for more than 5 years.
" it needs to be secure, and you need to be able to remember it."
And the one they always miss: You have to be able to type it reliably without visual cues.
Let's face it; everyone who has a short password likely started out with a longer one but all the retyping got old fast.
"Let's face it; everyone who has a short password likely started out with a longer one but all the retyping got old fast."
Not to mention being locked out of online access by your bank or credit card company until you call them. I'm getting older and my touch-typing of even real words isn't that reliable unless I watch my fingers. Thankfully, some sites now allow you to display the characters you type — presumably for when you are confident that no one will be able to see your display.
I'd love to use something like correcthorsebatterystaple everywhere. Unfortunately, dang near everything demands mixed case, symbols and numbers. At which point everyone picks a short password, because nobody can remember a long password with jumbled spelling. If I find whoever decided that mixed case, symbols and numbers were a good idea, I'll hit him with a dictionary.
The problem with a leetspeak spelling like that is that unless you have a good memory (and/or type the password frequently), there's a reasonable chance that you'll forget exactly which letters you leeted and which you capitalised, etc.
I suppose a possibility to satisfy such password rules would be something along the lines of CorrectHorseBatteryStaple1234$, with the words always capitalised in the normal way, and always using the same number/symbol string on the end (for every password that requires that), so that you can remember it?
(Of course, you can bet that every password cracking program nowadays will include a check for 'correcthorsebatterystaple' before it tries other long passwords anyway...)
"Leetspeak can be your friend."
Your only friend is entropy. Leetspeak adds a similar level of entropy as one capital and a better approach is to add characters between the words as it increases the password length:
i.e.
Password Entropy bits
correcthorsebatterystaple 93
Correcthorsebatterystaple 114
correcthor5ebatterYstapl3 120
Correct$horse$battery$staple 130
Correct$horse$battery$stapl9 136
1337 may make a difference with brute force, but that's likely to be the last method used after dictionaries, rainbow tables and more intelligent patterns.
Note that these are example passwords and I'm assuming for the example they aren't well known. All variants of these are likely to occur in decent dictionaries/rainbow tables meaning that even entropy won't save you.
What would be wrong with 'correcthor5ebatterYstapl3"?
Two years later:
Attempted & rejected password attempts:
corr3cthor5ebatterYstapl3
correcthor5ebatterY5tapl3
corr3cthor5ebatterY5tapl3
correcthor5ebatt3rYstapl3
corr3cthor53batterY5tapl3
(all the versions with inadvertent typos redacted for brevity)
It's true that adding in genuinely random punctuation will make it much harder to remember but adding in a punctuation character that is randomly selected once at the beginning of time does add a bit of value. It's worth remembering that if we suggest four random words, the average critter in the street will think "well two or three will be good enough" and they won't necessarily be well chosen words at that ("letmein" is three words but it's very far from uncrackable).
I always point out that any transformation ("o" -> "0") you can think of, those who crack passwords professionally have thought of it before you, so it's pointless.
One of the downsides of password manager generated random passwords ("45K7WaUfHxFyrIu6J6CPKM3Gs1jU1oB+UhMByAkn48A" (yes I do have a shell function to generate random noise passwords - don't you?)) is that they're a lot harder to type in than random word-style passwords ("petrifies-Reunion-primitive-putsch" (ditto)). And sometimes you do have to type 'em in.
I'm very familiar with 2- or 3-year old thumb drives — even those made in the USA by the best manufacturers — either becoming completely unreadable (looks like unformatted media) or having random data corruption inside files. They are simply not a reliable archive medium.
Of course you'd better have a good backup strategy!
Yes. And for many people, it's also important to have an inheritance strategy, so that your heirs can get into at least the important accounts in the event of your unexpected demise. This is a major problem for many families, and one that most of the password managers I've looked at don't handle very well.
>As long as you know the account numbers you can approach the vendor with the death certificate and you will get the funds.
Obviously not been through the Probate process in recent years...
Remember web accounts aren't always directly connected to a living person: for example try and provide that the deceased John Smith for which you have a death certificate is the same John.Smith@gmail.com...
Also one of the last 'vendors' you actually want to approach with a death certificate is their bank - they will tend to immediately close the account instead of doing the more sensible and blocking payments out until presented with a deed of Probate. This means that various utility and insurance premium overpayments have no account to go into (most companies will simply rebate overpayments on production of the death certificate to the account from which they were taken), thus now you have to go round all these companies sending them a copy of the deed of probate etc. just so that they can write a cheque out for these small amounts.
Another back of the queue vendor is the phone company, if the person has set up their phone as part of the account recovery, loss of the phone numbers means these accounts become practically unrecoverable...
With more and more companies only effectively operating on-line this is going to become more and more of a problem.
Unless you use Microsoft 365 that appears to totally fall over if you put a space at the beginning of a password. On perm AD works fine with that, but once it gets to Microsoft 365, it freaks out won't let the user login to e-mail. All because of a pissing space at the beginning of the password.
Note that it's possible to have nonsense phrases that are grammatically valid, which might help with memory, as in: "Colorless green ideas sleep furiously." But, don't use that one, as it's a quote of a certain famous linguist. (And no, I wouldn't include the spaces either.)
>Note that it's possible to have nonsense phrases that are grammatically valid, which might help with memory...
Another part of my early 1980's Computing degree that is still current :)
I tend to use this style of passwords for those accounts that it is helpful (ie. less irritating) to 'remember' short-term but not long-term. For example the SysAdmin account: for the few hours I'm working on something and swapping between accounts this style of password - in part because of the imagery and humour is relatively easy to retain and thus enter, compared to the typical random password which may be shorter but always requires you to look up, even if you had only used it a couple of minutes previously, and thus distract from the main task at hand.
Use passphrases, not words, "AworldinwhichIdieonTuesday" is stronger in basically every way when compared to "trump3t"
On private services I find the password length is often limited, so no joy. And on corporate systems you've always got your company's ITSec brainiac imposing rules about changing every one to three months, demanding mixes of upper case, lower case, special characters, numbers, no repeated characters etc etc.
When the company want proper password security, I presume they'll come up with better rules...
rules about changing every one to three months, demanding mixes of upper case, lower case, special characters, numbers, no repeated characters
Aside from the last, none of those should be any real impediment to using real-world passphrases. It's quite easy to construct natural-language phrases which "naturally" (i.e. in a manner familiar to a reader of that language) include mixed case, punctuation, and numerals. And memorizing such phrases is not particularly difficult, so having to change them periodically isn't a problem either.1
One technique is to choose words at random from a dictionary until you can assemble a phrase in the style of a newspaper headline; then add a numeral and some punctuation. For example, here's a few I selected from a list of words I extracted at random from aspell's US-English dictionary:
Norrie's, cashier, unstable, syphilis, unmanageable, newsreel, show
I just chose those from the first screenful, in about 10 seconds of looking. From those I could make:
Cashier Norrie's unstable syphilis unmanageable; newsreel shown at 11:00
That's shouldn't take much effort to memorize, and the use of capitalization, punctuation, and numerals is natural.
Now, that doesn't have a ton of information entropy. With Shannon's estimate of around 1.5 bits of entropy per English letter, we have only "about" 110 bits at best from the text. Since the capitalization is natural, an attacker who knows our scheme (Kerckhoff's Principle) can guess those, so that adds nothing. Similarly the use of numerals and punctuation isn't contributing a lot.
Now 110 bits still sounds pretty good (much better than that 8-character NTLM minimum password), but some experts think Shannon's estimate is too high in this context, particularly if attackers apply well-trained models to the problem. Someone who duplicated my aspell-based dictionary (around 150K words) and tagged them with part-of-speech information, then trained a model on plausible headline-style phrase structuring, could narrow the search space down quite a lot.
Still, if you really want passphrases you can memorize, you can accommodate quite a lot of those largely-pointless password restrictions. The tough ones are length limitations and especially idiotic prohibitions like the one on repeated characters.
1And, of course, you can always use a passphrase manager blah blah we've all read a thousand posts pointing this out.
All very well but why does one of the most commonly used cloud services, office 365, limit passwords to just 16 characters? Barely enough for two short words and a number. Correcthorsebatt.
It’s not good enough.
And why are the default system-generated passwords on office 365 of the format 3 letters plus 5 numbers with the first letter always being upper case?
why does one of the most commonly used cloud services, office 365, limit passwords to just 16 characters?
Because the Microsoft Office 365 team are a bunch of idiots, presumably. (I note that Microsoft Forefront Gateway also used to have this problem, and may well still have this problem. It's unacceptable.)
Fortunately, at my place of employment we use SAML authentication to Awful 365, and our authentication mechanism allows reasonable passphrases.
There's no reason to ever restrict the passphrase length to any unreasonably short value for a web-hosted service. Even if the backend system has a password-length restriction, you can create a verifier using a decent PBKDF (bcrypt, Argon2, etc), then transcode that into the character set accepted by the backend system. You may well have to truncate the verifier, but that doesn't help an attacker all that much because they'll still have to find a prefix collision, and good PBKDFs are expensive to compute.
Much as I tend to agree that a memorable long password beats a non-memorable short one, I can’t help but worry that these aren’t really that much stronger. Yes, there are (apparently) upwards of 170,000 words in the (Oxford) English Dictionary, making this on paper appear to be 170,000 to the power 4 (a roughly 70 bit number) but the reality is that most educated native English speakers only know a fraction of this number. Assuming a 35,000 word vocabulary (a number I’ve seen mentioned as an upper bound on real vocabulary size), this quickly reduces to only 60 bits. Assuming all 4 words are fairly common, as with “correcthorsebatterystaple”, the vocabulary size required falls to less than 10,000, rendering this weaker than the random 8 character (53-bit) password, though obviously more memorable.
Another issue with the long password, and one I’ve fallen foul of many times, is whilst they are fine when typing on a real keyboard. Try entering one with your thumbs on a phone screen, or worse, using a PlayStation / Xbox controller and they start feeling less of a great idea. Even more so if there’s a risk of shoulder surfing (the extreme case is with the PlayStation / Xbox), where the random mess of letters and numbers is relatively quick to type and tricky for an onlooker to remember. A set of English words, they may struggle to forget even if innocently observed.
My personal favourite scheme (though I must confess, not one I always employ) is taking initials from a memorable sentence. Ie, the password “ihpcrbtmplm”, can be simply remembered by the phrase “i hate password complexity requirements because they make passwords less memorable”, which is roughly the same strength as each of the above mentioned schemes but obviously quicker to type than “correcthorsebatterystaple” and far easier to remember than “ff3sd21n” (which, being all numbers and lowercase, I can’t see being much better than 41 bits anyway).
You are correct, if users choose the words then there is a big reduction in the name space on offer. My password generator extracts random words from /usr/share/dict/words and combines them with a few digits and punctuation characters. Very often I get words that I would never have chosen myself, or didn't even know existed. It is tempting to try generating another password with something more memorable, but then you are "playing with randomness", which defeats the purpose of using random words. Instead, I look the word up, learn something new, and that process seems to make it stick in my brain. Who knew that "calp" is a type of limestone, dark grey or bluish black in colour, that is found in Ireland?
The XKCD example already takes dictionary attacks into account. It gives 44 bits of entropy from 4 words, hence is based on a dictionary of 2024 words. As it happens, 44 bits isn't a lot nowadays. Bigger dictionaries will give stronger passwords, as will using more words.
I find multi-word English phrases much easier to enter into limited devices than random assortments of symbols. The latter I have to look up and enter one character at time, where-as a word like "horse" I can look up once than enter the whole word from memory. Even "ihpcrbtmplm" would make me stop to think for each letter. Not having to switch to weird symbol keyboards helps too. These phrases are also easier to tell other people, eg if they need to know your WiFi password.
" Bigger dictionaries will give stronger passwords, as will using more words.... multi-word English phrases..."
Of course simply using multiple languages can quickly multiply the available dictionary space without significantly increasing complexity. Many native English speakers are hampered in this regard by not knowing any other language but most people worldwide know at least 2 languages to draw words from
"Many native English speakers are hampered in this regard by not knowing any other language but most people worldwide know at least 2 languages to draw words from"
I'm English, so I like to use passwords like cul-de-sac, boulevard etc. That really stumps the crackers.
As a small company, for many years our network admin password was "hello" which worried me.
When we were taken over by a larger French firm with a proper IT department I was looking forward to an improvement but discovered their admin password was "bonjour"
We know have a 12 digit admin password with caps, numbers, special characters etc. It is impossible to remember so obviously easiest thing is to write it on a post-it note and stick top monitor :-)
I am currently using a passphrase built out of:
two words, neither of them from the English language and usually from two different languages, but which I remember quite well 'cause I know what they mean in English; my current words add up to 12 characters.
two numbers
one special character
That's 15 characters, total. I don't use the same two numbers or special character, and vary the order of the two words and change the words themselves every now and again. I write down a passphrase hint (two alpha characters, one for each word, two different alpha characters for the numbers, and a different alpha character for the special character) so that _I_ know which passphrase I used this time, and carry around that list; the master list showing what alpha characters mean what is securely locked away elsewhere (y'all don't need to know where; those who do need to know also have instructions as to where to go to find it in an emergency). Without the master list, the passphrase list is useless. (quick: what passphrase does er wi o represent?) and that's without considerations as to the number and position of uppercase letters and the order and location of the numbers and special character. (The alpha character used tells me the order and location, thanks to the master list. Oh. Wait. Others ain't gonna have the master list.) Making the passphrase longer (and usually stronger) merely requires using longer words or more numbers or special characters or some combination.
I find 15 characters to be easily remembered, especially after a look at the hint list, while being difficult to crack even for a native speaker of the languages in question. And I complicate things by using words from two _different_ languages. I went to uni with, among others, native speakers of Lakota, Urdu, Farsi, Japanese, and Tagalog and I have found certain phrases in those languages (and others; Arabic is really nice to have around when you want to curse someone out) to be quite useful.
But now I know your plan, while I brute force guess your words as phrases password I'll add trivial complexity by testing whether you have used the initial letter of the phrase rather than the full phrase...
And while I'm on it... in what percentage of 8 character Upper/Lower/Punctuation passwords is ! the 8th character?
If you're worried about humans picking the words - I use watchout4snakes. Get about 10 random words, and pick 4 or 5 that make a vaguely intelligible phrase. I don't know the size of their dictionary but my random 10 just now included theorem and pedantry.
Where good password rules (i.e. none) are enforced, I use correcthorsebatterystaple. Where bad password rules are enforced, I use correcthorsebatterystaple1!. This means if I remember my password, but can't remember the ruleset, I have a 50/50 chance of getting it right first time.
Struggling with some of the assumptions here.
For instance if you know that the passphrase is composed of dictionary words spelled correctly then you can calculate the time to brute force based on using all the dictionary words and gradually building up the length and complexity.
However if you don't know then presumably you also have to brute force a string of random characters to the same password length. Possibly some of the examples assume that the first thing you do is a dictionay attack (but to what length of characters?) followed by a random character brute force.
I think that this was what the XKCD example was based on - making remembering long strings of characters easier.
If, for instance, you picked one set of 5 non-dictionary characters, say xf-r@, and inserted this into all your password strings then possibly a dictionary based attack would fail. Again I assume this is some of the point of requiring punctuation in a password.
I would be interested in the entropy of, for example, correcthorsexf-r@batterystaple given that you don't know that it is mainly a dictionary based phrase and you don't know the length or location of the non-dictionary string.
It is easy to work backwards if you know the answer. Assume you don't know the answer for a more accurate result, perhaps?
>I would be interested in the entropy of, for example, correcthorsexf-r@batterystaple
Useful calculator here: http://rumkin.com/tools/password/passchk.php
But you aren't really comparing like with like, given the different lengths.
I think this is where maths and the real world diverge.
My understanding is that the entropy of "correcthorseb@tterystaple" and "correcthorsebatterystaple" is the same where the permitted charactersets and rules are the same.
However, just as Bletchley Park realised, people are human and so there are ways to reduce the entropy based on statistical analysis and assumptions ie. most people given a large characterset will constrain themselves to the alphabet and real words. Hence your outline dictionary attack could result in a password being revealed much quicker than the entropy calculations suggest. The only problem is that your reference lookup table of passphrases does, relatively quickly, become rather large and unwieldy...
However, I anticipate, given some of the comments here, that it won't be long before dictionaries exist for the more common (and shorter) passphrases.
Smartphones are a problem, and will be as banks, credit card companies and retail stores push towards their use. Entering long passphrases with combinations of <shift> keyboard special char, long hold-select is cumbersome and error prone. A few websites have started to have an option of 'show password text', but on mobile apps? Umm, no. I still don't know where or how passwords are stored on these phones, but it's convenient to check 'yes, store this password for future use'. Multifactor authentication on smartphones is even more cumbersome since (I'm guessing) it involves task switching, selecting a text string, copy, task switch back and pasting. Hardware authentication like Yubikey? For a while Apple wouldn't even give the outside security firms specs so they could design something that would work with their products.
Is there one magic bullet solution to online security? I haven't seen one. But, articles like this are good if it gets us to change how we protect at least one high value asset.
"Entering long passphrases with combinations of <shift> keyboard special char, long hold-select is cumbersome and error prone"
It's a pain on smartphone
It's a huge pain on the office photocopier where I have to log in every time I want to scan anything
It's a gigantic pain on a TV interface where you have to use the remote to go over every character and press OK for each
??According to Tinker, it's still used for storing Windows passwords locally or in the NTDS.dit file in Active Directory Domain Controllers.??
If you are using a Win2K server, Win98 clients, or Samba servers of similar age??
As I recall, not on Win 2003 server unless you deliberately enable it ?
AFAIK, the main reason for choosing to enable recording the NTLM hash in AD is so that password crackers can decode short passwords?
Okay given NTLM is the default option now on Windows Server the question has to be: what is the time taken to crack longer passwords ie. to rephrase the articles sub-text:
Password1 once again more secure and memorable than ff3sd21n
Caveat: in the context of the HashCat cracking approach demonstrated here.
If you're using a "recent" (as in, 2008+) AD and only allow Kerberos, according to an old Technet article the passwords are stored like this:
"AES256_CTS_HMAC_SHA1_96, AES128_CTS_HMAC_SHA1_96 - Used for Kerberos authentication since Windows Server 2008. Salted with user logon name and hashed 4096 times using HMAC-SHA1."
This post has been deleted by its author
Almost all of the memorable book and song titles and most of the lyrics are already in the hacker dictionaries.
I did this experiment in about 1992 with many thousands of people. We had them enter 5 different lines of lyrics from songs. We also asked them if they listened to both types of music or rock or something else. It turns out that the people who picked rock or country would often pick one of the same hundred to so lyrics. If we asked a country fan to quote 5 rock lyrics, it resulted in a much larger pool. The results would have also allowed high accuracy guesses of the subjects children's ages if they had small children.
Something I don't get, and perhaps someone can enlighten me. How does this even work? Any time I type in a wrong password 5 times, my computer locks me out for 5 minutes. After that 5 minutes, do it wrong 5 more times and it's 15 minutes. Howncan they run through umpteen dozen thousand wrong passwords in a couple of hours if 5 wrong passwords locks you out for 5 minutes?
Have you ever tried to guess the shape of an object from its shadow? , it's the same sort of thing but with numbers and an odd form of math called Modulo arithmetic. The attacker can see the shadow of the password and generates billions of combinations till it finds a 'shape' that matches. Then and only then is that combination tried against the target computer.
They aren't typing the password in multiple times. They have already stolen the password, it's just that it's in an encrypted form. What they then do is try to find the original password (or even a different password that would give the same result when encrypted!).
They can do this by trying every possible password one by one (against the same encryption method) until the encrypted result matches. So they start by trying 'a' then 'b' then 'c' ...a loong time later.... then 'Abhg75^&%fgtrds'. All these encryption methods cannot simply be reversed. ie. they are one-way so you can't just enter the encrypted (hashed) password and get the original plain text password as the plain text password no longer exists in any form. However some encryption schemes have vulnerabilities in the random number generator or method used that can reduce the number of attempts significantly. They might also demand a minimum of 6 characters so the attacker doesn't need to check for passwords less than 6 chars. However they would normally start by checking a dictionary list that would contain popular passwords, all the passwords from major breaches, all the words in a dictionary, every birth date, peoples names, including multiple capitalisation, swapping letters for common symbols (such as pa$$w0rd) etc.
In then end they may get a match for the password (and - it doesn't always need to be the exact same password, but nowadays it normally is, it just needs to produce the same output when encrypted). They then use this password to log in on their 'first' attempt.
How do they steal your encrypted password? Well either they have access to your PC/Network and have dumped the 'encrypted' password file or more likely they have stolen it from a website or intercepted it when sending it remotely.
Which happened to my son. I couldn't understand why his Fortnite account kept being hacked, even after changing the password numerous times, each with an increasing level of complexity and length.
Turned out his email password was a. weak and b. compromised and so the hackers just kept hitting the forgot password link whenever it got reset.
Cue a forced reset of all of his passwords by me.
Another reason why your email address is your username is A Bad Thing[1].
Unless you use a DEA system and register a different email address for each site ;)
That also makes it easier to see which site has been compromised.
Another reason why your email address is your username is A Bad Thing.
That's highly dubious. Kirckhoff's Principle applies: assume everything not part of the secret is known to the attacker. Otherwise you're just adding a small amount of hard-to-manage entropy to the key.
If not using an email address as a username is providing you with any significant additional security, then there's something very wrong with the security of the system you're using.
This post has been deleted by its author
@ DaLo
At the risk of teaching the occasional grandmother to suck eggs, I feel the urge to correct a few errors in your post.
Encryption entails a (roughly) 1 to 1 relationship between plaintext and ciphertext. i.e for every character in the plaintext there should be at least one in the ciphertext (ignoring compression)
Cryptographic hashing produces a fixed length output regardless of the size of the input. Using SHA256, for example, anything we hash will produce a 32 byte hash - whether its your 8 character password, or War and Peace.
One consequence of the difference is that hashing algorithms are NOT vulnerable to poor quality entropy (eg the output from weak Random number generators). If they used randomness at all, they wouldn't work because the hashes for a fixed input would usually vary.
Bcrypt is the exception to that rule. It is optimised for password handling. For example maximum input length is (from memory) 256 characters. And it does include randomness and thus always produces a different hash for a given input, which, amongst other things, means you can't test a Bcrypt password simply by repeating the hashing process. You need a partial decryption process which reads a section of the hash to determine the randomness which produced it, so it can verify the input against the output.
And bcrypt passwords can even vary (slightly) in length (which confused the fuck out of me when I was learning how to use it) and doesn't run the hashing process once but, typically, a few thousand times (user configurable). All these tricks are how bcrypt makes Brute Force attacks thousands of times more time consuming. It SHOULD, by now, be the standard hashing technique for all passwords. If the NTLM passwords were Bcrypt hashed, they'd still be safe!
They have already stolen the password, it's just that it's in an encrypted form
Sigh. Hashing is not encryption.
While there are certainly cases where password verifiers are encryptions of the plaintext password, it is much more common, and greatly preferred, to use verifiers which are derived from the passwords in a manner which cannot be reversed except by brute force.
Salted cryptographic hashes are often used for this purpose,1 but for years now we've recommended password-based key derivation functions PBKDFs such as PBKDF2, bcrypt, and Argon2. The best PBKDFs for this purpose are the ones which are designed to be both compute- and memory-intensive, making it difficult to execute them quickly using GPUs or custom hardware.
Aside from that, your description, while it describes offline password cracking correctly in broad terms, is rather behind the state of the art. Attackers won't try possible password-character combinations in order; they'll use dictionaries of known common passwords first, and then try less-likely variants. Often they'll have precomputed rainbow tables to speed the search. And for offline attempts, they'll be attacking a database of verifiers - verifiers are rarely sent over the network, so it's unlikely an attacker would have have "intercepted it".
Of course, some applications continue to use trivially-broken verifiers, such as unsalted MD5 hashes. A Google search has an excellent chance of returning the preimage for an MD5 hash of an English word.
1And before that, other things. UNIX originally used an encryption-based mechanism (first using the M-209 cipher and then a modified version of DES); but it used the password as the key to encrypt a fixed block, and then chained that for a number of rounds, injecting a salt value into the cipher. So the verifier was still in effect the output of a cryptographic hash of the password. NTLMv1, on the other hand, used an algorithm so stupid I can't even bear to describe it.
You may be confusing someone attempting a Brute Force / Dictionary / Guess attack with Password Cracking.
As you describe it, the process of throwing multiple of variations of passwords at a login page, with the hope of getting the right combination of username and password is generally referred to as a Brute Force attack. The methods vary, like using a simple password list (dictionary) or using a tool which creates variations of different passwords by substituting letters with numbers, special characters etc. Could also be a case of someone sitting at your computer and manually trying different passwords. Doing this against a system that gradually increases lock out times with each unsuccessful login attempt does make this difficult.
What they are referring to in the article is Password Cracking. The specific example in the article speaks to taking a password hash (the result of using a specific algorithim to turn a normal password into gibberish) and using a tool to brute force it (try every hash combination for the size of the password), or use a rainbow table (a list of precomputed hashes) and simply compare the results until they get a match.
Doing it this way is a much faster way of getting someone's password, but requires either capturing the password hash in transit (like capturing the authentication traffic while you log into El Reg for example), or in AD environments (for example) dumping the password store for offline cracking.
The crux of the article is that an 8 character password hash, hashed by NTLM, can be cracked very quickly, and affordably.
Hope that helps
Just to extend the excellent replies I'll add that computers don't normally store your password and compare what you have entered with that. Instead when you enter your password for the first time they run it through an algorithm that converts it into something completely different. That's what they store.
Every time you log in they take what you have entered and run it through the algorithm and compare the result with what they have stored. Thus no at least half way sensibly written system has a record of your password. This is great because if the system is compromised your password is still unknown.
Password hacking as others have said is the process of finding 'some text' that when run through the same algorithm produces the same value. Once they have this they can log in using 'some text' as the password.
>Time to go through my LastPass list and change the 8 char passwords that still exist (and there aren't many left now) to 12 char passwords.
While you are about it, strongly recommend you setup the account recovery security on key accounts. For a client I was glad I had done exactly that, they were using an old (ie. pre-2007) edition of Outlook, naturally in response to a Google prod about security they clicked the "improve my security" option which immediately blocked their Outlook client, this, in turn, continued to try and log in and fail, resulting in Google deciding that too many login attempts had been made and so locked the account. Also advise setting at least two phone numbers - client had originally used their PAYG mobile numbers, but for various reasons hadn't used that phone for 6+ months, fortunately, they had also set up their house landline number which hadn't changed...
Thanks for the most excellent replies, folks. That makes a lot more sense than the whole "try over and over" thing. A bit scary too, that they can get access to a string of characters that they can work over until they have a match, then log into an account first try. Methinks I will need to change important passwords more often. I've already been doing the multiple unrelated words for years, use the less common special characters and keep my passwords on a list only people who get into my house can access. In addition, my security questions have zero accuracy so anyone who knows me can't guess. They might know where I graduated high school, but that won't help them know that my security question "Where did you go to high school?" is answered with "quicklime and carpet."
Going to have to assume that they have some powerful computers, or perhaps using botnets lets them crack these passwords in considerably less time than days per password, like that horse password is suppposed to take 18 days. Sorry, I'm just not a computer guy.
the sites that bug me (and there are a few banking sites that do this) - are those that have a MAXIMUM password length.
so I can only use a 12 or 14 character password - mine tend to be 20+ characters long when I want something secure, and around 15 for the sites I am not giving any financial information to.
Also sites (usually financial institutions) which ask for specific characters from your password, thereby betraying that they actually store your password in plain text.
That's a thought that had literally never crossed my mind before. You surely must be right - I can't see how else they could do it. But it's a hell of a stupid thing to do.
El Reg - why don't you ask First Direct and Santander (two that I know of who do indeed ask for specific characters) to comment on this? No point in a normal customer asking the question, we'd just be fobbed off.
"thereby betraying that they actually store your password in plain text."
You're assuming that the only way to hash a password is as a single hash.
What they can do is produce a series of hashes of a few select characters and then ask for one of those selections. It has the disadvantage that if all permutations are stored the number of hashes to store expands very quickly as the password length grows. This means that either they have to pre-compute and store a large number of hashes, restrict you to short passwords or only store a small subset of permutations. Guess which is least likely.
My problem with the 'enter the 4th 8th and penultimate character' sites is that you've got to remember the place value of each character or resort to counting on fingers.
Quick, what's the 9th, 13th and 18th character in correcthorsebatterystaple (without resorting to fingers)?
If you let people use longer passwords, then you can't synchronize your older, legacy platforms (which seems like a bad idea to begin with). I remember having to choose a short SSO password at an employer because of some rules they had for their legacy Unix systems.
Worse yet, some of those sites limit the password to under 8 characters. It's almost like they are using an old miniframe* with a web front-end slapped on it or something... at least it allows for complexity, which at gives some modicum of difficulty in this day and age.
I can understand why- processor time used to be expensive, and crypto is processor intensive. That was before Moore's law and parallel processing kicked in proper-like and made CPU cycles cheap. (remembers running L0phtcrack on a machine's NTLM database overnight back in the early 2000's to extract the admin password on a win2K server when the original admin password was lost/misplaced. it got everything except the contact person's password, which required it to brute-force attack.)
* iSeries, I'm glaring at YOU.
Worse yet, some of those sites limit the password to under 8 characters. It's almost like they are using an old miniframe* with a web front-end slapped on it or something
Not an excuse. See my post above: It's trivial for a front end to overcome this sort of limitation in the backend system. You hash the password, transcode it into the backend system's allowed character set, and truncate if necessary. The attacker still has to find a prefix collision.
I believe RACF has a password character set of at least 64 characters, so you can use Base64 tweaked for EBCDIC and encode 48 bits of entropy in an 8-character password. That's decent; it'd take quite a lot of resources to find a preimage for the first 48 bits of an Argon2 hash.
When you see a web front end that only accepts 8 character passwords, it's a sign that the application developers don't understand security and couldn't be bothered to find someone who does.
Surely it's "correct horse battery staple"?
"correcthorsebatterystaple" misses 3 special characters.
For a decent memorable password pick a phrase with punctuation and type it in exactly.
"I should be so lucky, lucky, lucky, lucky"
Or
"I ain't gettin' on no plane fool"
Or
"My wife's birthday is 14/14/14"
Everyone says "don't use a birthday or anniversary" but if you stick in a sentence like that, ain't nobody gonna crack it fool.
I wonder if you used more exotic extended characters than what is available on the keyboard such as ὭӔꙬΘ whether this would make a 8 character password harder to crack?
My standard login password is 13 characters but maybe time to change to a passphrase. I saw a good article where someone mentioned about opening a book onto a specific page and then creating a passphrase from the page number, and then the first word on say the top 6 lines intermixed with a special character.
So doing that from a electrical parts catalogue I have on the table gives me a passphrase of:
222Long-domestic-paths-Polycarbonate-Lumens-LEFULLWH
When hashed, passwords are usually treated as simple sequences of bytes - not characters. So what sequences a password actually is depends on what character set is using. If a password entry filed allows for Unicode character, and is using, say, UTF-8, using characters that use 2/3/4 bytes will make it actually longer. If it uses an 8 bit code page not MBCS, it won't.
Then depends how smart the password cracking algorithm is - if it just attempts sequences with valid ASCII7 printable characters it may not hit some password, it it just generates and hashes plain sequences of bytes it will found anything within its processing capabilities.
I use password manager-generated passwords of random characters and symbols for website passwords that I can fill again from the password manager, but there are some passwords that I need to be able to type in manually - typing ks£94!_lkF0#- with a Playstation controller is difficult (and even harder over the phone to the kids).
For those occasions, I use a set of 5 dice and EFF's Wordlist [1] to construct a passphrase. This means I can still remember the individual words long enough to type them in, whilst the passphrases are appropriately random.There is something satisfyingly old-school about creating secure passwords using a dice and sheets of paper.
1. https://www.eff.org/dice
No, the sheets of paper are the lookup lists. The resultant passwords are stored in a password manager!
Mind you, I would rather my aged relatives used unique passwords for each website and wrote them down in a book than use the name of their favourite son-in-law for everything!
Much more secure for most domestic purposes. If your house fire destroys the safe contents, just reprint from digital backup. If burglar finds and breaks the safe to read it, just ensure they don't have a clue what they're looking at. Obviously don't tell anyone your unique scheme. Your random PIN for your bank card might be useful to use to select the same page and word number from a favourite book. Or memorable date read long ways like FirstJanuaryNineteenEightyFour. You're welcome.
A long password for your online banking is obviously sensible. For other stuff not so much - at work my Windows PC locks itself after 10 minutes and I don't fancy typing wrongdonkeyAAcellfastener dozens of times a day. As correctly pointed out by Time Waster strong passwords are a strong nightmare when not using a proper keyboard. Finally a password manager - you're stuffed when you have to use a computer which hasn't got it installed.
>Why would you ever type a password into a computer that was not your own?
Work?
Also I can't be bothered to jump through the hoops that are required to get 1Password/LastPass etc. to work across all my devices: Win/OSX/iOS/Andriod/Linux.
One of the things I dislike about new phones, printers, etc. is connecting them to the WiFi for the first time - so that they can be set up properly - My WiFi uses a 32 character PSK...
Basically, this only goes to confirm what the banks have known for ages: passwords are not a secure way to limit access to anything. To do it securely, you need:
An identifier
A secret
A physical token that you can verify possession of
Hence OATH protocol devices such as Google Authenticator; these are all devices that generate authorisation codes when asked to, and the authorisation code is verification that the intended user has possession of the code-generating device. Some banks even force the end user to remember a secret code to make the authorisation token spit out a code, for added secrecy.
If you do this, you make the stealing of password hashes pointless, since you also have to steal or otherwise access the OATH token generator. If you make the item to be stolen valueless then thieves will simply try something else.
Basically, this only goes to confirm what the banks have known for ages
Trouble is that marketing and the necessity to snoop on their own customers is killing the good experience they built over the years. Most of the banks are phasing out tokens and PIN sentries in order to force their customers to install mobile apps on their smartphones. I think the future is bleak, eventually a wave of trojan based attacks will push one or more of those banks into bankruptcy.
EDIT: I forgot to point out that I don't believe in OATH and other centralised systems that are just a big enormous honeypot for all sorts of hackers. The only safe system for banking and online payments in the PIN Sentry model.
OATH is fine as a second factor but it lacks enough security to stand on its own. It's easily for TOTP to fall to a machine-in-the-middle attack. HOTP looks fine theoretically, but the re-keying after failure is deeply problematic.
Having written this, OATH TOTP is far better than nothing, SMS codes, or an 2FA app. There's some fine clients, not just Google Authenticator. For example, andOTP has no Google-derived code but was written from the specification.
I'd recommend that people look into a secure hardware token. One which does FIDO/U2F for second-factor authentication, FIDO2/Webauthn for account authentication, and does HMAC-SHA1 Challenge Response for securing password databases. Yubikey are the dominant company in this space, but there's a handful of alternatives.
The hardware token provides key material for the password database. Maybe mix that key material with a trivial password so that a lost key can't be used immediately. The result is strong: the token challenge-response and password generate the key material needed to decrypt the password database, and the password database contains maximal-length, actually-random passwords for the websites which need passwords. KeePassXC provides a good implementation, but there are plenty of alternatives.
When configuring websites for FIDO/U2F second-factor authentication be careful to disable weaker 2FA alternatives which the website may also offer, such as SMS codes.
Finally, note that OATH's MITM shortcoming when compared with hardware tokens isn't always a weakness. I use OATH for some accounts as I may need to share the account (eg, some vendor websites only allow one account per client company) or where I may need to read the code over the phone for someone else to log into the account. For those accounts OATH provides better protection than a password alone.
NTLM was made backward compatible with the older MS Lan Manager (P O donkey S) and had a separate LM hash table which used passwords split into 2x 7 char blocks & padded with nulls. Dictionary attack times for the 7 chars was never very long and if the 2nd block was all nulls it gave the same hash every time. I believe the backward compatiblility could only be turned off once the entire AD domain was using NTLM2.
This was back in the early '90s when DES (56 bit) was standard and the US didn't allow export of anything better than 40 bit.
Some things scar the memory for life.
Anyone who writes a database where its possible to SELECT from the hashed password tables is an idiot. Last time I set up a password system the salted hashed password challenge was sent to a stored procedure that could only return a 1 or a 0, and select functions disabled on the table. Note I am not a software engineer or a security expert, and if I can do it...
Usually, an attacker has more than a database session (if they do, it's unlikely they have one with rights to the password table anyway). If they have access to the disks or the shell, they simply take a copy of the files implementing the database and open them at their leisure. Your solution only helps if they are able to get a database session and nothing else, and a proper database for passwords shouldn't allow remote accesses anyway. It's a nice tweak, but probably won't solve much.
I have passwords based on a phrase giving me a 15 character string (mixed upper case, lower case, numeric and special characters). When I need to register on a site that requires a secure password I apply a prefix or suffix to the base string. I only need to note down the prefix or suffix as the 15 characters is locked in my head (e.g El Reg could be noted as ER_ or _ER). The system does require a bit of tweaking where passwords must be shorter than 17 characters.
I always point people to the XKCD when they extol complex passwords, and always use pass phrases where possible.
It grips my shit when sites then LIMIT you to 8-20 characters (I'm looking at you NS&I), prevent you using spaces or certain special characters. What god-awful sort of plain text, crappy storage are they using behind the scenes to warrant that downright negligence. Arseholes.
The XKCD algorithm seems suspect to me. Its basic assumption is that people can make a random choice of common words -- without reference to a dictionary and without using any random number generation.
I just asked 15 coworkers to give me three random words -- there were 7 words appearing twice and two words appearing four times. This sample suggests that the size of the in-practice word pool may be small.
Given the skew in lotto number selections, we know that humans can't make random choices from a pool of ~50 selections even when it is in their financial interest to do so.
Given the apparently small size of the pool and human's poor ability to choose randomly, I suspect the in-practice XKCD-algorithm key size may be substantially less than that suggested by the author's back of the envelope calculation. I'd want to see a controlled study before recommending its use.
From another angle.
Part of the problem is that every fucker wants a password. I can remember a strong password. Or three.
So, what are the risks if my password is cracked for:
El Reg, or any typical messageboard. Apart from embarass me, or get me banned.
My utility account password (no card details saved)
A one off purchase from a site (again, no card details saved)
Or am i being naive?
NTLM? I can recall brute forcing NTLM pw from sam files in 1997 using L0phtCrack for NT3.51 and NT4. Any characters above 7 were discarded in the challenge so brute forcing it with a derelict 486 took me a night. Is this another NTLM or is this the still basically the same? For many years hacking MSos was kidsplay if you had access to the .sam file (as any user on running machine would).
Most of them unique, and many of them used maybe a couple of times a year.
No rules for password complexity, passphrases, or other similar solutions come close to dealing with the problem that I have to remember 203 of them, and I have to remember which memorable phrase was used for which site or account login. It ain't going to happen.
One of my banks supplies a dongle for two-factor authentication, and a few sites offer my phone as a second factor. But carrying round a keychain full of dongles is not going to happen either.
There is simply no alternative to a password manager.
There are 203 passwords in my password manager
So what?
dealing with the problem that I have to remember 203 of them
If you have a oassword manager it means you don't have to remember 203 of them.
There is simply no alternative to a password manager.
No, wait. You use a password manage, I use an encrypted partition and that's all right. But you can't assume that all PCs with a password manager are trojan free. Some credentials like those for online payments are too sensible to be put on a PC or even worse on a mobile phone (unfortunately too many banks lately are choosing this option). For them the only way os via hardware, be it token or PIN Sentry. If you pick out the most sensible like banking and unique ID for government services you don't need so many of them.
The requirement mentioned earlier about ensuring that your passowrds are not 'remembered' by someone watching you type it is not a problem for password managers.
When setting up a PC for my son I used his MS password about 8 times in several different cases across two PCs (old and new) as well as a phone.
Despite typing it that many times, I could not, under any circumstance, recall the password when trying to type it, even after a delay a few minutes.
This is because password manager passwords can be made eminently un-memorable; you would have to be the mentalist to remember 12 characters, case and all, just by watching someone type them.
I was typing from a displayed password and I still couldn't recall it.
Of course, we use 2FA so OneDrive etc. are even less likely to get hacked even if the correct password is entered on a new device, so the hacker would have to access the PC, steal the phone, know the phone PIN *and* have the password.
Hardly worth the effort to see his student debt (always assuming they managed to access the bank).
I think the honest truth is that £24 a year for four (I think) people to have LastPass is very good value indeed and it really does make site login (and address/CC details entry) super easy.
What was disappointing was not knowing if 12 random characters (with specials where allowed) is enough - from the looks of the article and the fact that NTLM is weaker than most systems in use - it seems so. I assume that it adds perhaps another 28 bits making brute forcing that much harder.
But how much is what I would like to know.
All these passwords are a PITA to remember & manage, even with password managers, yet despite this nobody has managed to come up with a viable secure replacement for them. Bio-metrics seems to have died away (apart from fingerprint login on your phone) and so called face recognition is very insecure since it's dead easy to fool. Besides, once someone manages to hack your Bio-metrics, you are well and truly f***ed!
Perhaps it's time to go back to a physical device coupled with questions and answers. The physical device is personal (ring, watch, rfid card) and it identifies you, but when you login it asks questions only you know the answer to. Now you just have to remember the answers to your questions and most importantly not give that info away on FaceTwit. If you lose your device it can be replaced and new logins can be setup. If you are the kind of moron who loses stuff all the time, then you get the device embedded in your body with a nail-gun :-)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
