
Stop forcing arbitrary password rules - bemmu
http://ryanwinchester.ca/post/stop-forcing-your-arbitrary-password-rules-on-me
======
lhecker
I completely agree with the author, but... what he completely misses is the
biggest annoyance: maximum length rules.

I'd probably sacrifice my firstborn if Microsoft would finally wake up and
accept passwords longer than 16 goddamn characters...

~~~
Karlozkiller
No, the most annoying thing is when they don't tell you the rules in advance,
and you start typing a password that fits most standard rules.

Now either you get through but don't know if you could've used a better
password. Or your password will be denied and you have to make adaptions or
change completely.

~~~
dannib
No, the most annoying is when you paste your password manager's auto generated
long password and it silently get cut after 16 characters but successfully let
you create your account. But now the login form doesn't have the same max-
length property and your password will fail.

Hopefully the reset password form is synced with the login form.

~~~
qb45
Sounds so insane I guess it must have really happened.

I had similar issue with paypal once. Their bank account number field expected
to get N digits without spaces, so it was hard limited to N characters. Of
course they didn't bother telling about that. When I pasted my number with
some K space separators tossed between digits, the last K digits have been
silently truncated. Boom, account locked.

~~~
Someone
Happened to me this week. "Luckily", they also implemented the "feature" where
they can send you your password by email directly after you set it, so when I
couldn't get in with the password I set, I reset the password, got a mail with
a new password, logged in, changed the password to a new random long string,
and this timeasked them to send the password to me. The password they sent was
chopped off. That told me their limit, so I could set my password a third time
to get something maximally secure.

~~~
smoothgrips
So, they emailed your password to you? Plaintext? They store passwords in
plaintext? Paypal?

~~~
Someone
_directly after you set it_

------
ckaygusu
One startup I was working for were enforcing different rules depending on
where you were setting the password e.g. 4 characters when you follow the
forgotten password procedure, 8 characters when registering, 12 characters
when changing password normally.

Another thing, a visa broker in Turkey had a so ridiculous password rule and
gibberish error message, I had to read the source code and parse the regex by
hand. Only then I was able to type in a valid password.

~~~
armabiz
Your password has expired :)

------
forgotpwtomain
I agree with the point the author is making and generally am just as annoyed
by arbitrary password rules; nevertheless:

> chili dog monkey nutso

Is definitely not 18 quintillion years at best it's approximately 250000^4
which is 2^72.

A good (though still requiring some memorizing effort approach) would be
something along the lines of
[https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi...](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)
which uses a standard dictionary of 1626 easily memorable english words with
each password being a 12 word mnemonic phrase. 1626^12 ~= 12^128

~~~
petercooper
_it 's approximately 250000^4_

If the attacker _knows_ you've used four dictionary words in a row. Now you
need to multiply the number by the odds of _that_..

~~~
paulmd
And the entropy of the password 0b0 is only a single bit - if the attacker
_knows_ you've used a single-bit password. Hashed into the SHA-256 space
that's only a 1:2^256 chance of someone colliding with it. Still, is that a
password you'd set?

What does that have to do with the output of the password in terms of brute-
force guessing? Aren't you kind of assuming that an opponent won't try a broad
dictionary attack? Equal distribution of hash outputs fundamentally assumes
equivalent distributions of hash _inputs_ , and that's not true for the
distributions of common passwords.

Again - everyone knows the passphrase patterns everyone uses, everyone knows
the password transformations everyone follows (eg l33t) and overall those
patterns are significantly weak against attack because of this public
knowledge. By those algorithm, with knowledge of salts/etc those passwords are
very weak.

Should you use a song, or a slight modification, or a l33t transformation?
Certainly not - if the input space isn't uniformly distributed across the
input space, the probability of hitting pay dirt definitely isn't uniformly
distributed across the output space.

Even the class of "valid transformations of sensical English sentences" is not
an equal distribution because of the above. If you can compress a language you
can attack it, because by the assumption of compression the data is not at its
minimum entropy. Maybe not feasibly if you're lucky - but don't bet on it just
because Webster's is big.

~~~
hueving
What are you going on about? Your giant post did nothing to refute the point
that an attacker doesn't know you are using 1 word vs 4 words vs 12.

Also, you seem to imply that there is a distinguishable difference in sha1
outputs of good random inputs and English word inputs, which violates a
security property of cryptographic hashes. So there is a lot of fame to be had
if you can prove that.

