Hackerrank.com sends passwords in the clear (gist.github.com)

29 points by theonewolf ↗ HN
So I saw the recently launcher hackerrank.com and noticed on sign up that the page wasn't HTTPS. I was a little bit worried and checked a packet dump.

Sure enough, passwords are sent plaintext to their servers (I hope not stored plaintext, although that is harder to confirm).

If you want to try them out, use a throwaway password!

41 comments

[ 3.4 ms ] story [ 82.8 ms ] thread
Even more fun are the sites which don't let you change your password (!!!).
HN doesn't even force https for login. (Heh, based on the direction of the whole thread, I should clarify) I'm not defending using non-HTTPS logins, just pointing out that lots of sites haven't decided to force HTTPS.
It depends on your login process. For signing up to a site, you generally will want/need HTTPS.

For login, what is transported on the wire can be a hash or some form of the password which is no longer plaintext.

Thus, _logins_, may not need HTTPS protection.

It depends on implementation.

As a quick path for HackerRank.com to fix, I proposed HTTPS which is already implemented, rather than modifying web app logic.

No, encrypting client-side is still vulnerable to a MITM attack. The MITM simply removes the code to encrypt the password from the website.
If you transmit the hash, it's either going to be unsalted, or the salt will have been sent ahead of time, leaving it open to being brute forced. Further, it's still a huge MITM attack because if you can login to whatever.com with theonewolf/HASHOFYOURPASSWORD then I can sniff that... and login as theonewolf/HASHOFYOURPASSWORD too.
We'll add https in a day. Sorry.
Hey, it's no big deal. I fully understand product launches :-)

I just wanted a warning out there for people so they don't use real passwords.

I am still of the opinion that you should put a red warning on the web site, or disable signups/logins.

sorry dude but what? You do know more than half of the internet doesn't use https for login? Hackernews (as pointed out above) doesn't. Are you seriously suggesting a company put "we're not secure!" on their login page because they don't use https?
Yes. Bad practices are bad practices. I don't think they should be maintained.

Just a simple warning to users that other people on the Internet could see their password might help in identity theft.

People would at least be cognizant that others can see their password.

I don't know how these guys stay afloat and continue to get companies to use them. I don't like any of the challenges on there, and I don't see a need to `centralize` the whole process.

EDIT: Not to mention how poorly this site is set up already. The only "challenge" I see on there right now is to type candies <N> to start playing a game where you and a CPU take turns taking between 1-5 candies (you go first). The person who takes the last piece of candy wins.

So, type candies 5. Then choose to take 5 candies. You win.

This is a completely new product. It's not linked to jobs/companies.
I agree, the top comment confused me...

It's new and could be pretty nice especially for younger people.

It's made by the InterviewStreet people.
Seems a bit unreasonable, the site is not even available yet. Looks like they protect vs CSRF and salt + hash passwords in the DB and have HTTPS on the way. Why keep nagging? Client side hashing in login pages is very rare, banks like wells fargo dont even do it.
(comment deleted)
The problem is that people are signing up and may be using passwords which they do use on a bank website etc.

Man-in-the-middle ARP attacks or even just sniffing the wire will reveal your password to attached machines on the path from you to HackerRank.com.

Right away they said they are adding HTTPS yet you continue pounding and then broadcast it to the world in HN, seems unreasonable.

"just sniffing the wire" will only work if your connected to the same dumb hub, modern switches don't broadcast packets on the subnet. ARP poisoning could force their browser to forward the traffic to you and you can forward it on to the gateway. Even that would require you to be on the same subnet. Once they have HTTPS they are protecting you just as much as any other service. If they refused to support HTTPS I would see this being a problem - but they are not.

The problem is that people are signing up with real passwords today without being warned that they _could_ be being compromised.

Yes, _tomorrow_ it might be fixed. But today no one knows there is an issue and their password has been exposed.

Wi-Fi is common enough that Apple has been dropping Ethernet adapters from products.

Sounds like the perfect 'dumb hub' to me!

Users should be trained not to do that. Sure, it's good for the site to use SSL, but training users to look for a lock logo will only protect them from MITM & wire sniffing, not untrustworthy sites.
I wasn't advocating for blindly using SSL, only to fix things short-term.

