Tumblr sends passwords in the clear. | Hacker News Reader

Tumblr sends passwords in the clear.

paulitex.tumblr.com

21 pointspaulitex25 comments

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....)

I agree except for the everyone should use https bit.

It's not a question of CPU time but usability, what if you want subdomains (then a wildcard SSL cert, then the cert expires and everyone is unhappy for a few days, and those annoying warnings about security exceptions that are bound to happen) and all that hassle for what? Just so that someone doesn't steal your oh so important blog password? I dunno, seems overkill, no?

Unfortunately, most people use the same password for their blog that they use for their online bank.

Yeah, they're being dumb, but they're going to blame you when their password gets sniffed and their bank account is drained.

"often from people who have written their web applications in Ruby"

Can you elaborate? What is Ruby's shortcoming in this area?

If performance is so important that you can't encrypt your login form, then you probably shouldn't be using a language that runs 50x slower than C. (Just to be clear; all my web applications are this slow too. But I enable SSL.)

As always, it depends what your app is doing. I've got a realtime event hanling solution where the performance dips close to 50% when you turn SSL on simply because of the handshake times.

So we shouldn't use python, perl, or php either? The last time I checked, all of these languages are at least 30x slower than C.

"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?

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]".

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.

Exactly; thanks for clarifying. :)

I think most people that use Ruby put something in front of their servers (like nginx or Apache) that can handle SSL and serving of static files...

The expensive bit of SSL is not the symmetric crypto once established, it's the public key crypto when setting up the SSL session.

However, 600 quid buys you a PCI-E accelerator card which offloads those calculations from the CPU, so you don't even have to get a fancy load balancer.

Welcome to the internet.

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.

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.

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.

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?

So does HN.

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

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

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

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.

This post is about Tumblr, which is PHP I think

Yes. They still use Rails (and Ruby) for the majority of their service. They use Scala for the highly concurrent / heavy lifting stuff.

Reply on news.ycombinator.com