
Why you shoud never use your favorite password on News.YCombinator.com - kwdowicz
http://rafb.net/p/DpOfOD83.html
======
cperciva
Of course the password is in plaintext. Logins are done via HTTP, not via
HTTPS. You know, there isn't that little yellow lock thingy in the bottom left
corner of the window?

Is this really news to anyone?

~~~
hsiung
There are still ways to add a little extra security for non-ssl logins. One
way is by hashing the password via javascript with a random number provided by
the server before posting it via HTTP. (see
<http://pajhome.org.uk/crypt/md5/auth.html>)

~~~
tptacek
That adds _no security at all_. Security is not an obstacle course.

~~~
thorax
Security is _nothing but_ an obstacle course. The only time security is not
merely an obstacle course is when you completely destroy the thing you're
trying to protect.

This is fundamentally something everyone needs to understand about computer
security-- it's all about creating bigger and harder obstacles (including
literal, physical obstacles). You can never _absolutely_ secure something
while it exists.

~~~
tptacek
That's a fine argument for rejecting all of engineering. An asteroid could
always strike the bridge we're building! Why bother making it structurally
sound?

~~~
thorax
I'm not sure why you're treating my comment as an argument to reject security
(or to reject anything other than your specific wording choice). I'm just
saying that security, fundamentally, is about making obstacles.

There's nothing implied there regarding the importance/unimportance/quality of
those obstacles. I don't think understanding its fundamental nature takes
anything away from Security.

~~~
tptacek
That's really not true. I think you're conflating cryptography with security.
In crypto, I suppose you could consider algorithms that increase attacker cost
as "obstacles", though I think the word loses meaning when the "obstacle"
involves summoning more CPU cores than there are atoms in the solar system.

In practical security, closing a buffer overflow, sanitizing inputs, and
proving code paths are not "obstacles". There are a finite number of
vulnerabilities in any piece of code.

~~~
DougBTX
_In practical security, closing a buffer overflow, sanitizing inputs, and
proving code paths are not "obstacles"._

I think you're being a bit picky over wording, an "obstacle" is just something
which makes it harder for some to break your system, examples of which are
closing buffer overflows and sanitizing inputs.

You could, possibly, use it as an argument against engineering, but I think
you'd be wrong. The same as someone arguing "we're all going to die anyway so
lets get it over with now" is wrong: it means that you have to make the most
of what you do have.

~~~
tptacek
This isn't just pickiness. This is two totally conflicting mindsets about
security. I'll be ungenerous and say that mine, which rejects the concept of
obstacle courses, is the practitioner's mindset.

We don't let things ship when we know they have exploitable vulnerabilities.
We recognize that there are known unknowns and unknown unknowns, and we try to
mitigate the former. But the known knowns? Come on. Just turn SSL on. The
Javascript rewriting hack is _not hard_.

------
axod
1\. Go read up on HTTP vs HTTPS

2\. Never use the same login for 2 websites

The fact this has been upvoted to top position is more worrying than any
security worries.

~~~
mhartl
_Never use the same login for 2 websites_

Dude, my brain would explode.

~~~
axod
It's not like you have to remember them... I just use a script that based on a
site name/keyword I give it, generates a password for me. Then the browser
remembers it.

Of course that means if anyone steals my laptop they have all my logins, but
that's extremely unlikely.

~~~
eru
"It's not like you have to remember them... I just use a script that based on
a site name/keyword I give it, generates a password for me. Then the browser
remembers it.

Of course that means if anyone steals my laptop they have all my logins."

Would have gone down better, I guess.

~~~
axod
Well... I never leave the house and live in a guarded fort.

~~~
eru
Why do you need a laptop then?

~~~
axod
You can't take a desktop on the toilet, bed, sofa, bath etc

------
fourlittlebees
I use a password manager, and auto-generate a new 12-char pwd for every site I
register with. Of course, if anyone would like to hack into my bank info and
assume my debt, I will be more than happy to oblige. ;)

------
antirez
Not being able to downvote this is what you get on the frontpage...

------
arthurk
You can do this with most sites.

I don't know how much more load SSL would cause but a good solution would be
to just use HTTPS for the login and then redirect back to the HTTP, like
Twitter does.

