
Robinhood Stored Passwords in Plaintext - bdibs
Just received this email from Robinhood (https:&#x2F;&#x2F;robinhood.com&#x2F;):<p>&quot;When you set a password for your Robinhood account, we use an industry-standard process that prevents anyone at our company from reading it. On Monday night, we discovered that some user credentials were stored in a readable format within our internal systems. We wanted to let you know that your Robinhood password may have been included.<p>We resolved this issue, and after thorough review, found no evidence that this information was accessed by anyone outside of our response team. Out of an abundance of caution, we still recommend that you change your Robinhood password.<p>We take matters like this seriously. Earning and maintaining your trust is our top priority, and we’re committed to protecting your information. Let us know if you have any questions–we’re here to help.<p>Sincerely,<p>The Robinhood Team&quot;<p>If you&#x27;ve used Robinhood in the past, it&#x27;s a good idea to check your emails!
======
bdcravens
This doesn't mean they were stored in a database. "a readable format within
our internal systems" could be log files if they didn't scrub passwords when
logging requests.

~~~
mnem
I'm not an authentication system programmer, so this may be a silly question,
but why do clients still send passwords to a server? Doesn't it make more
sense to hash the username and password together with some sort of nonce/salt
that's sent to the server for validation?

~~~
fortenforge
If you hash the password on the client, then the hash essentially becomes the
new password and you haven't solved anything. What you're looking for is a
password authenticated key agreement in which one party authenticates to
another without an eavesdropper learning any secret [1]. For whatever reason,
no major websites use PAKEs today.

[1] [https://blog.cryptographyengineering.com/2018/10/19/lets-
tal...](https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-
pake/)

~~~
gdhbcc
But you have. It means even if you refuse your passwords elsewhere, only the
website that was compromised is compromised.

~~~
allset_
You can (and should) store the salt server-side. Moving the hashing to the
client does not solve anything.

------
jchw
This is yet another reminder: Do Not Reuse Passwords. There’s good password
management even for mobile operating systems these days. I’m using Bitwarden
on iOS, and it integrates well both with native apps and webpages.

Also, use two factor authentication, of course. If you are going the U2F
route, I highly recommend having a permanent key for each computer and a
bluetooth+NFC key for on-the-go. It’s a worthwhile investment.

My biggest problem today is that it is tedious to generate and save new
passwords on mobile, which is increasingly where I do so... but security
always comes with some costs, I suppose.

~~~
mgfist
I haven't looked into password managers for a while. What do you do if you
need to login on a random machine?

~~~
driverdan
Don't. You shouldn't be putting your passwords into a random machine, it may
be compromised.

20 years ago when I was in high school a friend of mine bought a hardware key
logger. It went inline between the keyboard and computer. He would leave it on
library computers to get the firewall password and to mess with other
students. You never know when a machine is compromised.

~~~
probably_wrong
> Don't. You shouldn't be putting your passwords into a random machine, it may
> be compromised.

Sure, you _shouldn 't_, but sometimes you have no other choice. The simplest
case that comes to mind are the tourists who need to print boarding passes
using the self-service computers in their hotel (or, even worse, at some
printing shop down the street).

I would definitely change my password afterwards, though.

~~~
iamnotacrook
Just upload stuff you might need from an unsafe area from a private gitlab
repo. Encrypt it if you like. Change the gitlab password when you're back (or
just delete the account if you're paranoid).

------
jacquesm
Similar things have happened to Facebook _and_ Google recently, the two
companies that people keep repeating have the best security teams in the
world. As long as humans are involved in programming - something that will
likely be the case for the foreseeable future - these things will happen. But
props to them for owning up about it and promptly mailing users pro-actively.

~~~
hunter2_
Genuine question: how would the non-involvement of humans make such issues
unlikely? Doesn't the machine learning process involve trying (which, in the
case of programming, would probably mean deploying to some users) what is
quite certainly a combination of successful and unsuccessful things, to see
what sticks?

~~~
jacquesm
I would assume, perhaps in error, that when such a system is created that it
could be fed enough rules about what not to do that such oversights would not
happen. The typical error is 'programmer debugging something will serialize a
struct to a log file without realizing that there are critical fields in the
struct'.

