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?

  • 12
    Can you change the password?
    – schroeder
    Commented Apr 3, 2019 at 10:17
  • 3
    @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
    Commented Apr 3, 2019 at 10:19
  • 54
    @aMJay User accounts should be personalized whenever possible. When another person needs access to the system, then that person should get an own account.
    – Philipp
    Commented Apr 3, 2019 at 11:28
  • 14
    Can they provide you with access to a password manager through which they share these credentials with you?
    – BlueCacti
    Commented Apr 3, 2019 at 11:43
  • 2
    @BlueCacti thats something I'd have to discuss with them but I'll take it as potential alternative
    – aMJay
    Commented Apr 3, 2019 at 11:48

17 Answers 17


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.

  • 11
    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.
    – Neil_UK
    Commented Apr 3, 2019 at 16:15
  • 8
    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.
    – Nelson
    Commented Apr 4, 2019 at 2:25
  • 1
    You may want to note that OpenPGP is also an IETF standard (RFC4880)
    – SEJPM
    Commented Apr 4, 2019 at 8:41
  • 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. Commented Apr 4, 2019 at 13:09
  • 1
    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. Commented Apr 4, 2019 at 18:58

I commonly use a Password manager to store and share passwords. There are many password managers that have this functionality.

A password is shared from one account to the other, with the notification of the share sent via email to the other person, who can choose to accept, reject, or just ignore the share. The communication of the password is secure, while the notification of the share travels over less secure channels like email, thus using the strength of each method without compromising security. Some products will allow for the share of the password without disclosing the password to the receiver. In that case revoking the password becomes possible.