------
rsheridan6
I wish I could say I was surprised, but I'm not. If you look at websites that
don't involve transferring money, you'll find a lot of passwords transferred
in plain text. It should not be so, but it is.

I use the same password here that I use on other sites which aren't very
critical and which wouldn't really do me any harm if my account were cracked.

------
ig1
_sigh_ the correct solution for this problem is SRP (see RFC 2945) which
provides a secure transfer of password data and can be (and has been)
implemented in javascript.

However while that solution will prevent packet sniffing, if you want to
prevent phishing attacks you still need to use SSL

~~~
tptacek
You can't implement SRP securely in Javascript, as I've repeat ad nauseum here
--- attackers redirect traffic, they don't just sniff it, and when they do
that, they can trivially rewrite the JS that delivers the SRP code.

Beyond that though, if you're going to implement a crypto protocol, don't make
it SRP. It is much harder to do SRP securely than it is to do simple message
digests.

~~~
ig1
Well if you're going to implement a crypto protocol over just using an off-
the-shelf solution you're probably screwed anyway[1]. SRP over SSL is secure
as far as I know, and SRP is certainly better than most of the other home-brew
solutions proposed here.

[1] I've read your blog before and know that I don't need to tell you this,
but the generally community might :-)

------
DaniFong
Digest access authentication is an immediate and halfway decent fix.

At one point I thought this was a big enough problem to write a greasemonkey
script hashing passwords clientside for every website. But it just isn't a big
interest of mine.

~~~
bct
> Digest access authentication is an immediate and halfway decent fix.

It really is a shame that browsers have such a terrible UI for HTTP auth.

~~~
tptacek
Before you consider converting your own web app to HTTP auth instead of login
forms, be aware of the fact that several of the top security firms will
demerit your app for doing it, and that will hurt you selling to companies.

I don't totally agree with this (HTTP digest auth, while silly, is still
better than the crazy Javascript hashing schemes), but the logic is, it is
difficult to "log out" and manage sessions with HTTP auth.

~~~
cperciva
_be aware of the fact that several of the top security firms will demerit your
app for doing it_

Speaking as FreeBSD Security Officer: Several of the top security firms
provide ratings which reflect the quality of their checklists more than the
quality of the security in the systems they're assessing. The FreeBSD security
team recently dealt with a case of "if you don't fix this, people using
FreeBSD will lose marks on PCI audits" -- and our answer was "screw the
auditors, this isn't a security issue and we're not going to send out a bogus
security advisory just to keep some idiotic auditors happy".

~~~
eru
Care to elaborate?

~~~
cperciva
There was a recent "security issue" reported to us whereby an attacker who
could specify a printf format string could cause a buffer overflow. We don't
consider this to be a security issue since if you're allowing an attacker to
specify a printf format string, you've got much bigger problems already --
this "issue" doesn't make things any worse.

~~~
tptacek
Note that there are operating systems that have scrubbed their format string
support, and, as a result, applications with format-string vulnerabilities
have not been exploitable.

I'd elaborate, but I don't know the context of the finding you were dealing
with. If it was, "FreeBSD needs to get rid of the %n token", the auditor was
right, and you were wrong. I'd be surprised if it was that simple, though.

~~~
cperciva
_FreeBSD needs to get rid of the %n token_

It wasn't that simple; but in any event, do you seriously think that FreeBSD
should stop supporting a feature which (a) people have been using for two
decades, and (b) is required by POSIX?

If I was going to make FreeBSD more secure by removing features, I'd start by
removing the boot loader -- which would render the system utterly useless, yet
very secure. If someone wants to shoot themselves in the foot by using a
feature incorrectly, we're not going to stop him -- but we will do our best to
make sure that the gun doesn't explode if someone looks at it oddly. (I think
the X11 people called this the "tools, not policy" approach.)

~~~
tptacek
Yeah that one's pretty easy to answer. Of course you should get rid of obscure
printf(3) format string features, used in fewer places in your codebase than
you have fingers on your right hand, if it means saving your users from a
similar number of vulnerabilities.

