
Elsevier Left Users’ Passwords Exposed Online - markovbot
https://motherboard.vice.com/en_us/article/vbw8b9/elsevier-user-passwords-exposed-online
======
burtonator
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/](https://getpolarized.io/)

~~~
phoe-krk
Passwords aren't monetizable, that's why.

...or are they?

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

------
eledumb
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

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

~~~
tealeg
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.

~~~
munk-a
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.

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

[[https://www.elsevier.com/books/data-breach-preparation-
and-r...](https://www.elsevier.com/books/data-breach-preparation-and-
response/fowler/978-0-12-803451-4\]\(https://www.elsevier.com/books/data-
breach-preparation-and-response/fowler/978-0-12-803451-4\))

 _^v^_

------
heinrichf
For the record:
[https://twitter.com/michaelhoffman/status/102937490375625113...](https://twitter.com/michaelhoffman/status/1029374903756251136)

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

~~~
munk-a
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.

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

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

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

~~~
jrockway
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.

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

~~~
munk-a
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.

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

~~~
jfindley
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.

~~~
j_anstice
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.

~~~
munk-a
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.

