7 ms·

A Really Good Article on How Easy it Is to Crack Passwords

112 points by wulfgarpro 13y ago

cperciva 13y ago
Remember, security against cracking is a combination of password strength and key derivation function strength. Nothing will save you if your password is "password". Not much will save you if your password is hashed with MD5. But scrypt can be over 100,000,000 time stronger than MD5 -- so if you're using scrypt you can afford to use a password which is 100,000,000 times weaker. "jdtwbv" hashed using scrypt is stronger than "H.*W8Jz&r3" hashed using MD5.
- dublinclontarf 13y ago
  Just use bcrypt :-p
  - tsahyt 13y ago
    bcrypt is not bad and you're definitely better off with that than with MD5, but scrypt performs better for these sort of things. There was an article on HN a week or so ago about this.
    - Xylakant 13y ago
      One of the problems of scrypt is a lack of language bindings. There's no officially blessed language binding for PHP, there's a ruby gem that only works on MRI but doesn't support jruby. Bcrypt on the other hand is widely supported, simple and easy to use implementations exist for devise and activerecord for example. I'd pick the slightly worse but widely supported algorithm and rather tune the work factor than being stuck with an extension that might or might not be supported depending on the authors availability of time and resources. This all can change, but that's the current state of things. Sorry scrypt.
      - Freaky 13y ago
        > there's a ruby gem that only works on MRI but doesn't support jruby Works as well as any other MRI extension, which is to say pretty well: jruby-1.7.4 :001 > require 'scrypt' => true jruby-1.7.4 :002 > SCrypt::Password.create("bla") => "400$8$2d$096ac4e8a120a4f9$d1e13bbfa387196d68f116d76ae23d0d3ffa39c891192a56832db0a1d8f6a8ec" Yay for ffi.
        Xylakant 13y ago
        Well, C-Extension support in jruby is wonky at best. It works for some and doesn't for others and is sometimes scheduled to be removed. Granted, this one works, I stand corrected. There's a full java implementation for scrypt as well. However, my point still stands: There's no integration in devise, none in rails. No PHP implementation. It's all fairly easy to change, but nobody has done so :)
        Freaky 13y ago
        Devise: https://github.com/capita/devise-scrypt https://github.com/capita/devise-scrypt PHP: http://pecl.php.net/package/scrypt http://pecl.php.net/package/scrypt So not quite "none", though granted being some random third party addon might as well be for many people (and possibly a good attitude to take for something security-critical).
        Xylakant 13y ago
        ok, my original statement regarding PHP was: > There's no officially blessed language binding for PHP. And judging from https://github.com/DomBlack/php-scrypt/issues/9 https://github.com/DomBlack/php-scrypt/issues/9 that's going to stay like that a while. There's a pure PHP implementation that falls back to the pecl package, so that's probably your best bet atm.
    - rypskar 13y ago
      I think that since bcrypt is more available I will continue recommending it, and using anything else should be based on a risk assessment. I do not think peoples that don’t do risk assessment on storing password will care enough to spend time on something that is not easy to set up when it “only” affect security
  - hackerboos 13y ago
    http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html
    - est 13y ago
      Great article. Old discussion here https://news.ycombinator.com/item?id=3724560 https://news.ycombinator.com/item?id=3724560
    - tptacek 13y ago
      That article was simply wrong. The chart at the top of it was added after it was pointed out that PBKDF2 is worse than bcrypt as a password hash, and the chart refutes the article.
- dspillett 13y ago
  > "jdtwbv" hashed using scrypt is stronger than "H.W8Jz&r3" hashed using MD5* But "password" is still grossly insecure in either case, it'll still be the first thing that someone performing a dictionary attack will try. Never tell people how good your key derivation function is, lest they misunderstand and think it means they don't have to chose a non-obvious password/passphrase.