Again: unless there are two Colin Percivals working on FreeBSD, you tried to
_remove Hyperthreading from FreeBSD_ to "save" your users from a crypto timing
channel attack that has never been seen in the wild. Reconcile that with
standing fast on format string apocrypha of the sort uncovered by "Month of
XXX Bugs" fuzzers.

Are you sure you're still speaking as FreeBSD Security Officer? I may quote
you on some of this in the future.

~~~
cperciva
_obscure printf(3) format string features, used in fewer places in your
codebase than you have fingers on your right hand_

I just did a quick grep of /usr/src and counted 17 places where %n was used in
a format string -- fairly equally split between printf and scanf. I don't know
what sort of mutant you think I am, but I don't have that many fingers on my
right hand.

And that's not even counting all of the 3rd party code which gets run on
FreeBSD (including the 18000+ programs in the ports tree) which make the
perfectly reasonable assumption that FreeBSD's printf(3) conforms to POSIX
requirements.

 _you tried to remove Hyperthreading from FreeBSD_

No, I didn't. I turned it off by default. There's a big difference.

 _Are you sure you're still speaking as FreeBSD Security Officer? I may quote
you on some of this in the future._

Here's a quote for you: As FreeBSD Security Officer, I do not believe that
POSIX-mandated features should be removed in an attempt to make foot-shooting
harder. The printf and scanf family of functions are dangerous, and should
NEVER be called with a format string provided by a potential attacker or
constructed from data provided by a potential attacker.

~~~
tptacek
After I worked (very briefly with the project, more extensively out of it) on
FreeBSD, I played a minor part in the OpenBSD audit, back when it was mostly
Theo and bitblt. You're the FreeBSD Security Officer, you should know all
about that.

OpenBSD made vast, sweeping changes to their code to minimize and mitigate
security problems. Have you read privsep SSH?

How much third-party code links to your unsafe libc? How could you know? You
think it's more sound to rely on every undereducated third-party developer to
make the right choices about using your libraries, than to simply scrub out
the seventeen (17. really.) places in your own code that use an apocryphal and
dangerous printf feature, so you can eliminate it?

You're way out of step with the rest of your peer group, which appears to have
learned not to trust random developers to use C libraries safely.

I love that argument. "Bad programming? Use good programming. Not our fault."
By that logic, there's no security benefit to writing web apps in Python over
C.

~~~
cperciva
_simply scrub out the seventeen (17. really.) places in your own code that use
an apocryphal and dangerous printf feature, so you can eliminate it?_

Go back and read what I wrote. There are 17 places in the FreeBSD base system
where %n is used in a format string. I have no clue how many times it's used
in code in the FreeBSD ports tree, or in 3rd party code which isn't in the
ports tree -- and I'm not going to go and break lots of perfectly good code
just because someone might shoot themself in the foot.

~~~
tptacek
Yes, you've definitely made it clear that you don't think it's your problem.
Maybe if you just turn "%n" off by default. That's not the same thing as
breaking the code, is it?

Anyways, this is a tangent. It's amusing that you can stick up (in some sense)
for clientside Javascript security, which is at least 0.0001% more secure than
plaintext, but at the same time conduct protected arguments in the mailing
lists about why CPU features should be turned off, lest someone ever figure
out a way to make an attack you helped research become feasible.

------
eru
While you are at it: All that javascript hashing still leaks information. Why
not implement some zeroknowledge protocoll with AJAX?

(You need to send information back and forth because those protocolls are
interactive.)

------
JesseAldridge
I don't speak much bash. What does the script do exactly? Just demonstrates
that the password is transmitted in plain text?

------
snorkel
Oh no. You haxored my HN account. I'm so devastated. I am ruined. Simply
ruined. Come to think of it I really don't care.

------
immad
use clickpass

~~~
huhtenberg
Actually - don't.

<http://img223.imageshack.us/img223/3784/clickpasskf8.png>

<http://codefromthe70s.org/sslblacklist.asp>

If they don't care about the security of their web interface, do you really
want to entrust them with your passwords ?

~~~
tptacek
Ouch. Presumably you reported this.

------
newt0311
Indeed. md5 hash on password + random token is industry standard now. It would
be good to have that here.