------
ddlatham
100 times yes. The mere presence of a single character from a different class
does not increase entropy. It means that most common passwords move from 8
lowercase letters to 6 lowercase letters plus 1 number plus 1 symbol, which is
even easier to search.

If you have a sophisticated entropy estimation tool, or library, great.
Another simple thing is using a min length, plus restrict from a dictionary of
the million most leaked passwords to outlaw those (can hold it in a bloom
filter if size is a concern).

~~~
Retric
Must contain 2 of the following, (upper case letter), (lower case letter),
(number), or (Symbol) is higher entropy than 8 lower case letters.

~~~
sokoloff
Mathematically, but not socially.

It means that humans reduce the entropy across the board to (more than, IMO)
compensate for the mathematical advantage.

~~~
Retric
Do you have any data on this? Last I check pick to was a slightly better
option.

~~~
sokoloff
I don't have any real data. I know my own behavior for "sites I don't care
about" and every once in a while I'm exposed to someone else's password (when
they tell me their password for a site they don't care about, or where I see a
password in plaintext in our shared password manager).

There's an awful lot of "capitalize the first letter" and "replace e by 3, a
by 4, o by 0" and "sometimes append a bang". That results in meeting the
password complexity rules without any additional entropy in the first 2 rules
and 1 bit of entropy for the last rule.

------
emsy
Second worst password rule: preventing to paste in the password field.

As seen at The OS X FileVault dialog, PayPal, Blizzard and many more....

~~~
scintill76
Chrome hackaround:

1\. Right-click the field, Inspect element.

2\. Go to Console tab, type: $0.value = 'mypassword';

