Elsevier Left Users’ Passwords Exposed Online | Hacker News Reader

Elsevier Left Users’ Passwords Exposed Online

motherboard.vice.com

159 pointsmarkovbot35 comments

Open articleView on HN

Everything at Elsevier is closed, locked up, and proprietary, except for (ironically) your passwords.

Also, if you want an alternative to Mendeley check out my app Polar: https://getpolarized.io/

Passwords aren't monetizable, that's why.

...or are they?

I think you could sell a email+password database quite easily!

I would imagine the statistics of a large user base would significant in the black market. Most commonly used ones etc.

If only they'd make their citation data available in the same way they make passwords available.

(Blatant plug: check out https://i4oc.org)

Throaway

I interviewed at Elsevier for their Director of Information Security. The current Director was going back to Comcast, the entire team was from Comcast.

They were pompous, egotistical, and utterly clueless. They asked the all time dumbest questions I've ever been asked in an interview.

The first interview of the day was with the outgoing Director and his two lieutenants. They spent most of the hour explaining how important it is to make the business happy. When I tried to ask questions about their control framework they changed the subject. They deflected every question I asked. I thought about just leaving after the first interview but I stuck it out for the next 3 1 hour interviews.

It took them 6 months to follow up and tell me that they position was filled by an internal candidate

Add it to the list of reasons to be unhappy with Elsevier. The article makes it sound like passwords are stored in plain text. What a disaster of a company.

I'm mystified when articles like this come out. Even new developers know not to store passwords in plain text. Popular web frameworks like Laravel have password hashing built-in, preventing even bad developers from making this mistake. I cannot even conceive of how a such an insecure system gets built. Can we simply assume that this behaviour is intentional (and, perhaps, even devious)? Or is there some logical explanation for such poor design?

Sorry but this type of issue often occur because developers has your mindset. I've had so many auditors and security reviewers ask me "how do you hash your password?" but no one has asked me if I log http request, session tokens, outbound emails or any other thing where sensitive data can be transmitted. Nor have they asked me what the actual process for rotating credentials when employees leave, more than "Do you do it?"

I see, thank you, I wrongly assumed they were just looking at the database.

I recently used a website to sign up for online Health insurance access and noticed they console.log your password back to you in clear text whenever you hit submit. Now maybe 99% of the population won't know what to do with that, but despite the fact that someone's debug log for passwords made it into production which tells me all I need to know about their standards, what if they are using something like rollbar, fullstory, or god knows what else that captures log output? What about malicious browser extensions? I called their technical support helpline, and I got the typical joke of a "oh that's not my department" response. Imagine what they are doing with our healthcare data.

The password is stored in plaintext since they could read it via Kibana but I'm guessing you mean that their identity system which they use to store users store credentials in plain text.

To that I say meh: Could just as well be that they decided to log all Http request to troubleshoot some issue without realizing the security implications. The article even says it was a rolling list of passwords which further indicates loggimg since you probably don't store trace logs forever.

Kibana's a monitoring system, so the article makes it sound like the passwords were ingested into logs on their way to presumably sit hashed at rest for the systems that they were intended for.

Which means there are really three red flags: internal tools deployed to the public internet, internal tools without any user access control, and allowing passwords to hit the logging infrastructure.

>allowing passwords to hit the logging infrastructure.

This is the most ridiculous of the three in my opinion. When logging to elasticsearch you programmatically have to say what data to put in the document before its indexed (and thus viewable via Kibana). This means that the developer actually put the password as a parameter in the document object.

Not necessarily, it could just be total and indiscriminate logging of HTTP requests.

I know its petty, but any reason to pour the hate onto Elsevier makes me a happy. I do my utmost to never have to rely on publications only available through them as a resource and it has definitely shaped the focus of my research (if there is any barrier to getting a publication, I'm far less likely to use it or rely on it).

Almost all Elsevier development and infrastructure work is farmed out to companies in India, so they're probably not directly responsible for the cock-up, but their general attitude towards development, and their customers, probably plays a role.

If you cut corners in management then you are directly responsible for the cock-up, period.

This is a modern issue with the way laws look at subcontracting work as a tool that allows companies to isolate themselves from liability which needs to change, if your company (Elsevier) sub-contracts it should be your company on the line - with an allowance to pursue legal action against the sub-contractors that will be examined in depth during that proceeding.

These sorts of situations have too often resolved in "Well, we can't tell if it was the parent or sub-contractor that was responsible, I guess we need to let them both off." instead hit the parent with the full force of the law as a negligent reseller and if they were unaware of these situations they can recoup their costs by pursuing the subcontractor on their own dime.

If you decision leads to a failure like this, you are directly responsible. Responsibility for business processes are not outsourced with the IT service. When a company that has huge guaranteed profits (by nature of the academic publishing "market"-structure), and no IT skills to verify network service providers, you are responsible for not having any oversight to the processes of your company.

They publish an interesting book which they could read for fun and profit.

[https://www.elsevier.com/books/data-breach-preparation-and-r...

^v^

For the record: https://twitter.com/michaelhoffman/status/102937490375625113...

So, right now, most university Elsevier customers use "IP address authentication" to get through the paywall. And have a byzantine "proxy" system for affiliates not on campus to still get access -- appearing to a vendor like Elsevier like they are coming from a recognized university IP.

There are a whole bunch of problems with this system, that you can imagine.

But ONE is that it makes it a lot easier for things like sci-hub to automatically batch ingest articles with credentials from someone affiliated with a university (Elsevier customer), but without Elsevier actually knowing _what_ account was used. Elsevier's access logs end up giving them nothing but at best a university-affiliated IP address, with easy no way to know (because of proxy use) even what downloads were associated with distinct "users".

For THAT reason, academic content vendors have been trying to move to a system where there are individual identity accounts, so they can track who is downloading what (and try to block or worse accounts being used to sci-hub). You know, for "security".

I think this incident shows that trusting Elsevier with any kind of identity accounts is not in fact "security".

There is no part of this (except the possibility of shutting it down) that I don't love. Elsevier is just such a wonderful company to detest, they're like the final boss of free-market driven anti-intellectualism.

And all the higher ups leave the company out of disgust for their destructive impact in the world, when? About now? How about now? Is now a good time?

Leave the company because some engineer wrote log.Printf("%v", req) at the top of some handler function?

what were other developers (code reviews), testers and security officers doing? Stop blaming it all on one guy.

Oh, I didn't intend to do that. I just said that it seems irrational to me for the execs to leave their company because the engineering practices are not perfect. Fix the practices, keep on going.

Not that these days exposing hashed passwords is always that much better... but why are they even keeping plaintext passwords to accidentally expose?

As these appeared to originate from a log file it's very possibly plaintext passwords are not being stored anywhere (except the leak spot which is bad) but instead are being logged out of memory where they (generally) need to exist in plaintext for a bit for verification.

I don't think this is a mis-configured server - this is expected behavior for elastic search, as the OSS version has no security baked in to it - any security at all is an enterprise feature. This is irresponsible from elastic.co.

No. Plain text user passwords should never, in any circumstances, be entered into a search engine (which is what elasticsearch is). There is simply no possible excuse for this. There is no way this is elastic.co's fault, this is entirely on Elsevier.

I agree that the passwords should not be logged in any circumstances (if I had to guess, I might suspect that disk log files were ingested straight to elasticsearch), but I don't think this invalidates my argument that elasticsearch out of the box is not suitable for any data you intend to not share with the world.

There is a separate thread about security best practice learning that touches on the question of if the rote security knowledge we pass on is making it more likely that someone logs a password. I think a discussion around logging habits is much more relevant and while elasticsearch may have _also_ been misconfigured, pumping passwords into an internally viewable log file is a bad idea even if that file is well secured.

You're right, but it is easy to do by accident. Log a stacktrace that includes some function arguments, and one of them is the password...

Now, it's possible to avoid this, but it's hard to avoid this completely in a complicated system.

Elsevier could also buy a subscription instead of using it for free. It's not like they don't have the money.

Reply on news.ycombinator.com