- raverbashing 13y ago
  ""jdtwbv" hashed using scrypt is stronger than "H.*W8Jz&r3" hashed using MD5" Is it? I'm not sure. for the first one you're using lowercase letters (and digits, I'm giving you that 'free') For the first one we have 36^6 For the second one (all printables) 100^9 Relation between them: ~ 459,393,658. If you're saying scrypt is 100M times better, in this case the second one is safer And the relation is important but less as computers get faster. Option B may take 1Mi times as long as Option A but if Option A takes 1 microsecond, there goes your Option B as well
  - danielweber 13y ago
    People have built huge rainbow tables of MD5 hashes. I don't really keep up with that game (like WoW, it seems like a fun game, but only if you are willing to put in a lot of your time), but I think the current limit is somewhere around 8 or 9 characters if you are pulling from all printables, meaning that "H.*W8Jz&r3" with MD5 is probably not breakable right now. Take off two characters, or wait 3 years, and it probably will be.
    - consultant23522 13y ago
      My understanding, and I'm sure that someone else will correct me, is that with MD5 rainbow tables it's not so much that someone will get your password as they will get something that hashes to the same value. More than likely this will be your password, but sometimes not. The point is that it doesn't matter if your password is 25 characters long.. if there's a 5 character password that hashes to the same value they could log in with it.
      - danielweber 13y ago
        While it's possible to make MD5 collisions, finding something that hashes to the same thing as a hash of my short password is essentially impossible. In fact, collisions on short passwords are harder than collisions on long passwords. The space of all MD5 outputs is way bigger than the space of 12-character passwords.
  - 13y ago
salmonellaeater 13y ago
> "This is an answer to the batteryhorsestaple thing." Steube misunderstands the xkcd comic [1]. There's a really good comment which explains it: "It could be argued that Randall's example of 4 words is too short -- and indeed, for some applications, it is. However for a typical dictionary size, and genuinely random selection, it is massively stronger than "typical" passwords and in fact easily adequte to defeat the above-mentioned attacks." [2] Emphasis on "genuinely random selection." [1] https://xkcd.com/936/ https://xkcd.com/936/ [2] http://www.schneier.com/blog/archives/2013/06/a_really_good_a.html#c1483848 http://www.schneier.com/blog/archives/2013/06/a_really_good_...
- derefr 13y ago
  What password length would you need to get away with a plain-old grammatical english sentence (i.e. very much non-random selection)? For example: "and in the swept plains of winter's vale, our hero did beseech the emperor to send for his forces" -- what would be the difficulty in cracking that, given that this isn't a quote from a book or anything, but just a sentence that popped into my mind and seems easy enough to remember?
  - salmonellaeater 13y ago
    Shannon did an experiment that found the entropy of English text is about 1.6 bits per character. This is probably a high estimate, since the kinds of sentences you might think up for a password probably have lower entropy than if you used a source of random bits to generate valid sentences.
  - enscr 13y ago
    My God, are you going to type all of that or will you need a script to do it for you. Watch out for those touch-screen thingies people are touting around.
    - Semiapies 13y ago
      With Swype and similar programs, passphrases are pretty easy to enter.
praptak 13y ago
I like schemes that have an explicit input of n random bits (or where you can at least have a good estimate on the entropy.) With the Schneier Scheme I can not be sure of the actual entropy of my password. Maybe my brain only generates a relatively small set of sentences which can be reverse-engineered from my comments on HN? :-) A good algorithm would take n bits and map them uniquely to a set of strings that are easy to remember for a human. The apg utility does something like that.
tilsammans 13y ago
Passwords are broken and I really wish we would all move away from them. Persona is a nice idea with regards to privacy and control, but it's still a password that you need to remember, which can be cracked. Also, people generally don't use strong passwords. What irks me is that every OS in use today has support for strong cryptography and browser vendors could easily integrate that. We would no longer register for a website, we would simply upload our "Online Identity" or whatever we called it. This of course is just an id_rsa.pub with maybe name and email in the comment. The remote site stores the public key and the browser authenticates using the private key, stored securely in the keychain. This has the potential to be invisible to users, and thus used by default, and highly secure since the local keychain can generate incredibly strong keys, all behind the scenes.
- hvidgaard 13y ago
  And how do you access your identity from a device that isn't your own? I'm 100% with you, it would be a major step forward - but it's too inflexible for Joe & Jane.
  - xerophtye 13y ago
    and also it kinda destroys the ubiquity of the service. you have to admit, the ability to access your account from any device anywhere is pretty cool (and very critical in some cases)
    - hvidgaard 13y ago
      It certainly is a difficult sell to the average user. For most Internet Banking, it's already implemented, but try to get users to accept that when using Facebook or access to their mail. In Denmark we have a public system called "NemID". It is a 2-factor authentication, which relies on a card with one-time codes, or eventually, a physical key-generator. It is used to anything related to Internet Banking or access to the public services on the internet, such as application for university, change in tax return, and the like. Unless you can incorporate such a system, which ensure that most uses already have the needed physical token, I not convinced you can pull it off.
