5

I work as a tester at a company that makes network security appliances, I am having some discussions with a developer about a feature.

The feature is that the notification e-mails sent to the user by the appliance will be sent using the user credentials (e-mail and e-mail password) using whatever mail server the user uses (gmail, local mail server, etc)

These credentials are inside the machine in plain text, and is available with a cat to the right file. The developer argues that there is no point in trying to use any encryption because they always will need to decrypt it when sending the credentials to the mail server.

Now I do not know what to think, is there a correct way of doing this? or is the feature insecure and there is no secure way of doing it?

10
  • 2
    That is really phishy and insecure. I also do not see any point in the described mechanism, could you elaborate a bit more on the intended use?
    – Kevin
    Nov 22, 2017 at 18:22
  • @KevinVoorn Is it intended to send e-mails to the user from the appliance. And using any e-mail address that the user wants
    – Dodd
    Nov 22, 2017 at 18:32
  • So if I understand correctly; the users can choose their mail provider and provide login credentials and server details (such as POP3 server and port etc.) and those details are stored in plain text on the server machine and used to send notifications using those details?
    – Kevin
    Nov 22, 2017 at 18:36
  • 8
    I think the only practical solution here would be changing how you deliver the notifications, e.g. by using one of your own services instead of a customer-supplied mail provider. Otherwise you'll eventually have no choice but to handle plain credentials at some point (that is, if integrating lots of mail provider APIs isn't an option).
    – Arminius
    Nov 22, 2017 at 19:01
  • 1
    As a simple answer to the question posed, without technical data to back it up: YES. And no user should ever provide that info to anyone Nov 22, 2017 at 19:44

4 Answers 4

2

What is your threat model? Who is going to try to steal the password and how?

If you run the application as its own user, and only that user can access that password file, and you trust root, then it's okay.

Ideally, the application would send from its own email account, so if there was a compromise, the impact is minimal (or customer can always create a new freemail account just for this app)

If you don't trust root (because you're running on AWS or similar), then you're not fine.

But we can't know until you tell us your threat model

1
  • We have network appliances that are used in small and medium companies and government. The password could be stolen if for example a network is compromised and the hackers are trying to get credentials to further take control.
    – Dodd
    Nov 23, 2017 at 11:39
-2

Your developer needs to be sat down to discuss good security practices.

Essentially, leaving data encrypted on disk means that all an attacker has to do is get access to the body of that file. Your developer cannot guarantee that his software is free of security vulnerabilities, the other software on the system is free of vulnerabilities, and the operating system is free of vulnerabilities. He also can't guarantee that the system will be operating in single user mode, or with good file system level security applied to the system. He also can't guarantee that the hard disk will never end up mounted to a different operating system that cares nothing for any system level security.

Essentially, he is ensuring that he is sharing the users data with anyone else who has access to that operating system (legitimate or not). He is doing this without the end-users knowledge.

But, you are also only going half-way with the idea of encrypting the user's data. In reality, you shouldn't be storing the user's password at all - you should be using the API of the email client in question, such as Gmail's OAuth2 integration https://developers.google.com/gmail/api/auth/web-server to connect to the email account. This is the right way to do it, and avoids having any credentials lying around, encrypted or not. The same is true for pretty much any mail client - integrate with their given API. Chance are, it does not require knowing the user's password other than perhaps on the very first hand-shake.

9
  • 1
    But ultimately you'll always have sensitive data on the machine. If it's not a password then you still have the private API token stored somewhere (although that's better). Also, integrating mail providers' APIs might not be practical for OP since they don't control what providers their customers use.
    – Arminius
    Nov 22, 2017 at 18:50
  • Correct. It's always a trade off. This is the best security model we have for third party authentication that by its nature can not require user interaction. Additionally, the needs to decide how many third party apps they need to support and then create methods for handling each one. Just supporting Gmail securely is better than supporting all email clients, but insecurely. Nov 22, 2017 at 18:52
  • 2
    You're assuming they all have APIs.
    – Arminius
    Nov 22, 2017 at 19:59
  • 3
    It's all well and fine to say that “you shouldn't be storing the user's password at all”, but what else can you do, apart from not implementing the feature? Some email providers can hand out application passwords (API tokens or whatever you choose to call it), and these are preferable to the user's master password, but it's still a credential that the application needs to have when it sends the email. For email providers that only grant one set of SMTP credentials and that's it, there's no choice. Nov 22, 2017 at 21:24
  • 3
    @Adonalsium A "reasonable set of email providers" for a enterprise network security appliance is: "SMTP." End of story, pretty much.
    – Xander
    Nov 23, 2017 at 0:15
-3

Storing a password in plain text is widely considered to be insecure no matter the use or security measurements. As discussed in the comment section, your question is about users giving their login credentials, server details and information about their mail provider to be used for sending notifications to that same user.

To be very clear about storing password in plain text: This is not a secure way of handling passwords at all. To elaborate on this a bit more, someone could hack into the server machine, use a flaw or bug in the application itself or steal any backups that are made. There are so many ways of leaking the login details, I'm struggling to find any reason why you would store credentials in plain text.

As can be read in this paper, there have been a lot of major password leakage incidents recently where passwords were stored in plain text. The paper also explains a lot about the concepts of password and storing them securely, a worthy read for the developer I presume.

The developer is right when he says he would need to decrypt passwords to send those to the mail provider, although the application should be using the API of mail server providers to send notifications without even needing the password in the first place.

3
  • 1
    Unencrypted is not secure, but there is also no secure way to encrypt it (unless you involve trusted computing hardware, and even then the attack surface is very big).
    – eckes
    Nov 22, 2017 at 19:27
  • 1
    “the application should be using the API of mail server providers” That's assuming that there's an API, and if that API is authenticated (spam email being a thing, it should be), then the application would need to store the API credential. Nov 22, 2017 at 21:26
  • In a manner of speaking, it is using an API. Specifically, the SMTP specification, which in order to make an authenticated (and that is indeed what you want) connection, is going to require credentials for the account it is to use.
    – Xander
    Nov 22, 2017 at 23:44
-3

This is entirely wrong.

To send an email, all that is needed is a running smtp server (does not necessarily require any credentials, least of all from an end user) and a "to" address. It is the responsibility of the appliance to provide or use a suitable smtp server.

No need to use the user's credentials. In fact, I would never give anyone my e-mail account password. It is of no use except for me.

Your developer got the process of sending e-mail totally wrong.

2
  • 2
    You don't want it running its own SMTP server. You do want it to have SMTP credentials, so it can make an authenticated connection to an SMTP server, under the "use a suitable smtp server" segment of your answer.
    – Xander
    Nov 22, 2017 at 23:40
  • This is indeed wrong. To guarantee that an email lands in an inbox, you must ensure your mail transfer agent ("smtp server") is listed in your domains SPF records, has domainkeys authority for the domain, etc. Since your server would be claiming the domain gmail.com, your server must therefore be listed in gmail.coms SPF and be authorised via DKIM, which you can't do without having complete control over the zone, gmail.com.
    – autistic
    Nov 23, 2017 at 23:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .