Alternative to sending password over mail?

  • Recently I've started working as a contractor for a company, which requires me to often log in to different b2b services.

    The way I receive the login data is usually over email in plain text. My gut feeling tells me sending sensitive data in plain text is not a good idea however I'm not sure if there is an alternative, or perhaps it is already protected by the mailing service (in this case gmail)?

    I'm aware of probably the most obvious danger which would be leaving my email account logged in and unattended, however I'm more interested in some kind of a man in the middle attacks or other dangers.

    Core of my question is:

    Is there an alternative to sending passwords over email, and what would be biggest dangers of using email for this?

    Can you change the password?

    @schroeder technicly I can however there are other people who might have to use those accounts in the future so I'd have to send the new one back, so I guess that would miss the point

    @aMJay User accounts should be personalized whenever possible. When another person needs access to the system, then that person should get an own account.

    Can they provide you with access to a password manager through which they share these credentials with you?

    @BlueCacti thats something I'd have to discuss with them but I'll take it as potential alternative

    @aMJay If you want, I can add it as an answer. The advantage of them using a pw mgr is that they keep control of the credential and can revoke your access. If the creds are only used for web applications, LastPass (and probably others as well) can allow them to share the password with you without you being able to read the plain-text version of the password

    Vault offers a one time link. You can send that link by email and if it was clicked by anybody you will notice. This of course only works if quickly recognized and the passwords are unique to the task. Once established a login to vault you can also use it to share passwords. It has no comfy password sharing GUI or PAM/PQ manager functions but if all you need are secured password downloads it’s fine enough.

    Split the password. email part of it and text the other part.

    This is the result of folks setting requirements or rolling implementations without the requisite knowledge. Or, they know the problems and chose to accept the risk. You should read Peter Gutmann's *Engineering Security*.

    This is what key exchange is for. You can use Diffie Hellman over the phone (to prevent active MITM).

    Title would be more clear as "password over email" rather than "password over mail"

  • Philipp

    Philipp Correct answer

    2 years ago

    A common practice is to send the user an initial password via email which is only valid for a very short time and needs to be changed immediately during the first login.

    This is not perfect either. An attacker with read access to the user's email could intercept that initial password before the user and use it on their behalf. The user would notice as soon as they try to use their initial password. They would notify the admin that the password is wrong, the admin would investigate and notice the illegitimate access. But the attacker already had some time to access the account, so there might already be damage. But it's still better than sending a permanently valid password.

    It also requires that the system supports this. So it's not an universally applicable practice.

    When you don't trust your email provider to keep your emails secret (you are using gmail, a mail service financed by data-mining the content of your email and monetizing the results), then email encryption is an option. There is the good old PGP, the more modern PEP, the IETF standard S/MIME as well as some non-standardized proprietary solutions. That's the nice thing about standards: There are so many to choose from! But they all have one thing in common: They just don't catch on. Getting your business partners to encrypt their email in a scheme you understand can be an annoying uphill battle.

    One 'standard' that pretty much everybody has access to is an encrypted zip file. Not the strongest protection, but way better than plain text. Send its password over a different channel, text, voicemail, surname of that drunk we used to know at college.

    Or send a picture of a scrap piece of paper with the password. Obviously if you're explicitly being targeted then it doesn't matter, but if you're worried about passive mining then it'll add enough delay to the processing so that your time limited password will expire before it is leaked out.

    You may want to note that OpenPGP is also an IETF standard (RFC4880)

    It might help to add that turning on two factor/multi-factor authentication, when available, mitigates some of the risk of the interception of an initial or recently reset password.

    If the system can be controlled/altered, adding to the initial OTP a "only allow this action from trusted IP's" policy should improve it quite a bit (you limit the attack to your local network). Anyway, totally agree on PGP et al usage.

    Encrypting email is one of the worst experiences you can have. The whole process still feels straight out of the 90s (particularly funny since some of those standards are newer).

    @Voo That depends. At my job we have a plugin for Microsoft Outlook which encrypts emails without the user having to do anything. But it does of course require that the receiver also has the plugin installed.

    @Philipp And that there's infrastructure in place that makes sure the receiver already has your key. Which is where the fun begins. Oh and you obviously still have to be able to send unencrypted emails to most other people so there has to be some whitelist. So far so good, but what if you send an email to people that are on the "encrypted" list and to others that aren't? And so on and so on. Not fun, but sure the users only notice it if it doesn't work.

    @Neil_UK Or a KeepassDB and you give the password to the db by phone or other mean.

    Have you ever tried attaching an encrypted .zip file via Gmail? It won't be accepted; IOW, *it is impossible*. I tried that once, IIRC to send an .exe file, which Gmail won't allow either.

    @MikeWaters You can sometimes trick filters by _removing_ file extensions, and then, in the email's body, asking the user to re-add the correct extension after downloading the file --which you would specify in the email body.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM