

Input type="password" Needs to Grow Up - ergo98
http://blog.yafla.com/input_typepassword_Needs_To_Grow_Up/

======
tptacek
There's so little payoff to this scheme that we can safely assume it will
never happen, as opposed to bickering about its merits. Here's a couple
issues:

* The hashes are themselves password-equivalent, so we've changed browsers and introduced a random crypto dep to arrive at a solution that doesn't improve the security of the app itself (anyone who can see the hash can log in).

* A Gawker-style breakin under this scheme is exactly as bad --- perhaps even worse † --- as it was before, because these hashes are also trivial to crack with an iterative password cracker (of the kind that have been the industry standard since 1990).

* It's now that much trickier to implement a real password storage scheme like scrypt.

There is already a cryptographically sound proposal to improve password-based
authentication on the web: SRP. I believe it's RFC 5054. SRP systems don't
store trivially cracked passwords on the server and never pass the password in
the clear. I don't anticipate widespread adoption anytime soon, but that's the
horse to bet on if you have to bet.

† _I'm not totally sure whether DES crypt(3) is faster or slower than
SHA1(salt, password), but if I had to guess, I'd guess SHA1 is faster ---
speed being one of its primary design goals. Speed kills in password hashes._

~~~
raganwald
The author suggests that this solves the phishing problem. Is that true, and
if so, is that worthwhile?

UPDATE: I wonder if the author is wrong about this. If we start with the
presumption that a user is susceptible to phishing, what can be done to
prevent them from entering their password into a text field that uses JS to
change their characters to little black circles? Now you'd have to create some
sort of browser feature like a "key" icon that appears somewhere outside of
the page when you are in a "hashed" password box, and you'd have to teach
users not to put passwords in a field that doesn't display the key. If you can
teach them all that, you can teach them not to be phished.

And oh yes, while you're trying to teach them that, Facebook is busy teaching
them to enter their passwords into a plain text box so they can "find their
friends."

~~~
tptacek
In a perfect world, it would lessen the impact of phishing by disclosing only
a crackable password hash to a phisher. In the real world, phishers will just
construct phishing sites that appear to use the "secure" password type but
actually don't.

~~~
jules
Then a password UI that can't be forged could be used, but I agree if you're
going to do it, do it right.

~~~
tptacek
Have you considered how hard it would be to create a password FORM input that
couldn't be forged?

~~~
metageek
How about this: if focus is in a password field, then you get a visual signal
somewhere in the chrome--e.g., the color of the location bar changes.
Something that HTML+JS just can't do.

~~~
tptacek
We can't train users to look for a lock icon to see if they're SSL encrypted,
so I'm not optimistic that something as subtle as a URL bar change is going to
guide them to secure password inputs.

------
tptacek
Arguing with everyone who disagrees with you, questioning their motives, and
then deleting all your comments is troll behavior. I actually took the time to
write the little C crypt(3) loop to make sure I wasn't crazy before making my
points; the person who instigated this thread couldn't even bear to stand
behind his own words.

On the off chance that anyone thought this was a graceful way to end a
pointless argument: no. It's cowardly and rude.

~~~
ergo98
How utterly boorish. If I could delete the submission I would because I see
zero productive value in it, and I'm a bit shocked at the stunning narrow
mindedness of so many.

My motive was simply to have a discussion about web security as it's a
recurring topic and element fraught with peril on a rapidly changing web
platform.

It's telling enough that you keep pounding on the SHA1 thing (despite the fact
that I repeated, time and time again, that the computational complexity of the
algorithm is of course open because the implementation doesn't exist. 128
rounds of blowfish if you prefer), that you keep misrepresenting the Gawker
attack, that you pretend that it's a proposal to replace SSL (no), and so on.
"Argument" to you is disagreement with Thomas Ptacek, who time and time again
bizarrely gets upvoted without merit or regard for accuracy.

It's a counterproductive discussion.

