
Authentication Cheat Sheet - colund
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
======
oneeyedpigeon
"Applications should enforce password complexity rules to discourage easy to
guess passwords." \- ARGH!

To clarify, to avoid downvotes for a non-'productive' comment, I firmly
disagree since this will probably result in me having to pick a password
that's harder to remember than I otherwise would. It might also might it more
awkward to type quickly, making shoulder-surfing easier.

(Note that this is probably not i18n-friendly, either)

~~~
paulojreis
At my company this typically results in users printing or writing the password
down.

I wonder if the guys who create these heuristics/recommendations ever had
contact with humans. I believe that their research is thorough in their area
of expertise (info sec), however, it sounds like they are only considering
data _per se_ , ignoring human behavior variables. There's little value in
enforcing hard-to-break passwords while also encouraging users to write them
down.

What I believe: Info sec researchers should team up with HCI people.

~~~
tinco
There's not much wrong with writing passwords down. Printing thema is less
desirable.

It's a hundred times better to have a difficult password on a post-it on a
monitor than it is to have an easily guessable password. Who do you suspect is
going to hack you? Ask that question honestly and you'll know how best to
thwart them.

~~~
paulojreis
I understand your point, and I agree that the biggest threats aren't
physically nearby. In that scenario ("remote" attacks), of course, there are
bigger problems than written/printed passwords.

However, at the enterprise level, physically visible passwords are a big
problem. Imagine a less-than-happy worker, about to leave the company, having
the opportunity to get coworkers passwords. In such scenario, less strict
rules (let's say, rules that didn't make people writing the passwords down)
would have been beneficial.

And there's another point: the "perception" about IT security rules. If they
ask too much of people (think "non-IT people"), they might create a image of
overzealousness/"overcomplication". I wonder if this doesn't make people less
compliant, with security rules, on the long term.

------
beobab
"An application should respond with a generic error message regardless of
whether the user ID or password was incorrect."

I really don't like this advice (although I see why they put it in there).

I often use different email addresses for different services so that I can
determine who sells on email addresses (depending on how much I trust them),
and quite often I can't remember which email address I signed up with (was
that mojang@...com or minecraft@...com).

At least if I see "user not recognised", I know to try a different email
address.

~~~
jessaustin
So just keep trying addresses until you get a reset link sent to you. It's
really unacceptable for any service to leak its user list in the way you
suggest.

EDIT: x1j7xJuzX in the sibling subthread has it right for email addresses.
It's true that separate usernames would be difficult to handle in a user-
friendly manner without leaking, but with a valid email address a separate
username is probably unnecessary. It doesn't help the user interact with the
site. If users interact with each other, they can just choose non-unique
display names. To prevent impersonation, just use display name plus some other
invariant account property to generate a hash that is displayed alongside the
display name.

~~~
oneeyedpigeon
How do you avoid 'leaking the user list' if you enforce unique usernames?

~~~
sanderjd
If you use email as username, you can make the sign up give the same "check
your email to confirm your account" message for a new account and an existing
account. This works well for new users and those who have already signed up
but perhaps forgot, and leaks no information to someone who doesn't have
access to that email account.

I'm not sure how to do this just for usernames, but usernames are less
sensitive than emails anyway.

------
billyhoffman
_" Maximum password length should not be set too low, as it will prevent users
from creating passphrases. Typical maximum length is 128 characters."_

Why would you ever have a maximum password length at all? bcrypt or (god
forbid) your secure hashing algorithm of choice doesn't care about input
length, and has a fixed output length to stick in a database. Why on earth
would you limit the password length beyond anything so insanely large (1024,
etc) to not even matter?