I highly recommend using a password manager for all of your passwords. Some commercial ones are LastPass, 1Password or Dashlane but there is also the possibility to host one yourself if you don't want to trust anyone. A quick google search of "password manager" should put you on the right tracks.

  • 15
    Welcome to the site, Kent! Adding content can be tricky sometimes: you try to help using your experience but then people complain that it sounds like an ad. Thanks for sticking with it and updating your answer according to the comments! I hope you stay on the site :)
    – Luc
    Commented Apr 3, 2019 at 12:58
  • For completeness, I see Dashlane also widely used for access sharing with or without password disclosure (with possible access revocation).
    – zakinster
    Commented Apr 4, 2019 at 9:20
  • Yup, this is the "right" answer. At my employer, we use an internally hosted enterprise management solution with a web front end, and when we need to share passwords, we send an email with a link to the secret in question. (Basically - https://[ourpasswordmanagentserver.ourdomain.com]/SecretView.aspx?secretid=[######] ) Commented Apr 5, 2019 at 1:36
  • 1
    You cannot share a password without disclosing it. Sure, you can share it without showing it, but the person you share it with can still see the password somewhere else, be it on the page its filled on by changing the password field to a text field, or by lifting it from the network logs in their browser once the login request was sent. Any password manager that claims otherwise shouldn't be trusted.
    – PLPeeters
    Commented Apr 9, 2019 at 21:37

Two factors

Perhaps it's not literally appropriate for your situation, but one reasonable way to send sensitive data over channels that aren't entirely secure is to ensure that two separate factors are required to access that data and that they get sent over different channels. For example, I've seen approaches where the data is sent over email in an encrypted zip file, and the password to that data is sent over SMS. In this manner neither someone who has that email nor someone who has access to your phone can get to the sensitive information.

In a similar manner, it could be a better practice if you send the connection information over email and the password can be said over the phone (especially if it's like a passphrase) - but that choice is mostly up to the organization sending the data (who's supposedly the stakeholder who needs that data to be kept confidential), not to someone who's just receiving it.

  • 3
    This IMO is the right way to send data for authentication: use two separate channels. However I'd like to add one important note: both the sender and the receiver should then delete the data as soon as possible, by deleting the email, or the SMS, or the whatsapp message, etc. Also, I think that whatsapp messages are probably better than SMS's. You (and the other party) just need to remember to delete the message once the password has been stored somewhere else safely.
    – reed
    Commented Apr 3, 2019 at 13:11
  • 2
    @reed If the keys received through two channels are one-time and the user is prompted to enter a user-generated password immediately after using them, there is no need to remove the messages.
    – JiK
    Commented Apr 3, 2019 at 14:38
  • This is the way i usually do it. And I make sure not to mention anything about the host or login in the password-bearing text. Note this is also a good time to encourage people to use signal so the text itself is encrypted Commented Apr 3, 2019 at 18:49
  • 4
    Signal is probably the most secure way to send a message to someone's phone -- assuming both sides have Signal installed.
    – jcollum
    Commented Apr 3, 2019 at 20:39
  • @jcollum If they don't have it installed they need to GET it Commented Oct 28, 2021 at 13:07

If you trust it, onetimesecret (which is open source) exists for this exact purpose.

When you send people sensitive info like passwords and private links via email or chat, there are copies of that information stored in many places. If you use a one-time link instead, the information persists for a single viewing which means it can't be read by someone else later. This allows you to send sensitive information in a safe way knowing it's seen by one person only. Think of it like a self-destructing message.

  • 6
    Creating your own onetimesecret system is fairly trivial. I wrote a PoC in about a dozen lines of perl a few years back. Storing a secret (text) produces an URL that can be mailed safely. The URL can be opened exactly once, after which the secret is overwritten and then deleted. If you attempt to open it again results in a 404-like error message that also informs the visitor that if he sees that message the first time the URL is visited then someone else has seen it before, most like through an intercept of the mail with the link. Commented Apr 4, 2019 at 6:51

E-mail is not a good mechanism for sharing plaintext passwords given its inherently unencrypted nature.

If passwords are shared in this manner the service should ensure that the password is changed on first login to reduce the exposure (and to allow you to detect if someone has used the stolen password), not a perfect option as it still allows someone to take advantage of the window of opportunity to access the site but it is better than not knowing someone else has the password.

As this does not look to be an option for you given your reply to schroeder's comment I would suggest you look at a mechanism that guarantees encryption of the password all the way between your customer and yourself - either through end-to-end encryption of the e-mail contents or using an authenticated and encrypted sharing site where the plaintext passwords can be encrypted. Also think if you are really comfortable with other people (your customer, your other team members) knowing your password, something that would depend on the security requirements of the application you are accessing.

The main risk here would be who, apart from yourself, knows the password. In your case this would be, at least:

  • The person at your customer organisation that generated the password and e-mailed it to you
  • Anyone managing any e-mail infrastructure between your customer and yourself
  • Anyone with network access in any of the e-mail paths between your customer and yourself
  • The other team members that are working with the same account and password (inferred from your reply to schroeder's comment)
  • Anyone that may have access to your mailbox (e.g. your comment on leaving your e-mail client unattended)

If the only goal of the password is to avoid unauthorised access to the B2B services and you are comfortable with other people knowing your password then you can look at encryption for the password distribution. While many SMTP servers implement encryption for transferring data between mail server hops there is no encryption guarantee, plus inherently e-mails are not encrypted so the password will reside in plaintext at least during its processing at each of the mail transfer (SMTP) hops.

This means you need to look at end-to-end encryption to ensure that the password is not available to anyone snooping, such as PGP, S/MIME or some other assymetric encryption proprietary technology. These would guarantee confidentiality of the password while in transit, and you can still use e-mail for its distribution - with the tradeoff of a difficult setup and operational costs.

You could compromise and use something like an encrypted ZIP file or Office document with a pre-defined encryption password that is shared through a secure channel (e.g. a phone call), which will reduce both the operational overhead and the protection of the password. Similarly a cloud-hosted file with the passwords and protected with a securely shared secret would have the same advantages/disadvantages.


I've have a little project I created that I call "Secure Messaging Service" which will allow you to type in a message and generate a link to view that message. Once the message is viewed, it is removed from the database. It even supports sending an email when the message was read!

Type in a message and press "send", our server will generate a GUID based on uuidgenerator.net, a random 8 character passphrase based on passwordwolf.com (Which is not stored in our database), and will encrypt your message using AES-256-CBC. You'll then receive a link that contains the GUID and the passphrase to view the message (or to send to someone to view the message), as soon as the link is used the message will no longer exist in our database.

You now have the option for our service to send you an email when your message is read by the recipient. When you supply your email, we encrypt it before inserting it into our database using the same encryption method as your secret message, including the same passphrase. This passphrase is not stored in our server, it is given as part of the link to view the message.

Since everything sent to our server is encrypted with AES-256-CBC, and the passphrase only exists in the link provided, that means only you and whoever you send the link to can view the message. If anyone else wanted to view it, they've got to brute-force it. Fifty supercomputers that could check a billion billion (1018) AES keys per second (if such a device could ever be made) would, in theory, require about 3×1051 years to exhaust the 256-bit key space. We've done our best to make these messages not viewable by anyone but the person with the link, even if that person has database access, but we make no guarantees and are not responsible for any damage caused by using this service.

The Secure Messaging Service also has API support, meaning you could potentially automatically generate and send an email to users who are registering with a link to view their password.

This is how the data in the database is stored, as you can see, there is no way to recover the contents of the message using the information in the table, because it requires a special passphrase which is only appended to the link that is given to you when you create the message, and is not stored in the database.

enter image description here

  • Beautiful, simple and friendly UI, that is what I meant by my answer, I will bookmark your service to use it when I need it, thanks. Commented Apr 3, 2019 at 16:18
  • @Accountant Let me know if you can think of additional features or find any bugs. Glad you like it! :) (It won't let me directly @ you because of the symbol in your name) Commented Apr 3, 2019 at 16:29
  • 2
    I suggest you get the actual secret message and delete it when the user hover/click this box (by an AJAX request), that will prevent the password gets deleted by automatic requests made by email agents or by WhatsApp, facebook bots (If I send the link to my friend in whatsapp or facebook, these programs bots will make a request automatically which will cause the secret to be deleted) . other than that it's very nice 👍 Commented Apr 3, 2019 at 16:34
  • 2
    @Accountant Good idea, I'll definitely consider adding that. Commented Apr 3, 2019 at 16:35
  • 1
    @aCVn Simple, if you don't trust the service, don't use it. There are several other services that do similar things. I've laid out in the about page exactly how it works, what it stores, and that's all I can really do to try to "prove" to people they can trust the service. I also don't see what I could gain by lying about any of that, considering the service is anonymous. Commented Apr 3, 2019 at 17:41

I don't understand why you are sending them the passwords ?

The clients set their preferred password, you hash it, store the hash, and no one except the client/his password manager program knows the original password (not even you), and when they forget it, you send them a reset link.

However if you really have to send him the password, I suggest you send him a link to dynamically generated webpage that displays his password (for 1 time only).

you need to temporarily store something like this in your database

 emailTocken char(32)
 password    varchar

 | emailTocken                      |     password     |
 | 202CB962AC59075B964B07152D234B70 |   jhds7ytht_id   |
 | CF297E613A7F7892A3BF348EE526ABAD |   hdhdbdue874#   |
 | 8F14E45FCEEA167A5A36DEDD4BEA2543 |   yeheb8cvddt5)  |
 | 2510C39011C5BE704182423E3A695E91 |   6#hdyd98_jee   |
 | 8F14E45FCEEA167A5A36DEDD4BEA2543 |   yhrtxbxv48_e   |

and send to him an email that you expose only the emailTocken not the password

 Hello, client

 Follow this link to see your password

on the webserver when someone requests this link you do the following

  1. select the password that has the emailTocken provided
  2. delete it's record from the database

Now the first one who requests this link will see something like

 Hello, client 
 your password is yeheb8cvddt5)

