5 ms·

Tumblr sends passwords in the clear.

21 points by paulitex 17y ago

wgj 17y ago
Twitter's form looks very Rails'y. I know they used to be on the Rails framework, but are they still?
- teej 17y ago
  The use Rails for the user-facing web parts of the site. They use Scala on the backend to process asynchronous tasks.
  - gry 17y ago
    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.
- aditya 17y ago
  This post is about Tumblr, which is PHP I think
- simonw 17y ago
  Yes. They still use Rails (and Ruby) for the majority of their service. They use Scala for the highly concurrent / heavy lifting stuff.
natrius 17y ago
Welcome to the internet.
jrockway 17y ago
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....)
- aditya 17y ago
  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?
  - jrockway 17y ago
    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.
- callmeed 17y ago
  "often from people who have written their web applications in Ruby" Can you elaborate? What is Ruby's shortcoming in this area?
  - jrockway 17y ago
    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.)
rmorrison 17y ago
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.
chaosmachine 17y ago
So does HN.
- ash 17y ago
  Yes. But you can log in securely via clickpass.com.
mtarnovan 17y ago
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 17y ago
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?
deleted 17y ago
[deleted]
abyssknight 17y ago
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.

21 points by paulitex 17y ago

wgj 17y ago

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

teej 17y ago
The use Rails for the user-facing web parts of the site. They use Scala on the backend to process asynchronous tasks.
- gry 17y ago
  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.
aditya 17y ago
This post is about Tumblr, which is PHP I think
simonw 17y ago
Yes. They still use Rails (and Ruby) for the majority of their service. They use Scala for the highly concurrent / heavy lifting stuff.

natrius 17y ago

Welcome to the internet.

jrockway 17y ago

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

aditya 17y ago
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?
- jrockway 17y ago
  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.
callmeed 17y ago
"often from people who have written their web applications in Ruby" Can you elaborate? What is Ruby's shortcoming in this area?
- jrockway 17y ago
  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.)

rmorrison 17y ago

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.

chaosmachine 17y ago

So does HN.

ash 17y ago
Yes. But you can log in securely via clickpass.com.

mtarnovan 17y ago

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 17y ago

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?

deleted 17y ago

[deleted]

abyssknight 17y ago

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.