Long-term I'd hope for better handling of passwords.

This isn't a huge deal to me, I just want a warning out there for people to use throwaway passwords.

Better handling how exactly? Either you send a login token over the wire in plain text, or you send it over HTTPS. It makes no difference if you hash client side or not, as it's still a login token that can be sniffed and reused.

Even sniffing is only really likely to be a problem if you're on a public wifi network.

It seems like you're blowing this out of all proportion. It was only relatively recently that Facebook starting forcing HTTPS for authentication, and many many sites (inc. HN) still don't.

I think the point is that if the password is one that's used elsewhere, if it's client-side encrypted, at least it can't be captured for use on another site by an eavesdropper.

It does nothing against an attacker who can get in the middle of the transmission though.

I'm not talking about blind use of SSL, I'm saying users should always be cautious with their password. The burden of protecting your bank password falls on you, if you're using it on a third-party site, SSL or not, you're at risk.
I think we all know this is unfeasible.

I don't think we can expect the general public to even be _acquainted_ with acronyms like SSL; or an understanding of why passwords need to be completely different.

And this is a startup that hopes to train people in hacking...I was just expecting a bit more on the security-side I suppose.

What we can hope to do is place warnings that let them know when things are safer and when not.

I guess I haven't followed many launches recently (to see if people are starting things more secure or not).

I checked out Hacker Rank because I _really_ like their idea. And hope to let some younger friends (brother etc.) to use the site.

The 8th most dangerous software error (2011 CWE/SANS Top 25 Most Dangerous Software Errors) is not encrypting sensitive data.

If they ever want a paid-for version (maybe for future lessons), this will become an issue.

I'd just rather bake it in from the beginning.

I'm not sure what you mean by not available yet.

It is being publicly advertised and accepting signups+logins.

And you already told them it's a bad idea. So what are you trying to achieve by posting this on HN? Public humiliation?
I'm trying to prevent other people from using passwords that matter because there is no warning at all.
I beat the candies challenge with 601 candies and it's still telling me to beat it with more!

How do we input a program to beat the challenges?

challenge <any-integer>
What I mean is I can beat it with any integer (except those divisible by [REDACTED]), as long as I have the patience and typing accuracy to follow my algorithm for that many turns. Beating it on 601 candies took 2 tries purely due to a mistype on the 70th or 80th iteration.

But the site must let us type our solution algorithm in to a program of some sort and let the computer handle the grunt work, right?

There are 3 guys who've written an automated script. Can you figure? ;)
Every step you take to improve security has costs associated with it. At some point, you just have to say "this is secure enough for all reasonable purposes," because to do otherwise is to risk getting bogged down.

Hashing + salting passwords in storage and using HTTPS is better than a shocking number of large-scale sites. I fail to see a problem.

The problem is that HTTPS isn't in place today.

And people are signing up with passwords being sent plaintext.

I just wanted a warning out there---if you want to use the site today, please don't use a password that matters to you.

If you don't have time to do it right yourself, why not have someone else do it for you. For ex: https://www.dailycred.com

This is my startup. Getting SSL working is a pain. Building proper account UI is a pain. We think startups should stop burning time reinventing the wheel when they're trying to launch.

(comment deleted)
This appears to be a good response.

On the other hand, my local government had a website that let you book and pay for driving tests online, and, presumably due to a configuration error, it was taking credit card numbers over plain HTTP.

I contacted them to let them know that they were accepting credit card numbers over an unencrypted connection, and they just sent me an email saying "Thanks for your inquiry. I have been assured by our IT team that the site is secure." I sent a few more emails trying to prove to them that it wasn't secure, but then they stopped replying.

Eventually it got fixed, but I've just checked again and it's now insecure -- again.

Yes i know.

I think the excuses like "many sites dont do this" or "its up to the users to secure passwords" are just that---excuses for poor security practices.

Hashing on the client-side wouldn't make a difference if a MITM already has control of the SSL connection. They could just spoof the login form, swap out HackerRank's hashing code, and take your password anyway.

If you don't trust the connection don't trust any part of it. Especially not the code your browser is executing.

The problem is that it is a site for Hackers, so they have to understand their target market is going to be way more critical than the average user. Welcome to developer marketing