If anyone later requests the same link he will see something like

Sorry, this password is not exist or has been viewed before!

Advantages of this approach over sending the password in email:

  1. the password is exposed only 1 time for the first viewer, not for whoever see the email later.
  2. if someone else viewed the password firstly (a man-in-the-middle), the legitimate user will not be able to see it and will ask for help, which will make us know that there is something wrong happened, better than someone else see it, and we don't even know. I hope your email agent program doesn't request this automatically for any reason :( .

disadvantages of this approach over sending the password in email:

  1. requires web server
  2. more work than just sending the poassword in email easily

As I told you before, no one except the client should know the password, and I never tried this approach, but at least its better than exposing the password in plain text in an EMAIL that can reside on many computers/servers for a while.

  • 1
    I thought about this solution before, but as we all know I (i.e. the average programmer) is in 99.91% of the cases well advised to not custom build security related tools. So I always asked myself, if this is really a good idea, where is the tested, proven Open Source tool, that does exactly this, then?
    – s1lv3r
    Commented Apr 3, 2019 at 17:59
  • @s1lv3r As I mentioned in the answer, I never tried it, I only hash salted passwords and save the hash, and when my clients ask for the password, I give them a reset link. However the suggested solution is better compared to plain password in emails! Commented Apr 3, 2019 at 18:05
  • 2
    @s1lv3r check this answer, he actually did it. And this one too Commented Apr 3, 2019 at 18:07
  • 1
    This is a reasonable way to implement passwords in a custom system, but my impression is that the OP is asking about situations where the companies they're working with are generating passwords for various third-party pieces of software and services they use. Commented Apr 5, 2019 at 14:39
  • @XiongChiamiov Yes I understand that. Instead of generating passwords and send them to their owners in emails, generate the passwords and save them on the database and send the links. Commented Apr 5, 2019 at 14:52

Ask them to instead pick up the phone and call you. Using out of band communication significantly reduces the likelihood of a eavesdropper getting access to your information. This is partly because it isn't unlikely that an attacker would have compromised your email system, or your phone system, but the odds of them having compromised both is low. if you can split up the vital information (e.g. username in email, password by phone, etc) then it just becomes harder for the attacker, relatively to the increase in work required of you.

  • Yep, I've used "read a temporary password over the phone" a few times when dealing with less technically savvy people on the other side who couldn't get things like GPG working. Annoying, but practical. Commented Apr 5, 2019 at 14:41

I would suggest to use Signal to send and receive passwords. It is an end-to-end encrypted chat app.

Signal messages and calls are always end-to-end encrypted and painstakingly engineered to keep your communication safe. We can't read your messages or see your calls, and no one else can either.

No email is not safe because even if you use SSL on your mail servers there is a record of the message on the server's disk which can be read by an administrator. Only PGP/GPG or SMIME encrypted email would be safe.

Someone added the following to my answer. I've not heard of them so cannot recommend.

On top of Signal - another encrypted option of exchanging messages can be used, that doesn't require to confirm your ID by clicking links or providing e-mail etc. It's also multi-platform which is very important. It is

  1. for Android: Conversation app
  2. for Linux and Windows: Gajim app

It can use either PGP or OMEMO encryption - plug in might need to be installed separately.

There is also another method, probably the best in your situation.

It requires you to have a website with SSL and on a website and embedded box. Someone can write a message in that box and upon sending, message should be encrypted with [i.e.] PGP public key which can only be auto decrypted on your PC email.

  • @Over-heads Are you in answer ban due to a downvoted/deleted answer? If yes, could you remember, 1) how many answer did you write? 2) by how many of them did you see that they were downvoted (the number top left was negative)? | Btw, probably you can post again in 2 weeks.
    – peterh
    Commented Apr 5, 2019 at 16:12
  • @Over-heads Here you see the list of your deleted answers. How many answers are there, and how many of them has negative score? security.stackexchange.com/users/recently-deleted-answers/…
    – peterh
    Commented Apr 5, 2019 at 16:13

