Attackers Don't Bother Brute-forcing Long Passwords, Microsoft Engineer Says (therecord.media) 100
According to data collected by Microsoft's network of honeypot servers, most brute-force attackers primarily attempt to guess short passwords, with very few attacks targeting credentials that are either long or contain complex characters. From a report: "I analysed the credentials entered from over -- million brute force attacks against SSH. This is around 30 days of data in Microsoft's sensor network," said Ross Bevington, a security researcher at Microsoft. "77% of attempts used a password between 1 and 7 characters. A password over 10 characters was only seen in 6% of cases," said Bevington, who works as Head of Deception at Microsoft, a position in which he's tasked with creating legitimate-looking honeypot systems in order to study attacker trends.
Head of Deception at Microsoft (Score:5, Funny)
Now there's a sensible title.
Re: (Score:3)
There's actually several of these positions: one in Marketing, one in Standards Compliance, ...
Re: (Score:2)
Don't care. Me want that job title.
Re: (Score:1)
Don't care. Me want that job title.
Imagine if you're arrested for something.
Who do you work for?
I work for Microsoft.
What's your title at MS?
Head of deception
Cop - Very funny Mister.
Re: (Score:2)
Now there's a sensible title.
Title? I figured that would be an entire department.
Re: Head of Deception at Microsoft (Score:3, Funny)
Entropy makes long password guesses (Score:3)
Re: (Score:1)
Re: (Score:2)
Yes... you need a system that detects a similar password being attempted against multiple different usernames within the same system. If there are attempts to login to more than 10 accounts using the same password, then that password needs to get blocked from logging in for all usernames.
You can do that by recording the hash of all passwords attempted in a cache independent of username with the last few usernames it was tried against for a limited period of time with the amount of time determined by
Re: (Score:3)
Password1! (Score:2)
Everybody knows that to make a password secure you need to have a capital letter (normally the first) and a digit and a symbol (i.e. end with 1!)
Problem solved.
(This used to actually make sense many decades ago when some systems only had six character passwords.)
Re: (Score:2)
Yes... you need a system that detects a similar password being attempted against multiple different usernames within the same system. If there are attempts to login to more than 10 accounts using the same password, then that password needs to get blocked from logging in for all usernames.
Way back in the days of 2400bps modems and university VAX/VMS systems, my buddy was going to college and had an account on an internet connected mainframe that also had dial up modems listening.
They used a simple system for account names (LASTNAME_FIRST) so it was quite trivial to try mostly high potential account names. Simply went through three possible password per account at a time, over many nights, gathering several dozen over a week or so. Throughput was pretty slow, requiring a phone dial and 240
Re: (Score:2)
there are plenty of tactics to overcome that problem, e.g. rather than focus on a single account, the attacker might try 10,000 accounts all with the same top 10 passwords, a large percentage of people are dumb as dogshit when it comes to passwords.
Google for "salt". Using passwords without a salt is criminally stupid. And with a salt, there is no way to find out which 10,000 accounts have the same password.
Throw in some marketing and security buzzwords. (Score:2)
I've had some of my emails on data breaches, and I don't use the same password twice. If the failed login attempts from the mail providers are of any reliability, they may still try in regular intervals for up to two years. Though that's a sample size of 3, so mostly anecdotal.
Re: (Score:2)
and I don't use the same password twice.
It doesn't matter.. If one of the admins of the system your accounts were on used a weak password, or the the same password twice, or one of their servers got pwned, then your password or a hash of your password as a user of that system also gets pwned, potentially.
That's where "brute forcing" comes in - if only a list of password hashes got stolen and the hackers didn't modify the web application to capture real passwords,
then the hashes will be attacked b
Re: (Score:3)
I meant to say that the services that I used the email addresses for were breached, not the email services themselves.
Occasionally I get these bitcoin extortion mails in the spam folder where someone claims they've 'hacked' into my email account citing a password that they used, which is one that I genuinely used in the past. Then they claim that they hacked into my webcam (which does not exist on the machine I use to access th
Re: (Score:2)
Yep, there's nothing surprising here, but this result only applies to what occurs in online attacks. Offline attacks where an attacker has managed to secure a dump of password hashes is entirely another matter, and Hybrid + Brute force methods including GPUs or botnets are absolutely used in that area and Not At all measurable by systems like honeypots the researchers used.
Cool, I will just pad my passwords then (Score:2)
I wonder if this means that you can use a weak, easy to remember password, pad it out with zeroes to 40 characters and be safe because nobody will try to crack it.
Re: (Score:2)
Re: (Score:1)
It does remove the immediacy of "doing away with passwords", so championed by the likes of google and microsoft. So this guy is probably getting an unamused call from the head of propaganda soon.
Re: (Score:3)
This may blow people's minds but I just invented this right here on the spot. What if you take weak single word passwords then string them together in what I'll coin a "pass PHRASE". Get it. It's not a word, it's a phrase made up of multiple words!
Mark this day because you seen it here for the first time.
Re: (Score:1)
Welcome to Alec Moffett's 'crack' program from the 1990's.
Re: (Score:2)
If you're the only one inventing passwords like that, then you are likely safe from remote attacks. On the other hand, if anyone sees you type in your password, they'll guess it.
Re: (Score:1)
Or you could just use four words [xkcd.com] in a passphrase /s
Re: (Score:2)
I wonder if this means that you can use a weak, easy to remember password, pad it out with zeroes to 40 characters and be safe because nobody will try to crack it.
True, it’s not like 123456789101112131415 Is the kinda thing an idiot would have on his luggage lock - it’s far too long!
Yeah, kinda (Score:3)
I've analyzed many millions of login attempts from attackers over the last 20+ years.
If the system you're logging into will actually USE forty characters rather than silently dropping them, that would actually be a reasonably good strategy. Hitting the zero key, not trying to use the unprintable 0x00 byte.
*** repeated and other patterns of just one character repeated will get cracked, however.
It would also not be good to TELL people "it's a simple dictionary word padded out to forty characters using the zer
Re: (Score:2)
Since (in principle) you're storing password hashes, you should be able to take a password of any arbitrary length. Of course, not all sites do that, or don't do proper string handling for credentials.
(Since a lot of sites use javascript, why not perform the hash on the browser and have the buffer at the far end fixed length? If people insist on a limited number of bytes and/or don't want to slow the server down with hashing algorithms, this would seem to make more sense than truncating the password.)
Re: (Score:2)
Well as you suggest allowing 'any length' probably opens you up to potential problems even if its only a denial of service condition. Having the client do the hashing possibly works but you invite some potential problems that way too. Clients might be faulty users might tamper with things or just foul up trying to do stuff like script logins and might end up setting a hash value the not other clients can produce etc. Seems like a possible support issue. Additionally clients will then need to control the sal
Re: (Score:2)
"Any length" only works if the hash is client-side, since then the only person denied is the person attacking. You're right about the client-side problem, I'd been working on the assumption that all clients would execute javascript the same way and that developers wouldn't mess with server-supplied scripts (so the server would dictate the salting and other operations), although I admit that was not a terribly realistic set of assumptions.
Ok, if the buffer was set to 256, then that would allow 128 characters
The FIRST hash, not THE hash (Score:2)
You can't do THE hashing on the client side, then store THE hash.
If you send the hash to the server in order to get access, the hash *IS* the password. At that point you're storing plaintext passwords on the server, which is extremely bad. For security it MUST be hashed on the server. Otherwise when a bad guy is able to read some of the file / database on the server, the bad guys sees what they need to send in order to log in.
What you can do is hash it twice, once on the client and once on the server. In
Re: (Score:2)
How much extra entropy do I get for throwing a misspelled word into the passphrase?
Would stop dictionary attacks cold.
Re: (Score:2)
IDK because the summary is dumb AF. consider the statement "A password over 10 characters was only seen in 6% of cases" Well now if only 6% of password have over 10 characters then it's a fucking moot point isn't it. For the researcher to even had said that statement in the first place makes me think they're an idiot because the correct metric would be to say how much more likely a short password is to be attacked relative to it's frequency. Points to this being crap research that's stating the obvious - lo
Re: (Score:2)
I wonder if this means that you can use a weak, easy to remember password, pad it out with zeroes to 40 characters and be safe because nobody will try to crack it.
If I were the hacker, I wouldn't do this based on length, but based on password complexity. So your password will be tried after the six letter passwords, but before the seven letter ones. Now several passwords that I have do have a four digit number added as one component. Since I use a number that is unpredictable, it makes it 10,000 times harder to crack.
those pesky hackers (Score:2)
They know arithmetic and can do basic statistics.
Weakest link in the chain (Score:2)
Access through pop or imap is enough to try some stuff.
From there you can sit and watch, or send e-mails, try access some files, gain rights, use exploit code.
Welcome2021 and the likes, even as temporary passphrases should be punished by severe slapping.
And no, adding an exlamation mark at the end of a passphrase doesn't help.
Get MFA for your users.
Phew, though my fingers are tired. (Score:5, Funny)
My password is 7,000 characters. It takes me two hours to login at work every day ... Then another two hours after each time the company-mandated five-minute screen lock delay kicks in. All in all, I'm pretty productive though -- at typing in my password.
Re: (Score:1)
> My password is 7,000 characters.
That's called a private key. You're not supposed to type it in each time but you can protect it with a comparatively shorter pass-phrase.
Re: (Score:2)
That's when you just buy a Yubikey and stuff your password into that.
Re: (Score:2)
My password is 7,000 characters. It takes me two hours to login at work every day ... Then another two hours after each time the company-mandated five-minute screen lock delay kicks in. All in all, I'm pretty productive though -- at typing in my password.
You're obviously joking, but I had a colleague who once heard that every time someone's password expired they just increased the number on the end of their password (I mean we all do that). Except he misunderstood and *added* a number to his password. After a few years of this practice it was hilarious to see him sit at his computer typing "password123456789 0123456789 01234567", even more hilarious was the first time he was presented with a login screen that had a timeout.
That's when he told me his passwor
Length really does matter (Score:2)
Re: (Score:2)
Re: Length really does matter (Score:2)
Re: (Score:3)
Fleeing the bear ... (Score:5, Interesting)
Just like the joke about just needing outrun one's friend when being chased by a bear, as along as other users present easier targets, security in a relative sense exists. This is similar to how locked doors are effective, even though motivated or knowledgeable thieves can break those locks.
Re:Fleeing the bear ... (Score:5, Funny)
as along as other users present easier targets, security in a relative sense exists.
That's why I use password1235.
Re: (Score:2)
Re: (Score:2)
P@ssw0rd
Re: (Score:3)
I use hunter2222, with six more 2's after that. (Message to slashdot admin: your mom looks like ascii art)
password1235 (Score:2)
Amazing! That's the same password I use! ;)
Re: (Score:3)
Wow, if you type in your password it shows as asterisks.
I saw that on my screen as "That's why I use ****"
That's amazing, it must be filtering passwords.
Can you see mine? I use ****
. /credit to BASH.org. I am not that creative.
.
.
.
.
Re: (Score:2)
NordPass just did a survey of leaked passwords world wide. Some interesting stats.
One thing that stood out is that English speaking countries tended to be the worst for using weak passwords, and those that use non Latin scripts for their native languages did the best. That could be down to the way the data was collected, but equally the crackers are probably using dictionaries with mostly English and other European languages in them.
https://nordpass.com/most-comm... [nordpass.com]
Re: (Score:2)
NordPass just did a survey of leaked passwords world wide. Some interesting stats.
One thing that stood out is that English speaking countries tended to be the worst for using weak passwords, and those that use non Latin scripts for their native languages did the best. That could be down to the way the data was collected, but equally the crackers are probably using dictionaries with mostly English and other European languages in them.
https://nordpass.com/most-comm... [nordpass.com]
Where on the website does it conclude that "English speaking countries tended to be the worst for using weak passwords"? The list of passwords from English and non-English speaking countries look equally weak to me. 123456 seems to be a universal password regardless across all countries.
Re: (Score:1)
I think you'll find that the farsi, arabs, and jews use 654321.
Re: (Score:2)
You have to view it on desktop, not mobile. Scroll down a bit and there is a map of the world, with countries coloured according to how often passwords are leaked.
It's not all English speaking, quite a few European countries are in there too, so more like Latin character-using and familiarity with English terms. For example, in Japan "password" is very popular, despite that not being a Japanese word.
It's also interesting that Russia has the highest number of leaks per head of population. We tend to think of
Re: (Score:2)
Re: (Score:2)
I always remembered some 30 years ago now a news report about a club that had been broken into in the early hours of Christmas Day as the takings had presumably not been banked.
The thieves had taken a sledge hammer and gone through the brick wall of the building.
Eight character passwords (Score:5, Funny)
(Nick Helm joke)
Re: (Score:2)
Cool, you even managed to get a number in there as well :)
Re: (Score:2)
If you act surprised it meets the special character requirements too. Snowhiteandthe7dwarfs!
Re: (Score:2)
Just use & for the and.
Re: (Score:2)
*facepalm*
still a lot (Score:1)
Obligatory xkcd (Score:2)
Haystacking (Score:2)
Steve Gibson has a neat method of creating difficult to crack passwords. A bunch of repeated characters.
So "Password" becomes "Pass--word" but with more "-" characters
The reason this works is when this, hopefully, gets converted to a hash it treats your password as a number. The larger the number, the more difficult it is to crack, as there are more potential numbers to guess. It doesn't matter what characters you add, it makes space of potential values larger the attacker is going to have to guess.
The ex
Re: (Score:2)
If the attacker knows you do that, then it doesn't actually increase the attack space very much.
Re: (Score:2)
Only if they know your base password is password. Techniques like character substitution combined with random padding with random characters can be quite effective. No, you aren’t adding an extra order of magnitude x character pool to the complexity with each character, but you increase the order of magnitude of complexity for a raw dictonary with character substitution.
Re: (Score:2)
If you have a 5 character password (let's say lower case only), then there are 26^5 possible passwords. If you double one of the letters, then there are (26^5) * 5 possible passwords. If you add an extra character so it's a 6 character password, then you have 26^6 possible passwords.
Re: (Score:2)
Only if you are using 5 random letters as a base. If it is something that can be dictionary attacked then your base would be significantly less than 26^5, and the doubling (as an example strategy) would only add five additional possibilities for each word. Splitting the word at syllables with a random character or double character might add the equivalent of 20-50 additional options for each word.
Bottom line is that if someone knows your system then you need to use a complex system.
Re: (Score:3)
The problem is that attackers don't search the entire search space. They use the same algorithms Cracklib uses, based on dictionaries and patterns for commonly-used kinds of passwords. Eg., there's a pattern in there for "leet-speak" which takes the base password and replaces "e" with "3", "o" with "0" and so on to generate potential passwords. That's why applying "security rules" to passwords to require certain patterns (eg. requiring at least one of a set of special characters) is a bad idea, once the att
Re: (Score:2)
That means nothing a human could easily generate or remember, you need a randomly-generated password from a password manager program with the fewest restrictions on the allowable characters as you can manage.
That's what I use. It's not always practical or allowed by corporate IT, though. In those cases, it's still an effective way to expand the potential keyspace without having to remember gibberish. I'm sure there are well equipped bad guys with massive rainbow tables ready to go, but a 17 character password using upper and lower case, along with numbers and a special character, has a keyspace of roughly 10^33, even if one of those characters is repeated.
It's not a perfect solution, but the cost to the user is
Re: (Score:2)
I got news for you, a hash of your password is always of a similar length. The number does not get "larger".
I present you these two SHA256 hashes, one of them was for an input of length 1.
ca 97 81 12 ca 1b bd ca fa c2 31 b3 9a 23 dc 4d a7 86 ef f8 14 7c 4e 72 b9 80 77 85 af ee 48 bb
33 12 8b cc e5 b4 3e 0c b4 40 bc 15 d2 6e 26 9a db a6 f9 c0 8b bd 45 d7 4d ee bf 41 75 e0 5a 17
Let me know which one was easier to crack.
Re: (Score:2)
The first one was easier; it's the single character 'a'.
Re: (Score:2)
To save you the trouble, the other is for "I present you these two SHA256 hashes:".
Re: (Score:2)
I got news for you, a hash of your password is always of a similar length.
It's not the length of the hash that matters, but the length of the number being hashed. Cycling through the possible hashes of an 84 bit number is a *lot* more time consuming than cycling through the possible hashes of a 56 bit number.
The problem with all IT security (Score:2)
Re: (Score:2)
On the other hand, if your passwords are so complex you end up with people using a password manager, you're in a really bad situation. Because then there's only one password an attacker has to guess in order to know all of your passwords. The relative strength of those passwords is then completely meaningless. And if a social engineer can walk past and gather your passwords off post-it notes, you've again made all the security meaningless.
You're best off with some sort of two-factor authentication rather th
Windows (Score:3, Insightful)
a position in which he's tasked with creating legitimate-looking honeypot systems in order to study attacker trends.
So a default installation of Windows, then.
Re: (Score:2)
Most Windows machines have nothing of value on them. More like an empty pot.
Passwords are done wrong. Pet Peeve (Score:2)
Hackers just try to lowest hanging fruit first. If everyone started using stronger/longer passwords, they'd use zombie PC's to throw more brute force at them. It's length escalation.
The problem is that the password file itself is too easy to get to. If it were in a special locked box* with throttling and an API that did only one thing well, passwords, then it would be very rare for hackers to be able to try a billion combinations against it.
The password file doesn't belong on regular servers! There are too
Re: (Score:2)
Agreed passwords do not need to be stored locally. I think I saw something on lwn about Red Hat ditching NIS, though.
Re: (Score:2)
Using NIS to store passwords would be idiotic as the contents of /etc/shadow are in plaintext on the wire.
The right solution is to use Kerberos for passwords. You can still use NIS for the rest reasonably securely and we still do at work on the HPC system.
I was miffed that RedHat dropped Hesiod support. It was easy to stuff records into DNSmasq on my router to get a cheap user/group account system at home.
Re: (Score:2)
Kerberos is great, I agree.
SSH behind a firewall + SSH keys only (Score:3)
To secure SSH, first put access to it behind a firewall of some sort (iptables rules, VPN, port knocker, etc). Then also require all users to supply a reasonable SSH public key and disable password logins.
The first measure prevents packets from getting to the host. The second makes it highly unlikely to ever let an unauthorized person in.
Re: (Score:2)
This was the problem the original incarnation of IPSec was supposed to solve, back when it was made a mandatory component of IPv6. If all connections are encrypted, you can't know in advance which encryption is opportunistic (keys generated on-the-fly, no authentication of the client), which is fully identifying on a network-to-network basis and which is fully identifying on a client-to-server basis. By using a proper digital certificate for all fully identifying, it was supposed to be as good as SSH.
Of cou
Re: (Score:2)
Yes all well and good, but you have now lost total control of securing your system because you have no way of knowing if the remote private SSH key is secured with a passphrase.
Last year a number of HPC facilities in Europe where hacked and the hackers where jumping from one system to another looking for unsecured private SSH keys. Turns out to be trivially easy to find them on a system.
On the other hand I actually have control over the passwords that are used on my system. I can enforce complexity, I can s
confirmed (Score:2)
Lots of us (security experts) have been saying that for years: Length. That's the #1 important thing about your password. If it's 8 characters or less, it doesn't even much matter if it's passwd or !"Âf!4x
Also, stop forgetting that brute-forcing is not the only and not even the most common attack on passwords. When your password is stored unencrypted and the DB gets stolen it doesn't even matter if it's a random 80 character string.
Not the only attack. (Score:4, Informative)
I run a couple of servers on the internet. I've configured most of them to add a firewall rule to redirect your IP address to a different SSH server once you've entered 5 wrong passwords. That's an original ssh server with the "yup, that password seems correct" taken out. Oh and as you're already on the naughty list it also logs the attempts. So I have such a list of attempted passwords as well.
The thing is... with an online "brute force" attack, you are limited to a few attempts per second. But offline attacks, where the attacker manages to get hold of the encrypted password database are many orders of magnitude faster. So in that case, much longer passwords can and will be attempted. Thing is: by online logging you won't see those.
Re: (Score:3)
That's why password files should never be stored locally. Sadly, NIS seems to be on the way out and you don't really hear as much about Kerberos any more. That limits the number of ways you can use a secured password file.
Re: (Score:2)
Makes sense (Score:2)
That's a safe space I can get behind (Score:2)
I hope that fact gets noticed by the people who handle password filters, leading to more sites allowing spaces in passwords. I hate it when my passwords get kicked back for having spaces in them. Spaces are safe!
Then why do companies still limit... (Score:2)