cubsink 13y ago
Passwords should be a thing of the past. It gives the users an illusion of security.
MarkMc 13y ago
Why not force the user to have strong login credentials? I'm creating an online system that will store users' sensitive financial data. When setting up an account, the user will have to choose a password as normal, but will also be given a passphrase of the form "correct horse battery staple" that they must write down. To log in, the user will need to enter (a) username; (b) password; and (c) passphrase. It is effectively a poor man's two-factor authentication - the second factor being the piece of paper containing the passphrase. I think it strikes a good balance between security, convenience and cost. What do others think of this approach?
- ajanuary 13y ago
  It's certainly better than just a password, and as you say is a nice balance between usability and strong passwords. However, I'd be careful about thinking of it as any sort of 2-factor authentication and wouldn't bestow any of the advantages of 2-factor auth on your scheme. A static secret, no matter how complex, doesn't really prove ownership because multiple people can trivially have a copy of the secret at the same time. So you don't have a knowledge and a physical factor, just a convoluted knowledge factor. Better than just a password, but don't let it g e you a false sense of security.
- pbreit 13y ago
  The passphrase looks to be very weak if it is just something like 4 english words. And fails on the convenience test.
  - zokier 13y ago
    Correct horse battery staple comes from https://xkcd.com/936/ https://xkcd.com/936/
- Xylakant 13y ago
  That's not TFA since the piece of paper with the passphrase is not "A thing you have". It's just "another thing you know." and thus brute-foreceable. It's the same as not allowing the user to choose a password but rather generate 12-character random passwords with special chars. Authentication devices for TFA are designed, so that you really have to have the device close to you when you do a login.
pbreit 13y ago
The Ars article seemed totally irrelevant to me since it used MD5?
- 16s 13y ago
  Microsoft Active Directory servers (used in big business and government all over the world) uses one round of MD4 (no salt). That's a 4, not a 5.
- yk 13y ago
  The cracking technique discussed is dictionary plus some common substitutions. So the hashing algorithm is not very important. You would loose some factor of speed, but the 1000 most common passwords times 10 common substitutions, perhaps with 100 postfixes is still only 1 million hashes. And you would crack with these some non negligible fraction of the passwords in an unsalted database in probably under a minute. ( If the passwords are salted in the db, then you need a minute per hash, so assuming that you crack a few percent of the hashes you try, then you expect one password in under two hours even with modern password hashes.)