------
mehrdadn
Not surprised, considering their security practices... see
[https://news.ycombinator.com/item?id=15679099](https://news.ycombinator.com/item?id=15679099)

------
codezero
If you ever run a service, make sure you're not storing nginx logs with the
contents of POST requests. A few years later you'll realize you "stored
passwords in plaintext"

I assume this is what happened here, but maybe Robinhood will elaborate at
some point.

------
theshadowmonkey
Isnt it so convenient that they announce this after they close their funding
round.

~~~
wesammikhail
My thoughts exactly. How the hell do financial applications not take security
more seriously? I just don´t understand. It isn´t that hard to make security a
top priority. It isn´t even that expensive in comparison to the price they pay
for issues like these, yet it seems that time after time, fast growth and
dumping shares onto new VCs or public market investors takes priority over all
else...

~~~
zrm
> How the hell do financial applications not take security more seriously?

This is what taking security more seriously looks like.

The lazy company doesn't even bother to look for problems like this, never
finds them, and then an attacker eventually gains access to the plaintext
passwords and compromises their customers.

The shortsighted company finds the problem and fixes it silently, even though
they should really notify users to change their passwords to mitigate the
possibility that the plaintext passwords were already compromised.

The company that takes security more seriously does own up to it despite the
PR hit.

~~~
Shatnerz
Yeah, at least they notified customers. I found a similar issue issue at a
financial services company (money lending) where I previously worked as a
junior dev. A dev accidentally added a log statement to debug something that
made it to production. To make matters worse, the logs were also sent off to
3rd party log aggregator that we used and all devs had access to.

The company refused to do anything. No emails sent, not even a forced password
reset. The dev who made the mistake responded with "This is not a real
concern. I am disappointed we spent so much time working on this." I brought
it up with the CTO who essentially did nothing. Then I brought it up with CEO
who came to our standup where the responsible dev than said something along
the lines of "we don't serve any heads of state, so it doesn't really matter."
CEO did nothing. I emailed the general counsel who told me no one else brought
it up with him.

I think I gave notice 2 weeks later. The general counsel apparently left
within a year (not sure if related).

------
all_blue_chucks
The fact that they prompt you for your literal bank password when funding your
account says everything you need to know about how they look at security.

~~~
asdff
That's true of nearly every app I've used that links to your bank account
(mint and venmo off the top of my head). Super archaic and obtuse and I solely
blame the banks for not building a better method.

~~~
all_blue_chucks
ACH transfers do NOT require you to give your password to anyone, and they
have been around forever.

Never give your bank password to anyone other than your bank.

~~~
astura
But ACH transfers require you to give the information needed to print out
checks against your bank account (routing number and account number).

------
dumbeldore
The title is so misleading....

------
papito
Man, I would spend time masking sensitive data in a shop with no traffic, but
someone like Robinhood or Facebook can get away with it. They don't sweat the
small stuff, do they?

------
pgl
> "we ... recommend that you change your Robinhood password"

This should really be a forced reset. Not finding evidence that it was
accessed isn't proof that it wasn't.

------
ecnahc515
So they probably have a request logger that logs request headers, and they
accidently were logging credentials from those headers is probably what
happened. This has hit basically every large web service at some point. Crazy
this never came up in an earlier internal security audit, but not surprising
it occurred in the first place.

~~~
huntermeyer
Filtering those parameters should be a fundamental practice.

------
snek
I got an email this morning that my hulu had been logged into... my hulu and
my robinhood did in fact share a password. I have no evidence that these are
connected, but better safe than sorry. (And I do use 1password now, I just
didn't back when I used robinhood and hulu).

~~~
Scaevolus
Have you checked HaveIBeenPwned? for your email? If you shared a password
between Hulu and Robinhood in your pre-lastpass days, you probably used it on
yet another site that was hacked.

~~~
beatgammit
The problem is that it says I've been pwned, but it's completely unhelpful
because it doesn't say which service(s) it was. I use different passwords for
most sites (randomly generated via password manager), though a few unimportant
ones share a common password.

I use Bitwarden, which has a way of checking password dumps, but only for
individual passwords. I have over a hundred entries, so checking that
frequently is quite time consuming.

I've decided to just switch my email on as many sites as possible using a few
aliases to make put them into buckets, but there has to be an easier way...

~~~
ebg13
> _The problem is that it says I 've been pwned, but it's completely unhelpful
> because it doesn't say which service(s) it was_

This is the most frustrating thing about hibp. I have hundreds of passwords on
hundreds of services. "we found your email in a dump" doesn't help me if I
don't know which server you found it for.

------
paulie_a
"found no evidence that this information was accessed by anyone outside of our
response team. Out of an abundance of caution, we still recommend that you
change your Robinhood password."

That is complete bullshiting pr spin and I'm greatly concerned about my
account.

Gee wiz I wonder if anyone on the response team could have done something. Or
a dev with nefarious purposes like guy that rigged the lottery multiple times.

------
shawnjanas
Probably server logs / http request handler console log

------
huxflux
"take matters like this seriously", not really.

------
hartator
I think it was some kind of logs. Probably request logs.

------
2_listerine_pls
It's hard to believe a financial services company would store passwords in
plain text out of stupidity. Could this be a legal strategy to avoid
responsibility in some scenario?

------
blattinum
thanks for the heads up. I got the same email earlier.

------
foobiekr
Plaintext bank account credentials. Wow.

------
gilbertmpanga12
Looks like storing in text is now a trend will do this in rest of my projects.

------
Havoc
I smell weapons grade bullshit.

>On Monday night, we discovered

Because one casually does security audits on a Monday night and then releases
a "nothing has come to our attention" statement?

The one is proactive (on a monday night?) the other speaks of a response to an
external actor. Which is it?

The mere fact that a release like this happened suggests some sort of
legal/SEC/accounting requirement was triggered. i.e. Something happened.

~~~
luhn
I think it's plausible. As other commenters have noted, the leak was most
likely in application logs. So on Monday night, SRE gets paged about random
issue, pulls up the logs and starts debugging, ends up stumbling across a
user's password.