~~~
natrius
Maybe I'm not thinking this completely through here, but to do that, wouldn't
you have to store your users' passwords in plaintext to verify the hashes?
That's just replacing one problem with another.

If you use the salt that you're using in your database as the token to
concatenate instead of a random token, an attacker will only be able to use
the data they capture to login on your site as opposed to all the sites the
user has used the same password on. That sounds like it could work, but it
might have security implications I haven't thought through yet.

~~~
pc
No. The server stores salted hashes, and serves the salt and a nonce as part
of the login page. The client then submits hash(nonce + hash(salt + pass)).

This protects against both replay and rainbow attacks.

~~~
apgwoz
I'm a bit confused here. If you were to store salted passwords when you create
an account:

    
    
      salt = randomstring(4)
      hashed_pw = salt + ':' + sha1(salt + password)
      store(hashed_pw, login_name)
    

How do you then verify this? In other words, how do you send the user the salt
and the nonce if you don't know who the user is ahead of time?

~~~
Hexstream
Here's how I understand it:

The salt is generated on the server, it's always the same for a given user
(and possibly all users). You concatenate this with the password in some way.
The utility of this is that if a user's password is mypassword then it will be
hashed as, say, mypasswordsalt so someone with a "rainbow table" of all hashes
and the corresponding cleartext would normally have quickly known that the
hash's cleartext is mypassword but the dictionary will fail to match the hash
since there's no entry for mypasswordsalt. This is how rainbow tables are made
useless should the attacker get access to the passwords in the database.

I never used the nounce technique and can only make guesses so I'll refrain
from trying to explain that part.

~~~
tptacek
This is going to make me sound like _even more of an asshole_ , but I'm going
to say it anyways because it is true: if you have to explain to yourself what
a "salt" is, or you can't spell "nonce", you shouldn't be designing security
systems. That doesn't mean your app needs to be insecure; it just means you
should be using someone else's authentication system to do it.

~~~
Hexstream
You really need to calm the fuck down.

"if you have to explain to yourself what a "salt" is, or you can't spell
"nonce", you shouldn't be designing security systems."

No, I don't have to explain _to myself_ what a salt is, though my "Here's how
I understand it" introduction probably mislead you into thinking that. The
only reason I said "Here's how I understand it" is that initially I wanted to
explain both what a salt is (a notion I certainly understand because I read
about it and implemented it) and what a nonce is (a notion I probably don't
understand because I didn't really read about it and didn't implement it).

I know I still have much to learn but at least I know what I don't know with
respect to nonces, and I find it pretty lame that you're saying I shouldn't
"design security systems" just because I can't spell a word properly _for a
technique I just admitted I "never used and can only make guesses [about]"_

I've been working like crazy for the last 2 years to learn everything about
Common Lisp and making websites and you're saying I should give up everything
just because I still have things to learn?!

You can't judge someone's skills just by looking at a data point like that.
The concepts of closures and macros are now completely automatic and obvious
to me but I wouldn't call someone who never heard of it or has just a basic
understanding of it "someone who should never program". Of course I'd point it
out if they said they had a firm grasp of it while it was obvious that they
didn't.

~~~
tptacek
I'm not sure why I'm meant to care how hard you worked over the last 2 years
to learn Common Lisp.

A _huge_ fraction of the security breaks over the past 15 years --- which cost
us billions and billions of dollars --- are traceable to the mindset that says
that figuring out security is just like figuring out how to scale a database:
"you try and try and try until you get it right". Well, no.

I don't have an authentication system to sell you, but someone else does, and
you should use it before you try to build one yourself.

~~~
tptacek
In other news, I have _totally_ turned in to that fat old guy who bugged me on
Usenet when I was 18 and getting started. I'm off to cry into my beer.

------
socksandsandals
Um, pg? Can we get a fix on this, please?

~~~
fiaz
I don't understand why this guy is getting down modded...I think it's
perfectly reasonable to ask a question without incurring a penalty, regardless
of how much you disagree with it.

~~~
Hexstream
I wouldn't want us to set a precedent such that everyone formulate statements
as questions to avoid the possibility of being modded down?

~~~
fiaz
What about "listening to your users?"