$0 is the last selected element:
[https://developer.chrome.com/devtools/docs/commandline-
api](https://developer.chrome.com/devtools/docs/commandline-api)

~~~
dugmartin
I have this as a bookmarket named 'Reveal Passwords':

    
    
        javascript:(function(){var IN,F;IN=document.getElementsByTagName('input');for(var i=0;i<IN.length;i  ){F=IN[i];if(F.type.toLowerCase()=='password'){try{F.type='text'}catch(r){var n,Fa;n=document.createElement('input');Fa=F.attributes;for(var ii=0;ii<Fa.length;ii  ){var k,knn,knv;k=Fa[ii];knn=k.nodeName;knv=k.nodeValue;if(knn.toLowerCase()!='type'){if(knn!='height'&&knn!='width'&!!knv)n[knn]=knv}};F.parentNode.replaceChild(n,F)}}}})()

------
codedokode
What we really need is to stop using passwords.

Passwords are awful UX design solution. The users have to think of and
remember some meaningless phrase to get the service they really needed. If you
use easy password, your account can be hacked. If you use difficult password,
you won't remember it in a week.

For some people remembering a password or login might be especially difficult.

You can use software to generate and remember passwords but all of them will
be lost if you reformat your drive. Some of password managers are proprietary,
non cross-platform and some would upload your passwords to the so called cloud
so NSA can look at them too.

In any case your passwords can be easily compromised when your PC is infected
or you use somebody's else device.

What we need is to get rid of this obsolete system. We need hardware
authorisation key (that could look like a real key) that can be used for both
registration and logging in and would generate and securely store private keys
for all used services. Such device should use strong crypto, should not allow
exporting private keys, update firmware or operate without user confirmation.

I think such kind of keys will appear sooner or later, they are superior to
passwords and password managers and easy to use but I am not sure that they
will be open source, cross platform, and backdoor-free unless we do something
in advance.

~~~
CHY872
No. They are not superior to passwords - they merely provide different
tradeoffs. For example, the site that requires your hypothetical key-type key
would require that either all of their customers have spent money on such a
key (bad) or that they are willing to pay for keys for all of their customers.

This is something that has been thought about in detail - see
[https://vtllf.org/blog/ssh-web-sign-in/quest-to-replace-
pass...](https://vtllf.org/blog/ssh-web-sign-in/quest-to-replace-
passwords.png) for Stajano's analysis.

~~~
xixixao
More importantly, you just replaced the problems of virtual keys with the
problems of physical keys: you can lose them. Recovery is much more difficult
than recovery of a virtual key.

~~~
JoeAltmaier
Really? You don't lose (forget) virtual keys? It's a far worse problem. A
physical key can _always_ be found if you look hard enough. A virtual key can
truly be lost forever.

~~~
citruspi
> A virtual key can truly be lost forever.

Sure, but it's super easy to make backups of virtual keys. It's a digital file
- just copy it.

Worried one backup isn't enough? Make a million. Space is cheap.

~~~
JoeAltmaier
Ok, but that makes is harder, not easier, to manage virtual keys. And the more
copies, the weaker the key (the easier to find). A million is a terrible,
terrible idea.

No, I despise passwords. The whole scheme is backwards. I don't want to
authenticate myself to the server; I want to authenticate the server to me.
Why doesn't _it_ provide the password, and my computer verify it? Why is a
fallible human being in this game at all?

~~~
citruspi
> A million is a terrible, terrible idea.

Well, yeah. That was a hyperbole. I didn't actually mean that you should go
out and make a million copies of your key.

It simply meant to show that it's easier to prevent the loss of a virtual key
than it is to prevent the loss of the physical key.

> The whole scheme is backwards. I don't want to authenticate myself to the
> server; I want to authenticate the server to me.

That's... interesting. My first thought when I read that is that the server is
the one with your data and multiple users - so it needs to authenticate you to
make sure that you only access your data and don't gain access to other users'
data.

A server authenticating itself with you would tell you that you're actually
talking to XYZ and not an imposter, but once that authentication took place
you'd have access to everything on that server. Including other users' data.

How do you imagine this working?

~~~
JoeAltmaier
Any authentication is one-to-one. The server authenticates to me, by first
knowing who I am (my 'username' not a password), then using a scheme we agreed
upon (our shared pair of private/public keys would be fine) to verify
_electronically_ that my machine belongs to me i.e. has the right keys.

So we are both authenticated to one another. Except now, we're using
sophisticated passwords and Digital Computer Logic to work them out. Instead
of my fallible wetware.

------
plorg
I was in Chicago with my family recently and purchased a one-day pass for the
CTA. When I returned home I found you could create an online account connected
to the card, ostensibly to be able to fill it up automatically, but also to
track your ridership. I thought it would be interesting to see what kind of
data a rider could get from the card.

I spent quite a bit of time trying to create an account only to receive a
generic 50x error page each time. I tried disabling adblockers, completely
unblocking javascript, disabling extensions, and nothing worked. I tried it in
different browsers, and on different computers. I still received the 50x
error. Then, on a whim, I tried using a different password. When that worked,
I tried changing the password using 1-character-removed tweaks of the
original. There was a single character that, it turns out, would cause the
application to choke on passwords (I don't remember which character).
Presumably it was an escape character or a semicolon.

It's not impossible for account systems to fail in unexpected ways, so there
are probably more than a few (poorly-designed) websites which have seemingly
arbitrary password requirements which are designed to avoid the kind of error
I found above. Still, it would be better to fix the error in the webapp than
to try to patch it by limiting the user input - that's an obvious security
problem waiting to happen.

~~~
sago
Suggests to me that form-input is being used unescaped at some point in their
software. I wonder what the password "foo'; drop table users;" would do.

------
jpdus
Totally agree. At least 1 Uppercase means 99% of people just use an uppercase
first character for their standard password. 1 number means they append 1,2 or
a year and 1 special character means they append an exclamation mark. Entropy
added = 0 (if password rules are known to the attacker). I don't get how
anyone who cared the slightest about security would think otherwise and
enforces these stupid rules.

~~~
kristopolous
I think a lot of it is driven by management. I've had to talk management out
of it before. Then they still "don't get it" and think I'm OK with an "easier
to hack" website, holding it against me as a character flaw - as if I'm a bad
engineer who doesn't believe in diligence.

Anyway, that's probably where they come from - implemented by more obedient
employees.

------
nsmalch
I see this a lot now, with the proliferation of libraries that allow for
arbitrary passwords. Possibly some form of systemic trickling down of bad
practices into software with horrible consequences

"Your password must contain the seventh circle of hell, and a Taco Emoji"

~~~
mdpopescu
I liked the message saying something like "your password must contain three
characters from Game of Thrones" :)

------
1ris
Out of all, my bank forces to have my password to have exactly 5 chars. This
is madness. Fortunately to actually do anything I need a second authentication
factor.

~~~
therein
My bank does the same, and they limit everyone to 8 characters. It is Schwab.

------
coreyp_1
I despise expiring passwords. My university makes me change my password every
6 months, and they keep a list of the last 2 year's worth of passwords so that
you can't reuse them. That, and they disallow some characters such as "#" and
" " (space). It's annoying.

~~~
JoeAltmaier
Typically, folks just change the '1' at the end to '2'. And so on. I agree
this is another totally pointless password rule that helps nobody.

------
lifeisstillgood
I use pwsafe for iOS (yes trusting some guy built a binary ok) to keep my many
passwords for each domain. It will generate (no I don't know the RNG)
passwords based on policy settings (length, characters, etc)

And like the author, flat out my number one bugbear is that no matter what
random(ish) password I choose before signing up, some idiot will decide that
my 12 letter password is too long or my password must have an upper case, or a
number of a special character - but never in a consistent manner.

I really want to just move to google authenticator and one factor auth. Just
stick a QR code up, let me photo it on screen and I will give you a HMAC code
right back.

No passwords. Just illusion

~~~
benashford
And then you lose your phone and...

~~~
lifeisstillgood
Pretty much the same as everything else that happens when I lose my phone.
Total disaster.

------
coldcode
Often the stupidest limitations in passwords come from the backend system
being an ancient banking/insurance/healthcare system running on a mainframe
using rules that were prevalent 30-40 years ago. Having worked for a smallish
financial/banking company we had an AS/400 with code mostly written in a 4GL
tool as the system of record. The database didn't even have unique keys.
Everything modern (like web apps) was limited by what this system supported.

~~~
mkobit
One that comes to recent memory is Schwab. A few points from this
([http://www.jeremytunnell.com/posts/swab-password-policies-
an...](http://www.jeremytunnell.com/posts/swab-password-policies-and-two-
factor-authentication-a-comedy-of-errors)) article from December 2014:

> "Schwab.com passwords are limited to eight characters, cannot contain
> symbols, and are case insensitive. " > "I now know that on the backend, my
> secure 16 digit password got stored in the system as only the first eight
> characters." > "So what they do is allow UP TO eight characters to represent
> the password, which is stripped from the contents of the password field.
> Assuming that the user is activating a token, there will be characters left
> over. Instead of using the LAST six characters to check the token code, they
> pull the NEXT 6 characters."

Seems like these companies just do not want to put the effort or deal with the
customer pain of updating to a newer model.

------
bradjohnson
It always seems like banks are way behind the curve on this for whatever
reason. My old credit union that I left a couple years back required
specifically a 6 character ^[0-9]$ password for complete access to my account.
I have no idea why this seemed like a good idea to them. Plus the idiotic
security question crap that they usually store in plain text. Just let me
store my email and send me an email if I lose access; security questions make
you /less/ secure.

------
chris_wot
I've been wondering about password complexity for a while now. If a password
is cryptographically hashed, so long as it isn't a dictionary word or date,
why on earth do people add in complexity rules that prevent arbitrary
character sequences?

What I'm getting at here is that if you had a 8 character password (for the
sake of the example), and you can type in lowercase letters, uppercase
letters, numbers and punctuation marks the total combinations of values is
95^8.

But then you remove all possible values of just numbers, all values that are
just letters, all values that are just special characters. That reduces the
set of combinations by (52^8) for alphabetic characters, then reduce further
by 10^8 for numeric only values, then 33^8 for special characters. That's
quite a few characters removed!

But then you get Apple's recent password requirement of no repeated characters
in their iCloud and App Store passwords. My math behind permutations is a bit
rusty, but that removes a hell of a lot of passwords as well.

On top of this, if you require at least one special character, alphanumeric
character, and at least one number, then that reduces the number of possible
passwords even further!

I've never understood how this made passwords safer... What am I missing?

~~~
Natanael_L
They assume people are using short stupid 90's style password rules. Which
many unfortunately are...

~~~
chris_wot
Not following...

~~~
Natanael_L
Stuff like aaa123

~~~
chris_wot
Well, if you put in xuui-659995!?)) then it won't let you use this either. How
does that make any sense?

Edit: In fact, interestingly I used a pseudo-"random" generator made up in my
brain. And there you have a big problem - I couldn't help myself but I grouped
letters, numbers and special characters.

I have to ask - if most of us do this, as we pick our own passwords, then
don't we by our very nature make it easier to crack our own passwords?

------
vortico
Abstract: pls use
[https://github.com/dropbox/zxcvbn](https://github.com/dropbox/zxcvbn)

~~~
repsilat
For most websites, users should just be warned that their password is
insecure, not forced to use a stronger one. Your website probably isn't
important enough to me to get its own strong password.

------
armabiz
I would also add to this statement that this shouldn't be user's problem, but
service problem. By forcing setting strange passwords services transfer their
problem to secure passwords to user's shoulders.

Instead of following shitty password rules in forms, it's better to make it
very hard or expensive to brute-force these passwords. So any heuristics to
identify ubnormal/dangerous activity and take an action by decreasing attacker
chances like rate limiting/captchas and so on.

    
    
      * If you see one IP trying to login with incorrect creds with really high rate - then it's probably attack.
      * If you see really lots of IPs trying to crack specific user account at the same time - then it's probably attack.
    

Instead of that I can see the opposite practice: service set draconian
password politics, but just allow requests with incorrect credentials without
any limits: "30req/sec? You're welcome, buddy! Need an API maybe?"

I can suspect something like this happened before:

"It looks like a lot of work with rate limiting and all the stuff, let's just
force our users to set 10+ character passwords with one+ capital letter, one+
number, one+ special character". Oh, and in these examples there is usually
cherry on cake like:

    
    
      - Dev1: "Let's not allow 2 same characters or 3 characters of same type"
      - Dev2: "Let's also force our users to change their passwords every 3 months"
      - CEO: "Brilliant ideas! We're secure now!"
    

These surprises are up to every developer's/another genius infosec imagination
:)