~~~
tptacek
128 rounds of Blowfish would still be a password-equivalent hash. You should
read up on SRP. Smart people who have spent much more time thinking about this
problem than we did have been studying it for over a decade. It's very
elegant, it addresses exactly the problem you're talking about, and it's a
standards-track technology.

It's true, by the way. "Argument" to me is "disagreement with Thomas Ptacek".
It would be pretty weird if argument meant something else to me.

A long time ago, I was on a comp.security.unix thread when Daniel J. Bernstein
said something that has been stuck in my head ever since. Responding to _"You
appear to be absolutely incapable of realising that there are people in this
world who can see more than one side to a question..."_ , he wrote:

 _On the contrary. I see both sides, and I have evaluated both sides, and I
have found that one side is vastly superior to the other. This may seem
ruthless, but that's how engineering works._

~~~
jacobolus
Google Groups link to the usenet discussion in question, in case anyone is
interested:

[http://groups.google.com/group/comp.security.unix/browse_thr...](http://groups.google.com/group/comp.security.unix/browse_thread/thread/d9f5a55bd2b5181f/2c109f52f04eecdd?q=%22have+evaluated+both+sides%22)

~~~
tptacek
Ahhhhh, Nick McClaren. Those were the days.

Incidentally, that's a thread that includes Tim Newsham, Wietse Venema, Daniel
Bernstein, and Theo de Raadt. Read it! I do not acquit myself well on it. I
miss Usenet, but I have gotten _much less_ obnoxious in the intervening
decade.

------
ComputerGuru
Really pointless. I posted this to the site:

 _< em>The password is automatically salted with the domain and username</em>

...which is exactly as secure as Gawker.com themselves doing a salt+hash.

Let's for a minute assume what you're proposing is what's being done. Gawker
has been attacked. The hacker has the columns "password" and "username".
Hacker knows the domain name. You're exactly where you left off!

Even if the password has been again hashed and salted on the server - that's
just an extra round of cracking (or, more realistically, rainbow-table
matching).

What you _should_ be doing is using a single, trusted and very much secure
password provider (a la OpenID). Hacker attacks your site, gains nothing. And
if you must do the authentication yourself, or the nature of your userbase
prevents you from outsourcing the authentication (perhaps <em>you</em> are the
OpenID provider we're talking about earlier), you need to be using something
more complex than a silly MDx or even SHAx to do the hash - these are made for
boiling down huge amounts of data into a small field of not more than
~256-4096 bytes - which is NOT what you want. Look at bcrypt - it's DESIGNED
for this. It's a solution waiting for more and more attacks like Gawker.com so
lazy and incompetent developers worldwide will use this existing, plug-and-
play, simple, direct, and safe alternative to what they're currently doing._

EDIT

Regarding rainbow tables - I'm predicting that with todays resources and cloud
super-computing, etc. (just look at the new EC2 GPU instances!) we're going to
see a new type of rainbow tables that actually precompute the hashes for
different salts as well. It's an order of magnitude larger data and more
computation than last generations rainbow tables, but todays tech is more than
an order of magnitude more available.

~~~
user24
> or, more realistically, rainbow-table matching

I think that's not true - you'd have to generate new rainbow tables for each
user for gawker. So this method would indeed make rainbow tables impractical.

edit: but I think the rest of what you said is fine.

~~~
tptacek
You already can't use "rainbow tables" on Gawker password hashes.

------
jasonkester
Look, the reason I use a single password for most of the sites I visit is that
_I don't care_ if you figure out my password for those sites.

So yes, if you run a site that wants to steal my password, you can do all
sorts of things pretending you're me, such as downloading copies of mysql,
posting to a few random message boards, watching my Hulu favorites, etc. None
of which are things I care about. That's why they all get the same user/pass.
Because I don't want to spend even one second dealing with user/pass stuff for
sites where security is not an issue.

Now, if you did somehow manage to get my Techcrunch password or whatever, you
still wouldn't be able to log into my Gmail account, Bank, or anything I care
about because I have strong passwords for those.

Notice how there is no technical solution to the above because there is _no
technical problem_ above. For 90% of the sites you need credentials for, those
credentials just are not worth bothering to secure.

------
wccrawford
Right, because we've never had to upgrade our security measures, so browsers
should have a set of measures built-in that can't be easily upgraded. That's a
great solution.

I think it would be a LOT more useful to have a site that discusses security
and the current best-practices for dealing with it. Instead of everyone taking
their best guess, let most people follow along until they have an idea to make
security better than standard. And if it really is better, it can be promoted
to the new standard.

------
drdaeman
There's already solution to phishing, remembering passwords and whatever else.
Only three words: client X.509 certificates.

Well, if Google'll fix Chromium to play nice with them.

------
bhickey
Stanford's Dan Boneh has written about this quite a bit:
<http://crypto.stanford.edu/~dabo/pubs/abstracts/pwdhash.html>
[http://crypto.stanford.edu/~dabo/pubs/abstracts/passwordmgr....](http://crypto.stanford.edu/~dabo/pubs/abstracts/passwordmgr.html)

------
mattberg
i assume the obvious issue with this is browser support? and what about mobile
platforms? and then having everyone agree on a standard method for the
salt/hash? sounds nice in theory though.

~~~
pygy_
This scheme has another fatal flaw: What happens when a site moves to another
domain?

All accounts will go poof...

~~~
Groxx
And how do you handle subdomains? Different hash, or same? They could be
different sites entirely, but they're also more likely to change, so you've
got the same domain-change problem.

------
IgorPartola
This scheme would break down as soon as you need to use the password not only
through your browser, but also through say SSH, sudo, or Thunderbird. Also,
just use a random password + your built-in password manager for the browser
with a master password. No yelling into the voids of the internet required.

------
Locke1689
Producing domain dependent hashes is a bad idea -- if the hash is properly
created (that is, not the way described in the post, proper key-strengthening
algorithms should be used) it should already be functionally one-way, meaning
that passwords would be completely non-portable.

~~~
goran
"that is, not the way described in the post, proper key-strengthening
algorithms should be used"

Like what? Please correct the post, becaues it seems to be quite vague about
the "key-strengthening algorithms". Secondly, non-portability of the passwords
is the entire purpose.

This is my first exposure to Hacker News, after hearing nothing but good
things about it, and honestly it has been a shocking disappointment.

I read the article, thought it sounded interesting if incomplete, and felt
mildly enlightened.

Since then I've watched as post after post has either misreprented what it
actually said, or simply posted something completely wrong. Most of the people
in this discussion seemingly don't know what a hash, salt, rainbow attack or
dictionary attack are.

It is very disappointing. I will continue my downward cycle of points with
this post, so this shall be my swan song, but really this place is no more
illuminated, or no less a circle jerk, than Reddit r/programming.
Disappointing.

~~~
Locke1689
_Secondly, non-portability of the passwords is the entire purpose._

Non-portability of the passwords _outside of the site_ is the purpose, but
what if you wish to use the same password database on either a varying
subdomain or on the same network, well, that wouldn't be possible. For
example, Gawker runs a number of different properties and shares passwords
between them. This is impossible if passwords are domain-encoded. This also
has consequences for sites like Google which also use account sharing across
domains (including some of their Same-Origin Policy domains to enable cross-
site interaction).

 _Like what? Please correct the post, becaues it seems to be quite vague about
the "key-strengthening algorithms"._

You may want to read the Wikipedia article[1] on key-strengthening. If you
have mostly been exposed to older cryptographic techniques (e.g. salting and
rainbow tables), this will tell you the basics of more advanced (and modern)
password cracking. The most important thing that the article screws up is
encourages non-standard cryptography usage. Cryptography is ridiculously
difficult to get right even if you're an expert so cryptographic
recommendations should always be based around a standard written by
cryptographic professionals. The RSA standard here would be PBKDF2[2], while
Hacker News' own cryptography research Colin Percival wrote a utility called
scrypt[3] for the truly paranoid among us. This full category of strong
password negotation and verification is embodied in the SRP[4] standard, which
uses similar techniques.

 _Most of the people in this discussion seemingly don't know what a hash,
salt, rainbow attack or dictionary attack are._

Eh, some people it seems are misinformed. tptacek, for example, knows what
he's talking about. He's correct that SRP is really the relevant standard for
the full authentication system here, as well.

 _Since then I've watched as post after post has either misreprented what it
actually said, or simply posted something completely wrong._

The post also spends a tad too much time coming up with "fake" solutions --
that is, solutions which take little effort to get 90% of the way there but a
huge amount of effort to take to 100%.

 _It is very disappointing. I will continue my downward cycle of points with
this post, so this shall be my swan song, but really this place is no more
illuminated, or no less a circle jerk, than Reddit r/programming._

From my latest browsing in Reddit, r/programming seems to be a congregation of
unusually determined morons, but to each his or her own I guess. One of the
reasons you may have been downvoted (which has gotten a little excessive here
as of late, but I digress) is that your comments actually don't contain a lot
of information in them. For example, one of your posts just says "you're
wrong." This _may_ just barely get by if you're an established member of the
community with public credentials to back up your point but you have no
history, no name, and no information. Why should we think you're anything
other than an angry idiot with a keyboard?

[1] <http://en.wikipedia.org/wiki/Key_strengthening>

[2] <http://www.rsa.com/rsalabs/node.asp?id=2127>

[3] <http://www.tarsnap.com/scrypt.html>

[4] <http://srp.stanford.edu/>

~~~
joh6nn
_He's correct that SRP is really the relevant standard for the full
authentication system here, as well._

see, this is one of the places where I get confused. i don't read this
proposal as being an authentication system. i read it as being an attempt to
aid users in creating strong passwords that are not shared across sites. the
proposed implementation certainly isn't perfect (i much prefer the
implementation provided by <https://addons.mozilla.org/en-
US/firefox/addon/3282/> , but that also has problems ), but it seems to me
that many of the critiques presented so far are trying to measure this
proposal against the wrong metrics.

~~~
Locke1689
First sentence of "What is SRP?":

 _SRP is a secure password-based authentication and key-exchange protocol._

~~~
joh6nn
"this proposal" was meant to refer to the article, not SRP. hence my comment
that we're measuring it against the wrong metrics: it's no surprise that this
proposal doesn't stack up when compared to SRP, since, to my reading, it isn't
meant to be compared to it.

------
pixelcort
I wonder how well client-side SSL certificates could aid in this process. This
way servers would only have the public key of a user and as long as the user
doesn't compromise their private key they'd be safe.

~~~
andfarm
They're certainly available -- at least, in Mozilla -- but usability is poor.
The most obvious issue is that there's no obvious way to copy a client-side
certificate to another machine, making it incredibly awkward for users who use
multiple computers (or, worse, who only have access to shared computers).

------
pornel
It does not solve phishing _at all_. Phishers simply won't add secure flag to
the input, and will get raw password needed to create hash for every site.

Even if all password inputs were always hashed, phishers could write their own
plaintext-stealing imitations in JavaScript.

------
hackermom
Like others here have mentioned, what the writer is missing is that when a
single solution for creating these hashes are implemented, web-wide, browser-
wide, the hashes themselves are equal to the passwords. On this merit alone,
the proposal fails.

~~~
joh6nn
i'm not sure i understand why that's a failure. my understanding is that's the
point: every user now has a password that is unique on a per-domain basis. i
don't understand this to be an attempt to protect against the kind of attack
that gave access to the gawker passwords, but rather an attempt to limit the
scope of such an attack to only a single site.

if there's something that i'm missing here, can you please elaborate on it?

