Bsrgvty

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.

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.

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.

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 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

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)
 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:

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.

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.

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.

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.

We use Passbolt for sharing and storing passwords. This is especially useful for credentials that must be shared by a team and updated periodically like for servers or databases. And sharing passwords between groups is quite useful. This kind of centralized tool is great if all your department use but require some installation and configuration.

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.

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.

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.

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.

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.

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 >