

Tumblr sends passwords in the clear. - paulitex
http://paulitex.tumblr.com/post/335340309/tumblr-sends-passwords-in-the-clear

======
jrockway
Uh yeah, welcome to http. If you read the warning that pops up when you submit
a form over http, it says exactly what the author "discovered". If he disabled
it without reading it, that's his fault, not Tumblr's.

But of course, I think everyone should use https. I hear the excuse, "it uses
too much CPU time", but this is often from people who have written their web
applications in _Ruby_. Not using https is a very premature optimization, in
that case. (Of course, crypto is not that slow on modern computers. I can do
about 60Mb/s of AES on one core of my 8-way consumer-grade machine. If you are
getting a constant 480Mb/s of login form submissions, you can probably afford
one of those load-balancers that does SSL....)

~~~
look_lookatme
"I hear the excuse, "it uses too much CPU time", but this is often from people
who have written their web applications in Ruby"

I'm curious about this, are these excuses you've heard based on configurations
where a proxy server processes the initial https req and then sends the
backend request encrypted, too? This is where Ruby is handling an encrypted
request?

Or are you saying there are people who have excused https from their setup
because their frontend web server is written in Ruby?

~~~
jon_dahl
The poster's point isn't really about Ruby. Ruby works just fine with HTTPS,
thank you very much. It's not like Ruby handles the HTTPS encryption. I think
his point is more "I hear the excuse 'it uses too much CPU time', but this is
often from people who [should be looking elsewhere if they have performance
problems]".

~~~
look_lookatme
Ah I see. I was confused.

It didn't occur to me that he or she uses Ruby (in italics) as a catch all for
slow application performance, not slow encryption performance.

That said, do people really eschew https because they are that CPU strapped?
Bizarre.

------
natrius
Welcome to the internet.

------
abyssknight
What's the big deal with sending passwords in the clear? Your network security
is not an application's problem. I understand the big concern with the Chinese
firewall, but really, obfuscating credentials to non-essential services is
just not the biggest problem with it.

If an attacker is already on your network, i.e. sniffing your traffic, you
have far bigger issues than passwords in the clear. They don't need your
password. They can already read the data just fine without logging in.

Everyone is screaming HTTPS, but to be honest, that does _not_ make you any
safer these days. Check out SSLStrip and null prefix attacks on SSL
certificates. Now think about what would happen if the government did that.
Now then, is SSL still a solution to this problem? No.

------
rmorrison
Of course the passwords should be encrypted, but when they're not it's nice to
have a different password on each site.

If you haven't already, take a look at 1password, which makes doing this
pretty transparent.

------
mtarnovan
Well, there are other workarounds for this besides using ssl. I wonder why I
don't see them being used. For example one could encrypt the form with
javascript using a public key and submit that. There seem to be enough
javascript crpyto libs out there. Of course this would have the minus of
requiring javascript on the client side, but at least you don't need to buy a
valid https certificate.

------
timcash
Wait a second... you cannot "sniff" other peoples connections on the same
wireless unless you also use some kind of ARP poisoning... something like
ettercap will do the trick. Did I misunderstand what you are trying to say?

------
chaosmachine
So does HN.

~~~
ash
Yes. But you can log in securely via clickpass.com.

------
wgj
Twitter's form looks very Rails'y. I know they used to be on the Rails
framework, but are they still?

~~~
teej
The use Rails for the user-facing web parts of the site. They use Scala on the
backend to process asynchronous tasks.

~~~
gry
Neither have bearing on passing passwords in the clear.

I've made mistakes passing credentials in the clear. I've made mistakes
storing them in the clear. I've made mistakes passing them as md5 hashes. I've
made mistakes storing them as md5 hashes. I've made mistakes passing them
SSL'd and storing them as md5 hashes with a nonce. I've will make mistakes
using bcrypt.

I mentor developers. It makes me nervous is not being able to go from A to F
(in a good way). It also makes me nervous there are so many knowledge gaps
along the way.