Kiro 13y ago
I don't understand the difference between "momof3g8kids" and "tlpWENT2m". Why would the latter be more secure?
- dcuthbertson 13y ago
  Actually, it's hard for a 9-character password to beat a 12-character password even though the latter has a larger alphabet/key-space (unless I've completely blown the analysis below, which was done before coffee :). The first has a key-space of 36^12 (36 possible characters in each of 12 positions), or about 4.7e18. The second has a key-space of 62^9 (62 upper/lower case letters and digits in each of 9 possible locations), or about 1.4e16. If, in addition to adding the uppercase letters, you added the possibility of needing to test symbols, such as ~`.,/:;!@#$%^&*-=_+ (another 19 symbols), and changed the latter password to "tlpW#NT2m", then the searchable key-space for all 9-character passwords becomes 81^9, or about 1.5e17. RE-EDIT: Sorry. I should have read the article first. I'm not sure why the latter would be more secure. Obviously "WENT" would be in a dictionary, so I'd think that "tlpWENT2m" would fall to a combinator attack very quickly, too.
- Freaky 13y ago
  The former is common enough for multiple people to have it as their username, for a start.
Murk 13y ago
People seem to forget this important fact - That hashes get leaked. Without a hash corresponding to a user account it's quite hard to break in to a given account with a moderately reasonable password, even if the hash can be 'broken' in milliseconds.
corin_ 13y ago
'Also included in the list: "all of the lights" (yes, spaces are allowed on many sites), "i hate hackers," "allineedislove," "ilovemySister31," "iloveyousomuch," "Philippians4:13," "Philippians4:6-7," and "qeadzcwrsfxv1331." "gonefishing1125" was another password Steube saw appear on his computer screen. Seconds after it was cracked, he noted, "You won't ever find it using brute force."' If you won't ever find "gonefishing1125" using brute force, how on earth did they find "qeadzcwrstxv1331"?
- barrkel 13y ago
  Have you looked at the keyboard pattern for qeadzcwrsfxv1331? I imagine there are a whole bunch of these geometric patterns, and different combos of them are tried.
- deleted 13y ago
  [deleted]
gopi 13y ago
One benefit of being a indian language speaker (or other language not in hackers dictionary) is we can easily choose reasonably secure passwords that are remember-able by simply using native language phrases (combined with numbers and mixed caps)
- Semiapies 13y ago
  Assuming there aren't any Indians writing password-cracking software...

112 points by wulfgarpro 13y ago

Remember, security against cracking is a combination of password strength and key derivation function strength. Nothing will save you if your password is "password". Not much will save you if your password is hashed with MD5. But scrypt can be over 100,000,000 time stronger than MD5 -- so if you're using scrypt you can afford to use a password which is 100,000,000 times weaker. "jdtwbv" hashed using scrypt is stronger than "H.*W8Jz&r3" hashed using MD5.

dublinclontarf 13y ago
Just use bcrypt :-p
- tsahyt 13y ago
  bcrypt is not bad and you're definitely better off with that than with MD5, but scrypt performs better for these sort of things. There was an article on HN a week or so ago about this.
  - Xylakant 13y ago
    One of the problems of scrypt is a lack of language bindings. There's no officially blessed language binding for PHP, there's a ruby gem that only works on MRI but doesn't support jruby. Bcrypt on the other hand is widely supported, simple and easy to use implementations exist for devise and activerecord for example. I'd pick the slightly worse but widely supported algorithm and rather tune the work factor than being stuck with an extension that might or might not be supported depending on the authors availability of time and resources. This all can change, but that's the current state of things. Sorry scrypt.
    - Freaky 13y ago
      > there's a ruby gem that only works on MRI but doesn't support jruby Works as well as any other MRI extension, which is to say pretty well: jruby-1.7.4 :001 > require 'scrypt' => true jruby-1.7.4 :002 > SCrypt::Password.create("bla") => "400$8$2d$096ac4e8a120a4f9$d1e13bbfa387196d68f116d76ae23d0d3ffa39c891192a56832db0a1d8f6a8ec" Yay for ffi.
      - Xylakant 13y ago
        Well, C-Extension support in jruby is wonky at best. It works for some and doesn't for others and is sometimes scheduled to be removed. Granted, this one works, I stand corrected. There's a full java implementation for scrypt as well. However, my point still stands: There's no integration in devise, none in rails. No PHP implementation. It's all fairly easy to change, but nobody has done so :)
        Freaky 13y ago
        Devise: https://github.com/capita/devise-scrypt https://github.com/capita/devise-scrypt PHP: http://pecl.php.net/package/scrypt http://pecl.php.net/package/scrypt So not quite "none", though granted being some random third party addon might as well be for many people (and possibly a good attitude to take for something security-critical).
        Xylakant 13y ago
        ok, my original statement regarding PHP was: > There's no officially blessed language binding for PHP. And judging from https://github.com/DomBlack/php-scrypt/issues/9 https://github.com/DomBlack/php-scrypt/issues/9 that's going to stay like that a while. There's a pure PHP implementation that falls back to the pecl package, so that's probably your best bet atm.
  - rypskar 13y ago
    I think that since bcrypt is more available I will continue recommending it, and using anything else should be based on a risk assessment. I do not think peoples that don’t do risk assessment on storing password will care enough to spend time on something that is not easy to set up when it “only” affect security
- hackerboos 13y ago
  http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html
  - est 13y ago
    Great article. Old discussion here https://news.ycombinator.com/item?id=3724560 https://news.ycombinator.com/item?id=3724560
  - tptacek 13y ago
    That article was simply wrong. The chart at the top of it was added after it was pointed out that PBKDF2 is worse than bcrypt as a password hash, and the chart refutes the article.
dspillett 13y ago
> "jdtwbv" hashed using scrypt is stronger than "H.W8Jz&r3" hashed using MD5* But "password" is still grossly insecure in either case, it'll still be the first thing that someone performing a dictionary attack will try. Never tell people how good your key derivation function is, lest they misunderstand and think it means they don't have to chose a non-obvious password/passphrase.
raverbashing 13y ago
""jdtwbv" hashed using scrypt is stronger than "H.*W8Jz&r3" hashed using MD5" Is it? I'm not sure. for the first one you're using lowercase letters (and digits, I'm giving you that 'free') For the first one we have 36^6 For the second one (all printables) 100^9 Relation between them: ~ 459,393,658. If you're saying scrypt is 100M times better, in this case the second one is safer And the relation is important but less as computers get faster. Option B may take 1Mi times as long as Option A but if Option A takes 1 microsecond, there goes your Option B as well
- danielweber 13y ago
  People have built huge rainbow tables of MD5 hashes. I don't really keep up with that game (like WoW, it seems like a fun game, but only if you are willing to put in a lot of your time), but I think the current limit is somewhere around 8 or 9 characters if you are pulling from all printables, meaning that "H.*W8Jz&r3" with MD5 is probably not breakable right now. Take off two characters, or wait 3 years, and it probably will be.
  - consultant23522 13y ago
    My understanding, and I'm sure that someone else will correct me, is that with MD5 rainbow tables it's not so much that someone will get your password as they will get something that hashes to the same value. More than likely this will be your password, but sometimes not. The point is that it doesn't matter if your password is 25 characters long.. if there's a 5 character password that hashes to the same value they could log in with it.
    - danielweber 13y ago
      While it's possible to make MD5 collisions, finding something that hashes to the same thing as a hash of my short password is essentially impossible. In fact, collisions on short passwords are harder than collisions on long passwords. The space of all MD5 outputs is way bigger than the space of 12-character passwords.
- 13y ago

salmonellaeater 13y ago

> "This is an answer to the batteryhorsestaple thing." Steube misunderstands the xkcd comic [1]. There's a really good comment which explains it: "It could be argued that Randall's example of 4 words is too short -- and indeed, for some applications, it is. However for a typical dictionary size, and genuinely random selection, it is massively stronger than "typical" passwords and in fact easily adequte to defeat the above-mentioned attacks." [2] Emphasis on "genuinely random selection." [1] https://xkcd.com/936/ https://xkcd.com/936/ [2] http://www.schneier.com/blog/archives/2013/06/a_really_good_a.html#c1483848 http://www.schneier.com/blog/archives/2013/06/a_really_good_...

derefr 13y ago
What password length would you need to get away with a plain-old grammatical english sentence (i.e. very much non-random selection)? For example: "and in the swept plains of winter's vale, our hero did beseech the emperor to send for his forces" -- what would be the difficulty in cracking that, given that this isn't a quote from a book or anything, but just a sentence that popped into my mind and seems easy enough to remember?
- salmonellaeater 13y ago
  Shannon did an experiment that found the entropy of English text is about 1.6 bits per character. This is probably a high estimate, since the kinds of sentences you might think up for a password probably have lower entropy than if you used a source of random bits to generate valid sentences.
- enscr 13y ago
  My God, are you going to type all of that or will you need a script to do it for you. Watch out for those touch-screen thingies people are touting around.
  - Semiapies 13y ago
    With Swype and similar programs, passphrases are pretty easy to enter.

praptak 13y ago

I like schemes that have an explicit input of n random bits (or where you can at least have a good estimate on the entropy.) With the Schneier Scheme I can not be sure of the actual entropy of my password. Maybe my brain only generates a relatively small set of sentences which can be reverse-engineered from my comments on HN? :-) A good algorithm would take n bits and map them uniquely to a set of strings that are easy to remember for a human. The apg utility does something like that.

tilsammans 13y ago

Passwords are broken and I really wish we would all move away from them. Persona is a nice idea with regards to privacy and control, but it's still a password that you need to remember, which can be cracked. Also, people generally don't use strong passwords. What irks me is that every OS in use today has support for strong cryptography and browser vendors could easily integrate that. We would no longer register for a website, we would simply upload our "Online Identity" or whatever we called it. This of course is just an id_rsa.pub with maybe name and email in the comment. The remote site stores the public key and the browser authenticates using the private key, stored securely in the keychain. This has the potential to be invisible to users, and thus used by default, and highly secure since the local keychain can generate incredibly strong keys, all behind the scenes.

hvidgaard 13y ago
And how do you access your identity from a device that isn't your own? I'm 100% with you, it would be a major step forward - but it's too inflexible for Joe & Jane.
- xerophtye 13y ago
  and also it kinda destroys the ubiquity of the service. you have to admit, the ability to access your account from any device anywhere is pretty cool (and very critical in some cases)
  - hvidgaard 13y ago
    It certainly is a difficult sell to the average user. For most Internet Banking, it's already implemented, but try to get users to accept that when using Facebook or access to their mail. In Denmark we have a public system called "NemID". It is a 2-factor authentication, which relies on a card with one-time codes, or eventually, a physical key-generator. It is used to anything related to Internet Banking or access to the public services on the internet, such as application for university, change in tax return, and the like. Unless you can incorporate such a system, which ensure that most uses already have the needed physical token, I not convinced you can pull it off.

cubsink 13y ago

Passwords should be a thing of the past. It gives the users an illusion of security.

MarkMc 13y ago

Why not force the user to have strong login credentials? I'm creating an online system that will store users' sensitive financial data. When setting up an account, the user will have to choose a password as normal, but will also be given a passphrase of the form "correct horse battery staple" that they must write down. To log in, the user will need to enter (a) username; (b) password; and (c) passphrase. It is effectively a poor man's two-factor authentication - the second factor being the piece of paper containing the passphrase. I think it strikes a good balance between security, convenience and cost. What do others think of this approach?

ajanuary 13y ago
It's certainly better than just a password, and as you say is a nice balance between usability and strong passwords. However, I'd be careful about thinking of it as any sort of 2-factor authentication and wouldn't bestow any of the advantages of 2-factor auth on your scheme. A static secret, no matter how complex, doesn't really prove ownership because multiple people can trivially have a copy of the secret at the same time. So you don't have a knowledge and a physical factor, just a convoluted knowledge factor. Better than just a password, but don't let it g e you a false sense of security.
pbreit 13y ago
The passphrase looks to be very weak if it is just something like 4 english words. And fails on the convenience test.
- zokier 13y ago
  Correct horse battery staple comes from https://xkcd.com/936/ https://xkcd.com/936/
Xylakant 13y ago
That's not TFA since the piece of paper with the passphrase is not "A thing you have". It's just "another thing you know." and thus brute-foreceable. It's the same as not allowing the user to choose a password but rather generate 12-character random passwords with special chars. Authentication devices for TFA are designed, so that you really have to have the device close to you when you do a login.

pbreit 13y ago

The Ars article seemed totally irrelevant to me since it used MD5?

16s 13y ago
Microsoft Active Directory servers (used in big business and government all over the world) uses one round of MD4 (no salt). That's a 4, not a 5.
yk 13y ago
The cracking technique discussed is dictionary plus some common substitutions. So the hashing algorithm is not very important. You would loose some factor of speed, but the 1000 most common passwords times 10 common substitutions, perhaps with 100 postfixes is still only 1 million hashes. And you would crack with these some non negligible fraction of the passwords in an unsalted database in probably under a minute. ( If the passwords are salted in the db, then you need a minute per hash, so assuming that you crack a few percent of the hashes you try, then you expect one password in under two hours even with modern password hashes.)

Kiro 13y ago

I don't understand the difference between "momof3g8kids" and "tlpWENT2m". Why would the latter be more secure?

dcuthbertson 13y ago
Actually, it's hard for a 9-character password to beat a 12-character password even though the latter has a larger alphabet/key-space (unless I've completely blown the analysis below, which was done before coffee :). The first has a key-space of 36^12 (36 possible characters in each of 12 positions), or about 4.7e18. The second has a key-space of 62^9 (62 upper/lower case letters and digits in each of 9 possible locations), or about 1.4e16. If, in addition to adding the uppercase letters, you added the possibility of needing to test symbols, such as ~`.,/:;!@#$%^&*-=_+ (another 19 symbols), and changed the latter password to "tlpW#NT2m", then the searchable key-space for all 9-character passwords becomes 81^9, or about 1.5e17. RE-EDIT: Sorry. I should have read the article first. I'm not sure why the latter would be more secure. Obviously "WENT" would be in a dictionary, so I'd think that "tlpWENT2m" would fall to a combinator attack very quickly, too.
Freaky 13y ago
The former is common enough for multiple people to have it as their username, for a start.

Murk 13y ago

People seem to forget this important fact - That hashes get leaked. Without a hash corresponding to a user account it's quite hard to break in to a given account with a moderately reasonable password, even if the hash can be 'broken' in milliseconds.

corin_ 13y ago

'Also included in the list: "all of the lights" (yes, spaces are allowed on many sites), "i hate hackers," "allineedislove," "ilovemySister31," "iloveyousomuch," "Philippians4:13," "Philippians4:6-7," and "qeadzcwrsfxv1331." "gonefishing1125" was another password Steube saw appear on his computer screen. Seconds after it was cracked, he noted, "You won't ever find it using brute force."' If you won't ever find "gonefishing1125" using brute force, how on earth did they find "qeadzcwrstxv1331"?

barrkel 13y ago
Have you looked at the keyboard pattern for qeadzcwrsfxv1331? I imagine there are a whole bunch of these geometric patterns, and different combos of them are tried.
deleted 13y ago
[deleted]

gopi 13y ago

One benefit of being a indian language speaker (or other language not in hackers dictionary) is we can easily choose reasonably secure passwords that are remember-able by simply using native language phrases (combined with numbers and mixed caps)

Semiapies 13y ago
Assuming there aren't any Indians writing password-cracking software...