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