~~~
marklit
Hashing passwords takes a lot of CPU resources. Django limited their password
lengths to a maximum 4,096 characters because of this:
[https://www.djangoproject.com/weblog/2013/sep/15/security/](https://www.djangoproject.com/weblog/2013/sep/15/security/)

~~~
venaoy
The Django developers are wrong to blame PBKDF2 for this slowness. It takes
just 1 second with an unoptimized Python PBKDF2 to hash a 1MB password, and
probably 0.1 second or less with a native implementation. If they claim it
takes 1 full minute, they must be doing something seriously wrong, like using
a crappy parsing or serialization mechanism to pass a 1MB string around
higher-level modules.

    
    
      $ time python -c 'import pbkdf2; print pbkdf2.crypt("a"*1000000,"XXXXXXXX")'
      $p5k2$$XXXXXXXX$hmAHZehesTpLs.pM3G4mKlHZI6/FMj.Y
      
      real	0m1.233s
      user	0m1.221s
      sys	0m0.012s

~~~
Someone1234
By default that uses 400 iterations, the current recommended is 10,000. Try it
again with 10,000.

~~~
venaoy
Indeed: 28 seconds with 10,000 iterations. I assumed Django was iterating 400
times. I was wrong. Thanks for correcting.

------
birdmanjeremy
Every time you introduce a password constraint, you've reduced the potential
password complexity. I absolutely hate arbitrary password requirements. "not
more than 2 identical characters in a row"? WTF? Stop with this nonsense.

~~~
kitd
_" not more than 2 identical characters in a row"? WTF? Stop with this
nonsense._

This is OT, but there's an interesting snippet in "The Secret Life of
Bletchley Park" [1] about decoding Enigma messages used by the Italian Navy in
the Med.

One of the female operators had a set of messages from one Italian operator
who sent a message once a week on a regular basis. They had determined that
the first letter was an 'L'. She looked at the keyboard, saw that 'L' was
neatly placed under the right hand and guessed that he was sending a test
message consisting of nothing but 'L's tapped out in quick succession. Voila!
She hit the jackpot.

From this insight, all dial wirings and movements of the Italian machines
could be quickly deduced.

So, repetitive plain text _can be_ a security issue.

[1] [http://www.amazon.com/The-Secret-Life-Bletchley-
Park/dp/1845...](http://www.amazon.com/The-Secret-Life-Bletchley-
Park/dp/1845136330)

~~~
Zikes
That's a vulnerability for cyphers and has no application to modern password
systems. If a password were all Ls up to the minimum then certainly that would
be a bad idea, but having two Ls in a row because your password happens to
contain or be a derivative of a word that has two Ls has no bearing on how
secure the password is.

    
    
        sha256(LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL+mysalt) = 57c70b4fddd06c94c9a7b41d9884591bb1d487fb78df723b11bc4892e879f46e
        sha256(LRpSdU$EnD1ZrJJ2QyVHPycN*DZtrHm&YdH%%28f4ih+mysalt) = 29cd0708db0fb7350e17349012a6e728b357ef733e85f401fc757e6565ef5e80
    

Neither of those hashes would give an attacker the slightest bit of insight
into the user's password even if the attacker suspected the first letter of
each were an L.

~~~
hackuser
> having two Ls in a row ... has no bearing on how secure the password is.

At least some password cracking programs are built to anticipate human
tendencies, which I would guess includes repeating characters. If I were
designing a password cracker, I would target human-created passwords and not
random passwords. For example, I would have the program guess 123456 before it
guesses R%Vg9~\

~~~
Zikes
The other complexity rules rule that out, though.

If I have a password 10 characters long with at least one uppercase, one
lowercase, 1 digit, and 1 special character then having one of those repeated
won't make it any less secure. Rigidly enforcing that rule doesn't make sense,
it's saying that "R%Vg9~\LL" is _less_ secure than "R%Vg9~\".

------
AUmrysh
A big one I've seen is more related to the TLS cheat sheet [1] they link to on
that page.

Many sites will send session tokens over http because they don't set the
"secure" cookie flag. It's a simple thing to do, and prevents a malicious ARP
poison or DNS attack from potentially hijacking an account.

You'd be surprised how many sites are vulnerable to such attacks. Reddit,
parts of Ebay, several university websites, and many other sites still are
vulnerable to session hijacking.

I think people writing web libraries need to start building "sane defaults"
concerning security. All cookies should be secure by default, and only those
who know what they are doing should turn them off. It's not that much extra
overhead, and the potential benefits outweigh the increased processing and
bandwidth.

1:
[https://www.owasp.org/index.php/Transport_Layer_Protection_C...](https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-
_Use_.22Secure.22_Cookie_Flag)

~~~
Someone1234
Great point. Setting "SECURE" and the poorly named "HTTP" are key to cookie
security.

One issue we ran into was: So our site runs behind a load balancer. We receive
HTTPS connections into the load balancer but the internal connection between
the load balancer and the actual websites was HTTP only, so when we tried to
set SECURE on the cookies, the application framework we were using trying to
be "helpful" unset the SECURE flag because it detected that the connect from
its perspective was not secure (even though from the browser's perspective it
was).

Keep in mind that the connection between load balancer and web-servers was
never on the internet, in fact it never left a virtual machine farm (a single
room essentially). So it is justifiable doing HTTP internally and HTTPS
externally (and also makes certificate management easier).

We finally had to hack away a bit on the framework to get it to set secure
regardless of the connection type.

------
pc86
> not more than 2 identical characters in a row (e.g., 111 not allowed)

Why? If my password is _id8FK38f@ &&#d_ is it inherently less secure if _111_
appears in the middle of it somewhere?

~~~
pluma
Next revision:

> no prime numbers, no more than 2 even or odd numbers in a row (e.g., 644 not
> allowed), no sequence of 2 or more characters may repeat more than 2 times
> (e.g. aabaa not allowed), no ascending or descending sequences longer than 2
> characters in a row (e.g. 123 or cba not allowed)

~~~
pc86
These are just rules for the sake of having rules. It's downright silly and
honestly it makes OWASP look like a joke to have something this ridiculous on
their domain.

~~~
pluma
That was actually sarcasm (reductio ad absurdum), not an actual quote.

I think I've seen password restrictions similar in spirit to those, though.

~~~
pc86
I honestly couldn't tell. I think that in itself says something...

------
darkhorn
Some of the suggestions are bad. Why they are enforcing English characters?
Like a-z? For example in Github I write щ and then it wants me to write a
lowercase letter. WTF? It is lowercase! And more secure than an English
letter!

------
samspot
Do people REALLY brute force passwords? Do people REALLY brute force all
lowercase, all latin combinations up to 20 characters before trying symbols,
uppercase and numbers?

I am very skeptical that the '3/4 complexity rules' approach is making systems
meaningfully more secure. I've had all kinds of passwords, but I've never lost
them to brute force. Every time it was because someone got inside a company
and made off with the database.

If complexity rules don't add anything, they should be discarded in the name
of usability.

~~~
Someone1234
> Do people REALLY brute force passwords?

Yes. Source: I have, multiple times.

> Do people REALLY brute force all lowercase, all latin combinations up to 20
> characters before trying symbols, uppercase and numbers?

Remotely? No. Locally? Yes.

If I have some hashes, I am going to be doing every combination of characters
at least up to 8 digits. If they're using something bad like 3DES or MD5 then
I can go up to 20 digits and check everything.

Remotely you're typically using a common password dictionary which is just a
few thousands passwords people often use. If you had a botnet you might be
able to do every combination (I don't).

> I am very skeptical that the '3/4 complexity rules' approach is making
> systems meaningfully more secure.

Nor am I. I am more an XKCD-sentence password fan myself...

I really like entropy calculators. They're much more useful than broad generic
requirements that actually reduce the set of potential passwords.

The entropy calculators that give people "prods" (so there are no
requirements, just a traffic light system) are absolutely wonderful.

> I've never lost them to brute force. Every time it was because someone got
> inside a company and made off with the database

Which still requires brute forcing assuming the passwords are stored
correctly. If it is something modern like PBKDF2 with a decent number of
iterations (e.g. 10K rounds) it can be a nightmare even if your password is
"just" 8 digits.

> If complexity rules don't add anything, they should be discarded in the name
> of usability.

Agreed. They aren't even based on any research, someone in the 1980s just
thought they "sounded" secure. Nobody has spent any time actually researching
this, we just repeat the same tired advice from thirty years ago because
"common sense" tells us it is a good idea.

------
cddotdotslash
Just a hypothetical, but what if an application started encouraging users to
enter a "login sentence" instead of a password. i.e.: "Please enter a sentence
that you'll be asked to remember each time you login." Obviously, the standard
constraints of length and complexity (albeit slightly altered) can be
enforced.

It's much easier for me to remember "Please close the window, I'm cold." then
it is for me to remember "XSDJd94*(lo03X.._".

The "horse battery staple" XKCD comes to mind.

~~~
daddykotex
That could be an interesting idea, but I'm wondering if the user wouldn't
expect an unobfuscated input box to type in his sentence. Or if he would
expect : "Please close the window, I'm cold." to be the same as "Please close
the window, I'm cold" (no end period here)

~~~
VLM
If you ate all the whitespace and punctuation and uppercase'd it as part of
your password input routine, it wouldn't be all that much worse than existing
shorter passwords yet make life a lot easier for valid users.

Another interesting strategy, not discussed so far, is everyone in almost all
lives and professions has some pool of weird technical names that can be
concatenated together for a password. I'm partial to "unpopular yet cool
integrated circuit ID codes of the 80s". I thought I invented that idea and
was introduced to an old programmer using concatenated library calls from
multiple languages (so his passwords were concatenations like a java soundex
algo library call followed by some obscure fortran matrix manipulation) My mom
knows the long legal names of some obscure real estate cases / judgments /
citations / forms.

------
Karunamon
_The correct response does not indicate if the user ID or password is the
incorrect parameter and hence inferring a valid user ID._

ARGH. This is a usability nightmare - moreso when the recovery system
implements the same rule.

"Okay, I had an account on this website, which email address was it again?"

 _try logging in a few times_

"Hm.. I must have forgotten the password. Off to reset!"

 _go through the recovery process_

 _recovery page indicates an email will be sent_

 _email never comes_

"Wait, so are they being 'really secure', or is email just broken right now?"

 _wait a couple hours_

 _forget about the site_

~~~
davyjones
The trick here is it not go to the reset page but to the signup page. Almost
always, there is a message that indicates that the email id is already taken.

(which is why _I_ think that indicating specifically, that the userid was
incorrect or the password was, is better UX.)

------
bohinjc

      The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a *403* for a negative result.
    

I would say a _401 - Unauthorized_ with proper _WWW-Authenticate_ header.

403 means forbidden, which apply to when you try to access a resource without
permission / authorization

Also, in their _Password Storage Cheat Sheet_
[[https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet)],
they seems to recommend :

    
    
      Select:
        PBKDF2 [*4] when FIPS certification or enterprise support on many platforms is required;
        scrypt [*5] where resisting any/all hardware accelerated attacks is necessary but support isn’t.
        bcrypt where PBKDF2 or scrypt support is not available.
    

AFAIK, things are not so binary :

* [https://news.ycombinator.com/item?id=3724560](https://news.ycombinator.com/item?id=3724560)

* [http://security.stackexchange.com/questions/4781/do-any-secu...](http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415)

* [http://security.stackexchange.com/questions/26245/is-bcrypt-...](http://security.stackexchange.com/questions/26245/is-bcrypt-better-than-scrypt/26253#26253)

~~~
pluma
There are different interpretations of what 401 should be used for. The spec
only handles WWW-Authenticate authentication, which is pretty limited and not
universally used (Bearer auth is occasionally used for APIs but Basic auth is
pretty rare -- especially in end-user-facing parts of the web). The problem is
likely that when the status codes were defined nobody thought people would
ever need to build their own login forms.

I agree that it is more useful to use 401 to indicate that some form of
authentication is required or has failed, and 403 to indicate that you are
authenticated but not allowed to access something (which is what the spec
emphasizes).

IOW, 403 should be "Unauthorized", 401 should be "Unauthenticated". Sadly the
spec mixes those two meanings in various places.

~~~
bohinjc
I usually do set WWW-Authenticate to None or WebForm (to prevent browsers to
pop-up basic auth dialog).

And I agree with ambiguous spec on those concerns.

------
dpweb
Simplicity should be a primary goal in the methods used to protect systems.
Just because the methods to protect are easy, doesn't mean its easy to crack.
For instance, a decent size password and lockout and you're set as far as
brute force attacks. They are not going to guess a 10 letter password in 5
tries. After x tries, make them reset. Two factor auth for _really_ important
stuff, isn't that pretty much it.

I believe we're seeing more successful attacks from the use of security
techniques that are unnecessarily complex and not completely understood (or
partially implemented) by most engineers - than cause passwords aren't long
enough.

------
snarfy
Password complexity rules are stupid. The only thing that matters is the total
entropy. "Entropy too low" is the only error a user should receive when coming
up with a password.

Those complexity rules are the result of an entire industry blindly following
the best practices of an old unix DES crypt function. It's dumb and it should
stop.

[http://security.stackexchange.com/questions/33470/what-
techn...](http://security.stackexchange.com/questions/33470/what-technical-
reasons-are-there-to-have-low-maximum-password-lengths)

~~~
gear54rus
Going a step further, I don't even understand why we need any kinds of un-
skippable errors because of this.

If I wanted a single number, say, '1' as my password, why shouldn't I be able
to use it? It is my account and my responsibility, why does everyone feel the
need to enforce something on others.

A simple warning would suffice.

~~~
onion2k
A compromised account affects more than just the account owner. In many
scenarios it's possible to escalate privileges and take over an entire service
- your password might be all that stands between a malicious user and
_everyone 's_ accounts.

~~~
gear54rus
I can see how this may be a problem for invite-only systems, but a place where
anyone can create an account? Plz...

In a scenario like GitHub's organization (where one user has privileges over
many shared resources), for example, its owner still carries the
responsibility of safety of all its resources.

If it's possible to escalate privileges, then that's the place that needs
fixing.

------
pippy
He forgot an important modern rule on authentication: don't do it.

If you can get another system to do it for you; persona, OpenID, Github,
Google, Facebook, or twitter it's more secure for the end user. They have
features such as two factor authentication, fraud detection, manage password
resets for you, and the end user is more likely already have an account.

Many developers don't agree with this on a moral level, as you are giving
power to third party. However developers are developers, and if you do it
yourself you're bound to do at least one thing wrong.

~~~
dman
Might be a sample of one - but I dont use any services which requires me to
provide a google / github / twitter account. I have very little trust in what
I am authorizing the service to do on my behalf. Perhaps this wariness has
come from my experiences with linkedin where I have been negatively surprised
on more than one occasion.

------
Gargoyle888
Isn't 2FA the best approach? I'm just asking.

A problem here where I work is that every application must have a different
password and it must change every 90 days. Consequently everyone has a
spreadsheet with his passwords written down because nobody could possibly
remember them all.

It seems to me that with 2FA, one simple password is adequate. Two independent
devices need to be compromised and brute force is ineffective since the turn
around time is at least several seconds between tries.

~~~
tjbiddle
One simple password is never adequate as that then trains the user to continue
doing that across other sites - regardless of their use of 2FA.

I've found the best solution for me is to use a password manage (Personally, I
use LastPass) and enable MFA/2FA across everything that allows it.

------
peterwwillis
This doesn't touch on commercial authentication managers and how horribly they
can be implemented. There's no authorization cheat sheet either.

They also make assumptions like "When multi-factor is implemented and active,
account lockout may no longer be necessary." Sure, until someone finds a
simple hole in one of the factors and the rest become trivially brute-forced,
sniffed, phished, etc. The chain is only as strong as the weakest link.

------
zobzu
I dont really like this page. Its a good effort.. but. (no ands!).

\- Most things are just a flyby, such as "hey look heres a paragraph that
tells your what MFA is". but doesnt tell you how to use it.

\- Password rules are outdated "use caps, 10 char, numbers, etc!". The horse
staple blabla has been the new standard for yearS now... and is way better..
generating the password for the user is often not a bad idea

\- no mention of upcoming techs like FIDO/U2F

------
sekasi
This is not a accusing comment, but more of a request for more information:

"Passphrases shorter than 20 characters are usually considered weak if they
only consist of lower case Latin characters."

This goes against the concept of diceware generated passwords of 4-6 short
words doesn't it? Where in this equation am I getting it wrong? I've been
approaching passwords like this for a while now.

------
jakubp
"An application should respond with a generic error message regardless of
whether the user ID or password was incorrect. It should also give no
indication to the status of an existing account."

If so.. then how to respond on user registration page when someone tries to
open a new account with username / email address of an existing account?

~~~
boobsbr

        cat registrationError.php
    
        <?php echo "we don't want your kind here. go away." ?>

------
caseyf7
and if you use email addresses as user names, verify they actually own the
email address. Apple doesn't do this, and I'm amazed at how many people sign
up for iTunes with email addresses I control.

------
homakov
OTP passwords dont fight client side malware lol.

------
jjarmoc
Some of this is good advice, but there's a BIG point on the 'Password Storage
Cheatsheet' that's linked and referenced by the above article, that I don't
think is solid.
[https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet...](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Leverage_Keyed_functions)

Specifically, it suggests storing passwords using: `return [salt] + HMAC-
SHA-256([key], [salt] + [credential]);`

It goes on to note that the key must be protected as private, strongly random,
and stored outside the credential store, while the salt (can we please call it
a nonce?) can be safely stored against credentials.

I'm still not comfortable with this construction. Stick with their earlier
advice and use scrypt, bcrypt, or PBKDF2. That's my order of preference too,
which differs from theirs somewhat, but that's a minor quibble; all three are
reasonable.

The problem with their construction is that HMAC-SHA-256() is designed to be
fast, and so attackers have the opportunity to make a lot of guesses quickly.
The secrecy of the key helps over a straight SH256(...), but not a lot for the
following reasons:

1 - It assumes an attacker who compromises the credential store won't also
have the key.

2 - It assumes an attacker is unable to recover the key.

1) is a valid assumption for certain classes of attack. If your key is stored
in an environment variable or something, while credentials are stored in a
database, an attacker who compromises your database via a SQL injection won't
have the key. But the problem is that an attacker who compromises the
application may. If I have full remote code execution on the server (and you
have a bad day then, passwords aside) I'll have the key. Or maybe an attacker
has an arbitrary file read (not quite as bad a day), and you store your key in
a flat file on disk. Or an attacker can cause your application to generate a
stack trace (disclosing runtime details) and view the key...

You get the idea - there's lots of potential ways to get that key regardless
how you store it, and everything hinges on that. Once they have the key, they
can mount dictionary or brute force attacks against credentials just as they
would against `SHA256([salt]+[credential])`

2) is a valid assumption only if the attacker doesn't know a single password's
plaintext value and the key is sufficiently long and random. If I know the
password to my own account (and I likely do) or any other account (let's say
one user on the site uses a password that was recovered in another breach)
this scheme fails.

Suppose my salt is "SALTYSALT" (okay, so my PRNG sucks; also a detail to be
wary of) and my password is ye olde "PASSWORD" (yah, this sucks too.. but it's
my crappy password. Maybe I added it just to observe the resulting HMAC
value?) Now I can just try calculating `HMAC-SHA-256("A", "SALYTSALT" \+
"PASSWORD")` If that doesn't match, try `HMAC-SHA-256("B", "SALYTSALT" \+
"PASSWORD") and so on. The one thing I don't really know that would help is
the length of the key. If it's long enough (We'd want at least 256 bits), and
strongly random, I may have a difficult time. It it's short (And they make no
recommendation on it's length, just that you "Generate the key using
cryptographically-strong pseudo-random data"), I'm going to crack the key, and
then I'm back to attacking all the other credentials.

