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.

Editorial manager

Every academic will run into Editorial Manager and its kin 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. Elsevier has its own branded version (EES) of what is essentially the same software.

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.

Take PLOS ONE (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. You didn’t ask for this. 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. Many 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.1

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 (1 2 3 4 5). The fact that some system sends you your password by email means that your password could be intercepted by any old packet sniffer on a network that you’re using (think free wifi). 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.

Worse, the fact that the system can send out passwords means that passwords are 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 on the server, 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.

So EM freely shares passwords in emails. It also displays passwords on profile pages, offering further proof of the lack of encryption (or the use of reversible encryption). 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 respond to the issue. After a first email went unanswered, a reminder email 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 suggests 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 principle in web development states, 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. It is remarkable to see such a blatant disregard of industry-standard security measures.

Aries Systems continues by saying, “We do encrypt all passwords.” Here is 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. No matter how creatively you define “encryption”, you can’t get around that as long as you offer this ‘service’ to your customers.2

Aries Systems: ‘We don’t collect financial information’

Aries Systems: “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.”

The final defense is that Editorial Manager doesn’t store financial information. This sounds like, “You haven’t given us your creditcard, so we’ll just handle your user accounts in an irresponsible way.” This disregards the fundamental principle, mentioned above, that your responsibility goes beyond your application. Additionally, it is of course only apparently a mitigating circumstance. It is widely known that about 60% of users reuse passwords across websites.

If malicious hackers were to get access to an EM server, how many of the emails and passwords would match with accounts on other services that do allow financial transactions? The userbase of EM consists of highly educated people in academia. They 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 just about financial information

The problem is not just about credit cards and such, but about the security of 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 (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.

 

Mark Dingemanse
Max Planck Institute for Psycholinguistics, Nijmegen

1. To be clear, this is not about sending the user a password upon first registration. Although even this is frowned upon by security experts, some websites do this while still storing the password in a secure way. Editorial Manager, however, sends users their password in plaintext when they’re already registered, without them asking for it — and it does so routinely, for instance when sending out notifications of submissions awaiting approval. [↩]
2. In a follow-up email exchange, Fleet refused to answer my more detailed questions about their security design, “due to the potential exposure to which that may lead”. Even without that information it is already clear that passwords are not being hashed and salted. If they were, the system wouldn’t be able to give me my password. [↩]