To start with, this is kind of a bad situation. It sounds like you're sharing user accounts. Sometimes there's no good alternative to this, but it shouldn't be used with anything particularly sensitive because it gets much harder to audit use of the resource when there are multiple people logging in under the same name.

If it's really necessary to have multiple people using the same accounts, then the credentials should be delivered in person.

That's probably not practical, so your next best option is to send them via landline telephone. (In most countries at least.) Landlines are relatively difficult to intercept and in most countries the phone company is prohibited from listening in without a court order. Government spy agencies might be listening, but if they want your passwords they'll just beat you until you hand them over anyway.

Around the same level of security is encrypted email via GPG or similar. It's easier for third parties to intercept and store the data, but harder for them to read it until they have enough time to crack the key. Make sure to change the password every few years and make sure you don't use the same form letter every time as that makes cracking it easier.

If you can't get them on board with that then a book code is your next best bet. Needs to be a book that everybody has and uses all the time anyway, so that might be a bit tricky. Typical format is something like pagenumber-paragraphnumber-wordnumber. Make the passwords be four or five words and it'll work nicely. Or spell it out using the first letter of each specified word if necessary.

If a book code won't work then as long as the password doesn't contain any words or wordlike structures a simple substitution or transposition cipher like are used for the cryptograms in the newspaper will be sufficient to keep out all but the most determined attackers. But the password has to be random characters or statistical analysis will make short work of it and you still have to deliver the encryption key via a secure channel. Obviously with this method you encrypt only the password to limit your attack surface and, preferably, make no mention at all of the fact that you've scrambled it in the rest of the email. All discussion of the fact that the password is encrypted and how must be via a secure channel.