So, my conclusion is that best security systems should be almost invisible to
normal users and let attackers screaming.

------
xjay
Truncation: The browser could have warned users for years already. Pasting
something that gets cut off is data loss. Relying on a JavaScript
implementation to do this is a hack that only covers some sites (yes, you
could have an add-on, but no, that would require JavaScript, and it's still a
hack).

Binary Passwords: I could just copy/paste blocks of hexadecimal digits into
the password field using a fixed number of digits corresponding with the key
size, and they would be interpreted as a stream of unsigned binary octets. The
only thing you'd need to know was the length.

A suitable format is using hexadecimal. If you're using a password manager,
you already don't care about what the characters are, only that it is secure.

Passwords are also no longer limited to use printable characters.

How would you implement that for all users? Adding a prefix like 0x to enter
hex mode?

------
whoopdedo
I was disappointed to learn that Android wouldn't accept a password with non-
ASCII characters. I wanted to mix accents, punctuation, and symbols that are
all easily typed with the soft keyboard, but it was rejected as "too short"
because anything that wasn't between 0x20-0x7E was trimmed.

------
theophrastus
Apologies if this is a common held practice which i'm unaware, but why not
establish a policy amounting to: "if the system-admin can't somewhat trivially
crack your password then i won't bug you about it". That is, allow any
password, then if your chosen crack software can't crack that password, leave
them alone. If you can crack it then: "Please select another password, as our
trivial cracking software discovered it". This would strike me as a less user
burdensome method which would be more generally secure than every 13 weeks:
"9-12 characters including one of each of the following set"

------
AndyMcConachie
Or browser manufacturers could implement HOBA and we could stop worrying about
passwords for the web. Just sayin...

[http://tools.ietf.org/html/rfc7486](http://tools.ietf.org/html/rfc7486)

------
z3t4
Allowing 100,000 login attempts per second is in itself insecure! Using longer
passwords in that case is just treating the symptoms of a bad security
strategy.

Good security strategy: Have many layers of security! For example: Limit the
login attempts to max ten tries. And another layer, whether you like it or not
is to make users not use their "standard" password.

More security layers: hash+random salt, SSL, password timing, logging, 2-way
authentication, hiding, white-listing, ... a strong password =)

Please note the difference between cryptography and password authentication
though. In cryptography, a longer key is most likely always better.

------
dogancelik
I was looking for a cloud MongoDB provider, so I found MongoLab then I tried
to register. It didn't let me because my password didn't have a number in it,
do you want to know the password I used? Here's the password:

    
    
      U\"&%x#vdE
    

Their support site has more ridiculous password rules. Like one capitalized
letter, one number, one lowercase letter, one non-alphanumeric, etc.

I asked the support and he said this:

    
    
      Not all of our users are as savvy with security concerns.
    

