Today, Nature published a news feature by Cat Ferguson, Adam Marcus and Ivan Oransky (Retraction Watch) in which I am quoted about some problems with Editorial Manager (EM). This post provides the background to what I say there. Disclaimer: I am not a security expert, though the basic problems should be obvious to anyone caring about security and privacy on the web.
Editorial Manager (EM), the submission and reviewing software used by thousands of academic journals, routinely throws around passwords in plaintext. If you publish with any of the journals using EM, you’ll get emails with your password in plain text, even if you didn’t ask for it. Some configurations of EM even display the password in plain view on the user account page. This means that Editorial Manager does not safely encrypt passwords, which presents a massive security risk. Aries Systems, the firm behind Editorial Manager, defends itself by saying that (1) journal editors want these options and (2) they don’t collect financial information anyway. Those replies skirt the real issue: Editorial Manager, trusted by millions of academic authors and reviewers, fails to implement some of the most basic rules for the secure and responsible handling of passwords and user accounts.
Every academic will run into the Editorial Manager system sooner or later. This is a piece of web-based software that helps the editors of academic journals to manage the submission and review procedure. Literally thousands of journals across all disciplines use it, from well-known interdisciplinary ones like PLOS ONE to niche journals like Policy and Society and Frontiers in Neuroendocrinology, to pick some random examples.
EM requires authors, reviewers and editors to register an account. With such an account, users can submit and review manuscripts. The registration procedure asks for the usual username / email / password combination — nothing very special so far. Until you start using the system a bit more and you discover that it handles your password in, shall we say, a very casual way.
Let’s just take PLOS ONE as an example (though note that any other journal using EM is vulnerable in the same ways). Say you submit a paper, or get a request to review one. You’ll get an email notification with your password thrown in for good measure. In plaintext. You didn’t ask for it. In fact even if you did, it shouldn’t be able to give it to you — at most it should offer you to set or reset it. Most of us haven’t seen plaintext password since the early 2000s; in the last decade, better and safer methods have been introduced everywhere, except at Editorial Manager.
Editorial Manager for PLoS ONE sends you your password in plain text, even if you don’t ask for it
Packet sniffing and password reuse
I shouldn’t really have to explain why this is seriously problematic in multiple ways. Indeed why this is so is written all over the internet. Let me just quickly summarise. The fact that some system sends you your password by email means, first of all, that your password could be intercepted by any old packet sniffer. It also means, obviously, that your password can be retrieved by anyone who manages to get access to your email — either by looking over your shoulder, by rummaging in your inbox while you’re away from your computer, or by more sophisticated means.
But even worse, the fact that the system can send out password like that also must mean that the password is stored in plaintext form, or using easily reversible encryption (which, experts say, comes down to the same). As plaintextoffenders puts it, the password is there, waiting for someone to come and take it. And not only your password is there. It’s the passwords of the millions of users of the thousands of academic journals using this centrally hosted service. That, coupled with the knowledge that about 60% of users reuse passwords across different web services, means a security risk of massive proportions. Check out this XKCD comic for the basics on password reuse.
Not only will EM send you your password in plaintext. It also doesn’t shy away from displaying plaintext passwords on profile pages, offering further proof of the lack of encryption (or the use of reversible encryption, which in terms of security risks comes down to the same). Thousands of academic journals crucially depend on this same system, making their hundreds of thousands of peer reviewers and authors sign up for it. You would think that with “periodic third party security and infrastructure audits” (according to Aries’ hosting checklist), Aries Systems would at least have ensured that the most basic lessons in user account security are taken care of. Apparently not.
Aries Systems: ‘It’s optional, so don’t worry’
While preparing a report on this matter in May 2013, I communicated my findings to the Editorial Manager team, because I thought it would be reasonable to give them the chance to get their act together and respond to the issue. A first email went unanswered. A reminder email then led to an email exchange with Jennifer Fleet, Director of Client Services at Aries Systems, the company behind EM. Here are the most crucial excerpts from what she wrote to me (she gracefully gave me permission to cite this):
Our software (Editorial Manager) has a variety of configuration options that are made available to our publishing customers. The inclusion of credentials in emails is an optional configuration choice. The configuration option to include log-in credentials in emails is desired by some publishers because of the high convenience factor it provides to end users who infrequently access the system. However, inclusion of credentials in emails can also be entirely suppressed and many publishers in fact do not include credentials in emails. We have a wide variety of publishing customers and each is empowered by the administrative capabilities in the system to make their own choices concerning this type of policy.
While honest, this reply show that Aries Systems doesn’t realise how important it is to handle user information in a responsible way. The defense is basically: our clients want it, so we do it. But clients should never dictate security design. As a common theme in web development has it: your responsibility goes beyond your application.
Modern, safe, and user-friendly ways of handling user account security (involving hashed+salted storage of passwords with tokenised ways of resetting (but never retrieving!) them) have been available for at least five years now. People have thought long and hard about this problem. Repeated breaches have shown how dangerous it is to use anything less than secure encryption and robust ways of resetting passwords. There is really no excuse to not use industry-standard security measures.
Aries Systems: ‘We don’t collect financial information’
Aries Systems: “We do encrypt all passwords in our databases. Also, Editorial Manager does not collect or store any financial information.
I would be happy to discuss this with you further by telephone or email, and I hope you will understand the dynamics and trade-offs under consideration.”
This typical marketing response ignores a simple technical fact: any system that offers the possibility to switch on bizarre options like sending out or displaying plaintext passwords has to store its passwords in such a way that they can be easily fetched and decrypted. That’s the problem right there.
The final defense is that Editorial Manager doesn’t store financial information. You haven’t given us your creditcard, so we’ll just handle your user accounts in an irresponsible way mmkay? First, this is a blatant disregard of the simple principle, mentioned above, that your responsibility goes beyond your application. Second, this is of course only apparently a mitigating circumstance. It is widely known that about 60% of users reuse passwords across websites.
If EM were to be hacked, how many of those passwords would match with passwords on other services that do allow financial transactions? The userbase of EM consists of highly educated people in academia. They will have creditcards, Amazon accounts, Paypal wallets, iTunes IDs, et cetera. A significant chunk of them may use the same password for some of those services. Put these things together and suddenly Editorial Manager becomes a very interesting hacking target. (I would not say this out loud here if I had not communicated all this to Aries Systems well over a year ago.)
It’s not about financial information
Tell you what. Financial information isn’t the biggest thing at risk here. It is the very process of scholarly publishing. Editorial Manager is easily one of the weakest links in the chain of peer review. What if you could easily get access to someone’s account — pass yourself off as a peer reviewer, say, or get access to an editor’s account to invite your own friends (or yourself) to peer review your own papers?
This is not mere conjecture. It’s happened already, as documented by RetractionWatch: Elsevier’s editorial system (which is basically a branded version of EM) was hacked, leading to a peer review scandal and ultimately to a couple of retractions. The details of the case aren’t known, but with a link in the chain that is as weak as EM’s lighthearted handling of password security, I wouldn’t be surprised if some form of password hacking played a role; with the lax security of Editorial Manager, getting access to passwords is child’s play.
Let me end on a positive note. The journal Language recently transitioned to the open source Open Journal Systems, which, as far as I’ve been able to ascertain, handles passwords and account information in a much more secure and modern way. Such is the power of open source. Of course, this doesn’t really help us end users: we are unlikely to choose a publication venue on the basis of the manuscript management software they force us to use. But it does show that there are good models out there. Let’s hope that the dust kicked up by the Nature news story will bring some change for the better. Meanwhile, if you’re forced to use Editorial Manager, use disposable passwords and write to the editor to tell them of the risks of the system.
Max Planck Institute for Psycholinguistics, Nijmegen