Correct, it is unsafe to send a password in an email.

A safe initial account protocol is:

Send the user a single use, expiring hyperlink and allow the user to set their initial password from that link. Then, optionally verify the user has set up the second factor. Then, optionally check the user's identity in some other way (video call?) Finally, provision the user's account with the access they require.


The good ol' phone call is a tried and true method.

Aside from this, an SSH handshake is a good method...

Both you and the recipient generate an SSH key. You generate a password and encrypt the password using your key. You send encrypted password to the client. They add an additional encryption to your message using their key. Then they send you back the double-encrypted message. You decrypt this message, leaving just the password encrypted by the recipient's key. You send back this message. They decrypt it using their password to get the password. This way unencrypted data never touches the web.

  • 1
    Why do this when you can just use PGP, which is actually intended for things like this?
    – ave
    Commented Apr 5, 2019 at 13:19

There is a typical use case for distributed developement teams where SysOps and TeamMembers creates credentials to a resource (DataBase, service, server) and needs to comunicate it to the team. IF you add a new member to the team :

  • You can't just hash the password.
  • You can't just reset the password or it will stop working for the rest of the team.

We use a distributed password manager. This allow us to add a new password and share it with individuals or groups. You will receive an e-mail like "BOFH-1 shared the password 'JenkinAdmin'". You need to log in to see the real password that will travel through https.

A centralized tool may be an overkill for some scenarios as it force you to some installation and configuration. It is great if all your department use it to update it. Only one person need to update the credential in the password manager. We use an open source tool but specific programs are better discussed in Software recommendations

  • This is already covered by the more generic password manager answer. Please do not post ads for specific products.
    – schroeder
    Commented Apr 5, 2019 at 20:07
  • @schroeder I had removed the reference to the solution even if it is open source.
    – borjab
    Commented Apr 12, 2019 at 18:45

You could use SendPass (https://sendpass.app)

In my opinion, the two biggest risks of sending plain-text passwords are that they may reside in archives, logs or still in the user's mailbox, and the second one being interception of the password and the actual recipient not knowing of this (and therefore not notifying the admin).

To address these risks, I have created a free application which you can use to send a one-time code that can be used by the recipient to retrieve the password. I've published SendPass to help others, especially non-technical people, but it may be of use to you as well.

SendPass offers you a free, easy and secure way to share passwords. SendPass works by generating a unique, one-time code which you can send to your recipient. The code is only able to be used once, after which the password will be instantly deleted.


If your email is preset by the company then a solution is not to have a password at all (the password is seeded with a long, complicated, etc. string nobody knows).

You then request a new one (though the "Forgotten password" functionality), which sends you a reset link to your email.

  • this is covered in the comments to the question
    – schroeder
    Commented Apr 5, 2019 at 20:09

OAuth is the alternative to access third party systems without the requirement to set up password authentication in said systems and eliminates the need to exchange passwords. Of course, that would require that systems to support OAuth, which is not always the case.

  • This does not answer the question
    – schroeder
    Commented Apr 5, 2019 at 20:10
  • 1
    @schroeder, could you elaborate?
    – n0rd
    Commented Apr 5, 2019 at 20:23
  • 1
    That's an alternative to needing to send a password at all. It's a reframing of the problem. The implication is that a password needs to be communicated.
    – schroeder
    Commented Apr 5, 2019 at 20:37
  • 1
    Alternatives are exactly what this question is about. There is no premise that OAuth is not an option. A lot of B2B applications I've dealt with do support it, but people who use it often disregard that capability.
    – n0rd
    Commented Apr 5, 2019 at 20:46
  • 1
    The set of apps I worked with is definitely skewed though, as those are mostly hosted in Azure and support Azure AD.
    – n0rd
    Commented Apr 5, 2019 at 20:48

The first thing that comes to my mind is asymmetric encryption (e.g. GPG). This could be particularly useful without overcomplicating things.

Find or set up a public key server and let everyone share their public keys. Then whenever you need to share something sensitive to a specific recipient, you can grab his key and encrypt the content. No one else will know the original content except the recipient.

An example email would become:

Hi iBug,

Here's your login credential to Information Security Stack Exchange. It's encrypted with your key DEADBEEF found on our corporate key server.

 < GPG Encrypted Message >
  • already covered by other answers
    – schroeder
    Commented Apr 5, 2019 at 20:09

You must log in to answer this question.

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