I told them Google allows "aaaaaaab"...

I wish them to get rich with their non-savvy users, best of luck to them.

------
tsana
"Through 20 years of effort, we've successfully trained everyone to use
passwords that are hard for humans to remember, but easy for computers to
guess." Wow.

------
dheera
Pick whatever high-entropy passwords you want, and tack on "Aa$1" onto the end
of every password to deal with the silly systems.

------
jstoiko
Combination of words are the way to go. Often, when I tell people that, they
seem to get stuck probably because that's not what they've been used to doing.
I would be inclined to give some kind of hint to the user: "a good password,
easy to remember: pick at least 4 random words and separate them by a
character of your choice."

------
dendory
Password rules are needed, otherwise passwords would be even worse than they
are now, with people going back to using '1' or '1234'. They just need to be
better designed:

Must have at least 16 chars, OR Must have at least 8 chars with 1 number, 1
letter, 1 symbol, AND Must not have more than 3 repeating characters

~~~
JoeAltmaier
I think the rest of this thread, _and the OP_ , have been systematically
refuting that claim.

------
pjmlp
The worse ones are the constraints to which characters one isn't suppose to
use, which on my book only reveals sloppy coding as the developer wasn't able
to cope with arbitrary characters.

~~~
adamc
Sometimes it reveals things about the underlying system (e.g., that they are
storing passwords on a mainframe, or in a database with a different character
set).

------
frik
The iCloud and Microsoft account password rules are bad examples. The first
one forces one to use certain characters (uppercases, numbers) amd the second
one supports only up to 16 characters.

------
armabiz
Surprised of 99% agreement here at HN, because usually IT/security people in
majority of the cases don't understand me when saying ^^ the same.

------
gravypod
I also hate companies that won't let you use a space in your password. What
kind of crazy stuff is that?

Stuff like "I like spaces" would not work.

~~~
elinchrome
Maybe it's because spaces are unicode characters and they are worried that
their password system isn't unicode compatible.

------
cespare
Here's a collection of offenders:

[http://password-shaming.tumblr.com](http://password-shaming.tumblr.com)

------
jshc
totally agree. just to make things worse, the password rule on the client side
sometimes does not agree with the one on the server side. XD

------
kevinsimper
The problem is that those that enforce those rules does not read these
articles :( its sad

------
darkhorn
They want me to enter upper case letter. I enter Ö and it doesn't accept it

------
rdancer
Right on!

------
ErrantX
Argh! The XKCD entropy comic. Back away slowly..

The "4 common words" password meme was around a lot after that comic. However,
such passwords are definitely not secure because a good dictionary attack will
break it in hours. You do not have as much entropy as you think with them.

The same problem tangentially applies to his suggested password schema to.

The problem is: as soon as you start using human word or pseudo words then
your complexity decreases significantly.

With that said he has a point: password complexity schemas as employed by
websites are not good enough. It should enforce length and complexity properly
(not by saying "you must have these types of characters" but by really
analysing the password).

I appreciate the UX problems involved there... but then we could push people
towards using password managers and auto-generated passwords.

Summary: use a password manager and auto-generate complex passwords.

~~~
gambiting
No. For a dictionary attack, someone would need to know that you are using
words. They would need to know if they are separated by spaces, or dots or
slashes. The probability of someone knowing your personal scheme is
fantastically low, unless they already know one of your other passwords and
can guess it. A password like:

"Żółć zżółkła w gąszczu fantazyji!"

Is absolutely impossible to crack in any reasonable amount of time. It's a
perfectly valid sentence in Polish, but the attacker would need to know to use
a Polish dictionary, and also a one of these words is an old-Polish word which
will not appear in any modern dictionaries. Finally, they would need to know
you have an exclamation mark at the end.

It's literally impossible for someone to guess all of that, and this password
is infinitely easier to remember than !@#%#$@j4jnvdbst$#^@%$@#$#

~~~
Natanael_L
It has literally been done already. Obscure African poems have been guessed.

~~~
gambiting
By people who knew to look for obscure african poems? I mean sure, you could
guess a Polish sentence if you used a Polish dictionary, but how likely is
that?

~~~
Natanael_L
Very, because password crackers are literally including everything they can
come over.

~~~
gambiting
If they include "literally everything", then such humongous dictionary attack
would literally take longer than a simple brute force one.