I _MIGHT_ be convinced of this being reasonable if it can be ensured that all
the HMAC calculations are done in something like an HSA or TPM which generates
a large key internally and doesn't expose it, even to the application. But
that's probably not the scenario we're talking about here. Even then, you've
got nothing to lose by using an adaptive algorithm rather than the HMAC
construct. For anything else, it's far safer (and easier really!) to use
scrypt, bcrypt, or PBKDF2. So just do that.

~~~
timo_h
_Some of this is good advice, but there 's a BIG point on the 'Password
Storage Cheatsheet' that's linked and referenced by the above article, that I
don't think is solid._

I read they recommend to use the both (adaptive hashing and "local
parameterization"). As even if you utilize separate device (HSM for example)
for encrypting the passwords (I'd encrypt instead HMAC), you should indeed not
give up on adaptive hashing.

Here's some good commentary on this by Solar Designer (user solardiz on
Reddit):
[http://www.reddit.com/r/netsec/comments/26d52c/yescrypt_pass...](http://www.reddit.com/r/netsec/comments/26d52c/yescrypt_password_hashing_scalable_beyond_bcrypt/chqajgu)

~~~
jjarmoc
"I read they recommend to use the both (adaptive hashing and "local
parameterization")."

I read their text as recommending A or B, based on the intro where they state
"Two approaches facilitate this, each imperfectly."

"As even if you utilize separate device (HSM for example) for encrypting the
passwords (I'd encrypt instead HMAC), you should indeed not give up on
adaptive hashing."

Right, this is the sort of thing that led me to hedge by saying I _MIGHT_ be
convinced if an HMAC were involved; it still gives me pause, for sure.

