Alternative to sending password over mail?

Question

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?

@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, Apr 03 '19 at 10:19
@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, Apr 03 '19 at 11:28
Can they provide you with access to a password manager through which they share these credentials with you? — BlueCacti, Apr 03 '19 at 11:43
@BlueCacti thats something I'd have to discuss with them but I'll take it as potential alternative — aMJay, Apr 03 '19 at 11:48
@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 — BlueCacti, Apr 03 '19 at 12:31
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. — eckes, Apr 03 '19 at 18:55
Split the password. email part of it and text the other part. — Sherwood Botsford, Apr 03 '19 at 22:31
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](http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf)*. — , Apr 04 '19 at 14:27
This is what key exchange is for. You can use Diffie Hellman over the phone (to prevent active MITM). — Reinstate Monica, Apr 05 '19 at 18:27
Title would be more clear as "password over email" rather than "password over mail" — chux - Reinstate Monica, Apr 06 '19 at 01:13
Does this answer your question? [Sending passwords to someone remotely](https://security.stackexchange.com/questions/58509/sending-passwords-to-someone-remotely) — RemarkLima, Mar 13 '21 at 08:56

score 69 · Answer 1 · edited Apr 04 '19 at 15:50

69

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.

edited Apr 04 '19 at 15:50

DysphoricUnicorn

103
3

answered Apr 03 '19 at 12:04

Kent

607
4
4

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 Apr 03 '19 at 12:58
For completeness, I see [Dashlane](https://www.dashlane.com) also widely used for access sharing with or without password disclosure (with possible access revocation). – zakinster Apr 04 '19 at 09: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=[######] ) – HopelessN00b Apr 05 '19 at 01: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 Apr 09 '19 at 21:37

Philipp · Accepted Answer · 2019-04-03T11:19:26.857

63

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.

edited Apr 03 '19 at 11:19

answered Apr 03 '19 at 11:13

Philipp

49,017
8
127
158

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 Apr 03 '19 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 Apr 04 '19 at 02:25
1

You may want to note that OpenPGP is also an IETF standard ([RFC4880](https://tools.ietf.org/html/rfc4880)) – SEJPM Apr 04 '19 at 08: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. – Todd Wilcox Apr 04 '19 at 13:09
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. – bradbury9 Apr 04 '19 at 13:17
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 Apr 04 '19 at 13:39
@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 Apr 04 '19 at 13:54
@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. – Voo Apr 04 '19 at 14:06
@Neil_UK Or a KeepassDB and you give the password to the db by phone or other mean. – Bakuriu Apr 04 '19 at 18:34
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. – Mike Waters Apr 04 '19 at 18:58
@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. – code_dredd Apr 06 '19 at 01:30

Peteris · Answer 3 · 2019-04-03T18:56:38.060

27

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.

edited Apr 03 '19 at 18:56

answered Apr 03 '19 at 11:20

Peteris

8,389
1
27
35

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 Apr 03 '19 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 Apr 03 '19 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 – George M Reinstate Monica Apr 03 '19 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 Apr 03 '19 at 20:39
@jcollum If they don't have it installed they need to GET it – Noah Broyles Oct 28 '21 at 13:07

score 15 · Answer 4 · answered Apr 03 '19 at 14:32

15

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.

answered Apr 03 '19 at 14:32

user137369

713
5
9

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. – P. Goetterup Apr 04 '19 at 06:51

score 4 · Answer 5 · answered Apr 03 '19 at 11:20

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.

AccountantM · Answer 6 · 2019-04-04T12:27:45.223

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
 https://example.com/showPassword?emailTocken=8F14E45FCEEA167A5A36DEDD4BEA2543

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

select the password that has the emailTocken provided
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)
 NOTE: WE WILL DELETE THIS PASSWORD FROM OUR SERVERS, SO YOU HAVE TO REMEMBER/SAVE IT

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:

the password is exposed only 1 time for the first viewer, not for whoever see the email later.
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:

requires web server
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.

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, Apr 03 '19 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!** — AccountantM, Apr 03 '19 at 18:05
@s1lv3r check [this answer](https://security.stackexchange.com/a/206724/149722), he actually did it. And [this one](https://security.stackexchange.com/a/206709/149722) too — AccountantM, Apr 03 '19 at 18:07
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. — Xiong Chiamiov, Apr 05 '19 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. — AccountantM, Apr 05 '19 at 14:52

GrumpyCrouton · Answer 7 · 2019-04-03T17:49:47.670

3

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.

edited Apr 03 '19 at 17:49

answered Apr 03 '19 at 16:08

GrumpyCrouton

131
4

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. – AccountantM Apr 03 '19 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) – GrumpyCrouton Apr 03 '19 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 – AccountantM Apr 03 '19 at 16:34
2

@Accountant Good idea, I'll definitely consider adding that. – GrumpyCrouton Apr 03 '19 at 16:35
This might be a useful service for some people, but why should we trust you? – user Apr 03 '19 at 17:01
@aCVn valid worry, but why should we trust our OS makers, web hosting companies, everyday programs ? **LAW**. a little user agreement will be enough, other than that, do we technically trust or even know every line of code we use everyday? another reason for me to trust him is that this is a light service that doesn't require registration, which makes him doesn't know who am I or who is the person that I sent the password to, or even what password is this, where can it be used for ? **He just sees secrets for users he doesn't know anything about them more than their IPs/browsers user-agents.** – AccountantM Apr 03 '19 at 17:33
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. – GrumpyCrouton Apr 03 '19 at 17:41
@aCVn I added an image which shows how everything is stored in the database. I may even consider uploading the code to github if I stop being lazy one day – GrumpyCrouton Apr 03 '19 at 17:52
@AccountantM Not sure if you are still interested in this project at all, or even remember it (I forgot about it, even though I was still hosting it), but someone upvoted my answer here which reminded me of this project. Turns out it has seen some use in the last few months, which I didn't even know about. Took some time today to completely rewrite it. Check out the changes I made! – GrumpyCrouton Jun 18 '20 at 01:09
@GrumpyCrouton Hello, yes I remember your project and it stills in my bookmarked sites, but I didn't use it yet. Congratulations on the new changes in the look and feel(looks better), I didn't check the network traffic yet, but I will give it a deeper look tonight. – AccountantM Jun 18 '20 at 13:12
@AccountantM Awesome. I'm thinking about implementing some way for people to _respond_ back to messages they are sent (if the sender inputted an email, but without actually showing the senders email to the receiver), sort of like the way the Contact Us page works. Another idea that I had was allowing senders to set an additional password that the receiver must enter manually before revealing the secret. Let me know what you think! – GrumpyCrouton Jun 18 '20 at 15:36

Chloe · Answer 8 · 2019-04-10T18:15:02.540

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

for Android: Conversation app
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, Apr 05 '19 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? https://security.stackexchange.com/users/recently-deleted-answers/203877 — peterh, Apr 05 '19 at 16:13

score 3 · Answer 9 · answered Apr 04 '19 at 12:54

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. — Xiong Chiamiov, Apr 05 '19 at 14:41

score 2 · Answer 10 · answered Apr 03 '19 at 19:07

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.

borjab · Answer 11 · 2019-04-12T18:36:01.463

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, Apr 05 '19 at 20:07
@schroeder I had removed the reference to the solution even if it is open source. — borjab, Apr 12 '19 at 18:45

score 2 · Answer 12 · answered Apr 03 '19 at 21:03

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.

bremen_matt · Answer 13 · 2019-04-04T05:37:01.167

2

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.

edited Apr 04 '19 at 05:37

answered Apr 04 '19 at 05:31

bremen_matt

131
3

1

Why do this when you can just use PGP, which is actually intended for things like this? – ave Apr 05 '19 at 13:19

Toine-L · Answer 14 · 2019-09-26T17:53:59.403

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.

WoJ · Answer 15 · 2019-04-03T16:57:40.953

1

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.

edited Apr 03 '19 at 16:57

answered Apr 03 '19 at 15:33

WoJ

8,968
3
33
51

this is covered in the comments to the question – schroeder Apr 05 '19 at 20:09

score 0 · Answer 16 · answered Apr 04 '19 at 04:46

0

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.

answered Apr 04 '19 at 04:46

n0rd

109
4

This does not answer the question – schroeder Apr 05 '19 at 20:10
1

@schroeder, could you elaborate? – n0rd Apr 05 '19 at 20:23
I mean, how is `OAuth` is not an answer to `Is there an alternative to sending passwords over email...`? (With the assumption that just `yes` is not enough) – n0rd Apr 05 '19 at 20:33
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 Apr 05 '19 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 Apr 05 '19 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 Apr 05 '19 at 20:48

score 0 · Answer 17 · edited Jun 16 '20 at 09:49

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 Apr 05 '19 at 20:09 — schroeder, Apr 05 '19 at 20:09

Alternative to sending password over mail?

17 Answers17

Two factors