Alternative to sending password over mail?Secure alternative to e-mailA secure alternative for e-mailStoring passwords in text files inside Ubuntu encrypted home directoryEmail unsubscribe handling securitySending Mail Using TLSIs it dangerous to program a user-called deamon that sends passwords via https?Is sending personal information over email between different providers secure?Does a signed hash reveal any information about the original message?Is Mailbait still a threat?How do I make safe login-emails? (GET/POST)

What do you call a Matrix-like slowdown and camera movement effect?

The magic money tree problem

Extreme, but not acceptable situation and I can't start the work tomorrow morning

How can the DM most effectively choose 1 out of an odd number of players to be targeted by an attack or effect?

Can I interfere when another PC is about to be attacked?

Why doesn't Newton's third law mean a person bounces back to where they started when they hit the ground?

Why is an old chain unsafe?

The use of multiple foreign keys on same column in SQL Server

When blogging recipes, how can I support both readers who want the narrative/journey and ones who want the printer-friendly recipe?

Are white and non-white police officers equally likely to kill black suspects?

Why did the Germans forbid the possession of pet pigeons in Rostov-on-Don in 1941?

"which" command doesn't work / path of Safari?

Why was the small council so happy for Tyrion to become the Master of Coin?

Prevent a directory in /tmp from being deleted

What typically incentivizes a professor to change jobs to a lower ranking university?

What is the white spray-pattern residue inside these Falcon Heavy nozzles?

What does "enim et" mean?

How do you conduct xenoanthropology after first contact?

Circuitry of TV splitters

Download, install and reboot computer at night if needed

Example of a relative pronoun

Can an x86 CPU running in real mode be considered to be basically an 8086 CPU?

Copycat chess is back

What is GPS' 19 year rollover and does it present a cybersecurity issue?



Alternative to sending password over mail?


Secure alternative to e-mailA secure alternative for e-mailStoring passwords in text files inside Ubuntu encrypted home directoryEmail unsubscribe handling securitySending Mail Using TLSIs it dangerous to program a user-called deamon that sends passwords via https?Is sending personal information over email between different providers secure?Does a signed hash reveal any information about the original message?Is Mailbait still a threat?How do I make safe login-emails? (GET/POST)






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








52















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?










share|improve this question



















  • 12





    Can you change the password?

    – schroeder
    Apr 3 at 10:17






  • 2





    @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 3 at 10:19






  • 53





    @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 3 at 11:28






  • 13





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

    – BlueCacti
    Apr 3 at 11:43






  • 2





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

    – aMJay
    Apr 3 at 11:48

















52















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?










share|improve this question



















  • 12





    Can you change the password?

    – schroeder
    Apr 3 at 10:17






  • 2





    @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 3 at 10:19






  • 53





    @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 3 at 11:28






  • 13





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

    – BlueCacti
    Apr 3 at 11:43






  • 2





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

    – aMJay
    Apr 3 at 11:48













52












52








52


12






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?










share|improve this 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?







email password-management data-leakage






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 3 at 12:21







aMJay

















asked Apr 3 at 10:10









aMJayaMJay

5761412




5761412







  • 12





    Can you change the password?

    – schroeder
    Apr 3 at 10:17






  • 2





    @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 3 at 10:19






  • 53





    @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 3 at 11:28






  • 13





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

    – BlueCacti
    Apr 3 at 11:43






  • 2





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

    – aMJay
    Apr 3 at 11:48












  • 12





    Can you change the password?

    – schroeder
    Apr 3 at 10:17






  • 2





    @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 3 at 10:19






  • 53





    @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 3 at 11:28






  • 13





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

    – BlueCacti
    Apr 3 at 11:43






  • 2





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

    – aMJay
    Apr 3 at 11:48







12




12





Can you change the password?

– schroeder
Apr 3 at 10:17





Can you change the password?

– schroeder
Apr 3 at 10:17




2




2





@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 3 at 10:19





@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 3 at 10:19




53




53





@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 3 at 11:28





@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 3 at 11:28




13




13





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

– BlueCacti
Apr 3 at 11:43





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

– BlueCacti
Apr 3 at 11:43




2




2





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

– aMJay
Apr 3 at 11:48





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

– aMJay
Apr 3 at 11:48










16 Answers
16






active

oldest

votes


















58














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.






share|improve this answer




















  • 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 3 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 4 at 2:25







  • 1





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

    – SEJPM
    Apr 4 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.

    – Todd Wilcox
    Apr 4 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.

    – Mike Waters
    Apr 4 at 18:58


















65














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.






share|improve this answer










New contributor




Kent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.















  • 8





    This is a much stronger answer, thanks

    – schroeder
    Apr 3 at 12:35






  • 14





    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 3 at 12:58











  • For completeness, I see Dashlane also widely used for access sharing with or without password disclosure (with possible access revocation).

    – zakinster
    Apr 4 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=[######] )

    – HopelessN00b
    Apr 5 at 1:36


















23














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.






share|improve this answer




















  • 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 3 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 3 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
    Apr 3 at 18:49







  • 3





    Signal is probably the most secure way to send a message to someone's phone -- assuming both sides have Signal installed.

    – jcollum
    Apr 3 at 20:39


















6














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.







share|improve this answer


















  • 2





    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 4 at 6:51



















4














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.






share|improve this answer






























    3














    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.






    share|improve this answer

























    • 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 3 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 3 at 18:05






    • 2





      @s1lv3r check this answer, he actually did it. And this one too

      – AccountantM
      Apr 3 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.

      – Xiong Chiamiov
      2 days ago











    • @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
      2 days ago


















    2














    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






    share|improve this answer










    New contributor




    GrumpyCrouton is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.




















    • 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 3 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 3 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 3 at 16:34






    • 2





      @Accountant Good idea, I'll definitely consider adding that.

      – GrumpyCrouton
      Apr 3 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.

      – GrumpyCrouton
      Apr 3 at 17:41


















    2














    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.






    share|improve this answer






























      2














      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.






      share|improve this answer























      • 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
        2 days ago



















      2














      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.






      share|improve this answer

























      • This is already covered by the more generic password manager answer. Please do not post ads for specific products.

        – schroeder
        2 days ago


















      2














      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.






      share|improve this answer

























      • @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
        2 days ago











      • @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
        2 days ago


















      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.






      share|improve this answer

























      • this is covered in the comments to the question

        – schroeder
        2 days ago


















      1














      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.






      share|improve this answer






























        1














        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.






        share|improve this answer




















        • 1





          Why do this when you can just use PGP, which is actually intended for things like this?

          – Ave
          2 days ago


















        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.






        share|improve this answer























        • This does not answer the question

          – schroeder
          2 days ago











        • @schroeder, could you elaborate?

          – n0rd
          2 days ago











        • 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
          2 days ago











        • 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
          2 days ago












        • 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
          2 days ago


















        0














        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 >






        share|improve this answer























        • already covered by other answers

          – schroeder
          2 days ago









        protected by Rory Alsop Apr 4 at 10:40



        Thank you for your interest in this question.
        Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



        Would you like to answer one of these unanswered questions instead?














        16 Answers
        16






        active

        oldest

        votes








        16 Answers
        16






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        58














        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.






        share|improve this answer




















        • 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 3 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 4 at 2:25







        • 1





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

          – SEJPM
          Apr 4 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.

          – Todd Wilcox
          Apr 4 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.

          – Mike Waters
          Apr 4 at 18:58















        58














        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.






        share|improve this answer




















        • 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 3 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 4 at 2:25







        • 1





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

          – SEJPM
          Apr 4 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.

          – Todd Wilcox
          Apr 4 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.

          – Mike Waters
          Apr 4 at 18:58













        58












        58








        58







        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.






        share|improve this answer















        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Apr 3 at 11:19

























        answered Apr 3 at 11:13









        PhilippPhilipp

        45.2k8116142




        45.2k8116142







        • 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 3 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 4 at 2:25







        • 1





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

          – SEJPM
          Apr 4 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.

          – Todd Wilcox
          Apr 4 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.

          – Mike Waters
          Apr 4 at 18:58












        • 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 3 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 4 at 2:25







        • 1





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

          – SEJPM
          Apr 4 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.

          – Todd Wilcox
          Apr 4 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.

          – Mike Waters
          Apr 4 at 18:58







        11




        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 3 at 16:15





        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 3 at 16:15




        8




        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 4 at 2:25






        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 4 at 2:25





        1




        1





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

        – SEJPM
        Apr 4 at 8:41





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

        – SEJPM
        Apr 4 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.

        – Todd Wilcox
        Apr 4 at 13:09





        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 4 at 13:09




        1




        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 4 at 18:58





        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 4 at 18:58













        65














        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.






        share|improve this answer










        New contributor




        Kent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.















        • 8





          This is a much stronger answer, thanks

          – schroeder
          Apr 3 at 12:35






        • 14





          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 3 at 12:58











        • For completeness, I see Dashlane also widely used for access sharing with or without password disclosure (with possible access revocation).

          – zakinster
          Apr 4 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=[######] )

          – HopelessN00b
          Apr 5 at 1:36















        65














        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.






        share|improve this answer










        New contributor




        Kent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.















        • 8





          This is a much stronger answer, thanks

          – schroeder
          Apr 3 at 12:35






        • 14





          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 3 at 12:58











        • For completeness, I see Dashlane also widely used for access sharing with or without password disclosure (with possible access revocation).

          – zakinster
          Apr 4 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=[######] )

          – HopelessN00b
          Apr 5 at 1:36













        65












        65








        65







        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.






        share|improve this answer










        New contributor




        Kent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.










        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.







        share|improve this answer










        New contributor




        Kent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        share|improve this answer



        share|improve this answer








        edited Apr 4 at 15:50









        DysphoricUnicorn

        1032




        1032






        New contributor




        Kent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        answered Apr 3 at 12:04









        KentKent

        56714




        56714




        New contributor




        Kent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.





        New contributor





        Kent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






        Kent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.







        • 8





          This is a much stronger answer, thanks

          – schroeder
          Apr 3 at 12:35






        • 14





          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 3 at 12:58











        • For completeness, I see Dashlane also widely used for access sharing with or without password disclosure (with possible access revocation).

          – zakinster
          Apr 4 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=[######] )

          – HopelessN00b
          Apr 5 at 1:36












        • 8





          This is a much stronger answer, thanks

          – schroeder
          Apr 3 at 12:35






        • 14





          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 3 at 12:58











        • For completeness, I see Dashlane also widely used for access sharing with or without password disclosure (with possible access revocation).

          – zakinster
          Apr 4 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=[######] )

          – HopelessN00b
          Apr 5 at 1:36







        8




        8





        This is a much stronger answer, thanks

        – schroeder
        Apr 3 at 12:35





        This is a much stronger answer, thanks

        – schroeder
        Apr 3 at 12:35




        14




        14





        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 3 at 12:58





        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 3 at 12:58













        For completeness, I see Dashlane also widely used for access sharing with or without password disclosure (with possible access revocation).

        – zakinster
        Apr 4 at 9:20






        For completeness, I see Dashlane also widely used for access sharing with or without password disclosure (with possible access revocation).

        – zakinster
        Apr 4 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=[######] )

        – HopelessN00b
        Apr 5 at 1:36





        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 5 at 1:36











        23














        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.






        share|improve this answer




















        • 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 3 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 3 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
          Apr 3 at 18:49







        • 3





          Signal is probably the most secure way to send a message to someone's phone -- assuming both sides have Signal installed.

          – jcollum
          Apr 3 at 20:39















        23














        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.






        share|improve this answer




















        • 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 3 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 3 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
          Apr 3 at 18:49







        • 3





          Signal is probably the most secure way to send a message to someone's phone -- assuming both sides have Signal installed.

          – jcollum
          Apr 3 at 20:39













        23












        23








        23







        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.






        share|improve this answer















        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Apr 3 at 18:56

























        answered Apr 3 at 11:20









        PeterisPeteris

        6,63611828




        6,63611828







        • 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 3 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 3 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
          Apr 3 at 18:49







        • 3





          Signal is probably the most secure way to send a message to someone's phone -- assuming both sides have Signal installed.

          – jcollum
          Apr 3 at 20:39












        • 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 3 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 3 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
          Apr 3 at 18:49







        • 3





          Signal is probably the most secure way to send a message to someone's phone -- assuming both sides have Signal installed.

          – jcollum
          Apr 3 at 20:39







        3




        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 3 at 13:11





        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 3 at 13:11




        2




        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 3 at 14:38





        @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 3 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
        Apr 3 at 18:49






        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
        Apr 3 at 18:49





        3




        3





        Signal is probably the most secure way to send a message to someone's phone -- assuming both sides have Signal installed.

        – jcollum
        Apr 3 at 20:39





        Signal is probably the most secure way to send a message to someone's phone -- assuming both sides have Signal installed.

        – jcollum
        Apr 3 at 20:39











        6














        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.







        share|improve this answer


















        • 2





          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 4 at 6:51
















        6














        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.







        share|improve this answer


















        • 2





          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 4 at 6:51














        6












        6








        6







        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.







        share|improve this answer













        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.








        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Apr 3 at 14:32









        user137369user137369

        37338




        37338







        • 2





          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 4 at 6:51













        • 2





          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 4 at 6:51








        2




        2





        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 4 at 6:51






        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 4 at 6:51












        4














        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.






        share|improve this answer



























          4














          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.






          share|improve this answer

























            4












            4








            4







            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.






            share|improve this answer













            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Apr 3 at 11:20









            llmorallmora

            1663




            1663





















                3














                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.






                share|improve this answer

























                • 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 3 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 3 at 18:05






                • 2





                  @s1lv3r check this answer, he actually did it. And this one too

                  – AccountantM
                  Apr 3 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.

                  – Xiong Chiamiov
                  2 days ago











                • @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
                  2 days ago















                3














                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.






                share|improve this answer

























                • 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 3 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 3 at 18:05






                • 2





                  @s1lv3r check this answer, he actually did it. And this one too

                  – AccountantM
                  Apr 3 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.

                  – Xiong Chiamiov
                  2 days ago











                • @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
                  2 days ago













                3












                3








                3







                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.






                share|improve this answer















                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.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Apr 4 at 12:27

























                answered Apr 3 at 15:40









                AccountantMAccountantM

                20616




                20616












                • 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 3 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 3 at 18:05






                • 2





                  @s1lv3r check this answer, he actually did it. And this one too

                  – AccountantM
                  Apr 3 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.

                  – Xiong Chiamiov
                  2 days ago











                • @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
                  2 days ago

















                • 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 3 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 3 at 18:05






                • 2





                  @s1lv3r check this answer, he actually did it. And this one too

                  – AccountantM
                  Apr 3 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.

                  – Xiong Chiamiov
                  2 days ago











                • @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
                  2 days ago
















                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 3 at 17:59






                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 3 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 3 at 18:05





                @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 3 at 18:05




                2




                2





                @s1lv3r check this answer, he actually did it. And this one too

                – AccountantM
                Apr 3 at 18:07






                @s1lv3r check this answer, he actually did it. And this one too

                – AccountantM
                Apr 3 at 18:07





                1




                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.

                – Xiong Chiamiov
                2 days ago





                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
                2 days ago













                @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
                2 days ago





                @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
                2 days ago











                2














                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






                share|improve this answer










                New contributor




                GrumpyCrouton is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.




















                • 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 3 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 3 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 3 at 16:34






                • 2





                  @Accountant Good idea, I'll definitely consider adding that.

                  – GrumpyCrouton
                  Apr 3 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.

                  – GrumpyCrouton
                  Apr 3 at 17:41















                2














                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






                share|improve this answer










                New contributor




                GrumpyCrouton is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.




















                • 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 3 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 3 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 3 at 16:34






                • 2





                  @Accountant Good idea, I'll definitely consider adding that.

                  – GrumpyCrouton
                  Apr 3 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.

                  – GrumpyCrouton
                  Apr 3 at 17:41













                2












                2








                2







                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






                share|improve this answer










                New contributor




                GrumpyCrouton is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.










                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







                share|improve this answer










                New contributor




                GrumpyCrouton is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                share|improve this answer



                share|improve this answer








                edited Apr 3 at 17:49





















                New contributor




                GrumpyCrouton is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                answered Apr 3 at 16:08









                GrumpyCroutonGrumpyCrouton

                1213




                1213




                New contributor




                GrumpyCrouton is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.





                New contributor





                GrumpyCrouton is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.






                GrumpyCrouton is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.












                • 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 3 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 3 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 3 at 16:34






                • 2





                  @Accountant Good idea, I'll definitely consider adding that.

                  – GrumpyCrouton
                  Apr 3 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.

                  – GrumpyCrouton
                  Apr 3 at 17:41

















                • 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 3 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 3 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 3 at 16:34






                • 2





                  @Accountant Good idea, I'll definitely consider adding that.

                  – GrumpyCrouton
                  Apr 3 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.

                  – GrumpyCrouton
                  Apr 3 at 17:41
















                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 3 at 16:18





                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 3 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 3 at 16:29






                @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 3 at 16:29





                2




                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 3 at 16:34





                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 3 at 16:34




                2




                2





                @Accountant Good idea, I'll definitely consider adding that.

                – GrumpyCrouton
                Apr 3 at 16:35





                @Accountant Good idea, I'll definitely consider adding that.

                – GrumpyCrouton
                Apr 3 at 16:35




                1




                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 3 at 17:41





                @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 3 at 17:41











                2














                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.






                share|improve this answer



























                  2














                  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.






                  share|improve this answer

























                    2












                    2








                    2







                    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.






                    share|improve this answer













                    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.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Apr 3 at 19:07









                    PerkinsPerkins

                    1894




                    1894





















                        2














                        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.






                        share|improve this answer























                        • 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
                          2 days ago
















                        2














                        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.






                        share|improve this answer























                        • 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
                          2 days ago














                        2












                        2








                        2







                        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.






                        share|improve this answer













                        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.







                        share|improve this answer












                        share|improve this answer



                        share|improve this answer










                        answered Apr 4 at 12:54









                        AdonalsiumAdonalsium

                        3,3911720




                        3,3911720












                        • 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
                          2 days ago


















                        • 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
                          2 days ago

















                        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
                        2 days ago






                        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
                        2 days ago












                        2














                        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.






                        share|improve this answer

























                        • This is already covered by the more generic password manager answer. Please do not post ads for specific products.

                          – schroeder
                          2 days ago















                        2














                        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.






                        share|improve this answer

























                        • This is already covered by the more generic password manager answer. Please do not post ads for specific products.

                          – schroeder
                          2 days ago













                        2












                        2








                        2







                        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.






                        share|improve this answer















                        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.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited 2 days ago









                        user02814

                        1032




                        1032










                        answered Apr 3 at 20:13









                        borjabborjab

                        33918




                        33918












                        • This is already covered by the more generic password manager answer. Please do not post ads for specific products.

                          – schroeder
                          2 days ago

















                        • This is already covered by the more generic password manager answer. Please do not post ads for specific products.

                          – schroeder
                          2 days ago
















                        This is already covered by the more generic password manager answer. Please do not post ads for specific products.

                        – schroeder
                        2 days ago





                        This is already covered by the more generic password manager answer. Please do not post ads for specific products.

                        – schroeder
                        2 days ago











                        2














                        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.






                        share|improve this answer

























                        • @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
                          2 days ago











                        • @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
                          2 days ago















                        2














                        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.






                        share|improve this answer

























                        • @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
                          2 days ago











                        • @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
                          2 days ago













                        2












                        2








                        2







                        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.






                        share|improve this answer















                        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.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited 2 days ago









                        peterh

                        2,11732030




                        2,11732030










                        answered Apr 3 at 21:20









                        ChloeChloe

                        9082923




                        9082923












                        • @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
                          2 days ago











                        • @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
                          2 days ago

















                        • @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
                          2 days ago











                        • @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
                          2 days ago
















                        @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
                        2 days ago





                        @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
                        2 days ago













                        @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
                        2 days ago





                        @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
                        2 days ago











                        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.






                        share|improve this answer

























                        • this is covered in the comments to the question

                          – schroeder
                          2 days ago















                        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.






                        share|improve this answer

























                        • this is covered in the comments to the question

                          – schroeder
                          2 days ago













                        1












                        1








                        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.






                        share|improve this answer















                        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.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Apr 3 at 16:57

























                        answered Apr 3 at 15:33









                        WoJWoJ

                        7,21312544




                        7,21312544












                        • this is covered in the comments to the question

                          – schroeder
                          2 days ago

















                        • this is covered in the comments to the question

                          – schroeder
                          2 days ago
















                        this is covered in the comments to the question

                        – schroeder
                        2 days ago





                        this is covered in the comments to the question

                        – schroeder
                        2 days ago











                        1














                        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.






                        share|improve this answer



























                          1














                          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.






                          share|improve this answer

























                            1












                            1








                            1







                            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.






                            share|improve this answer













                            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.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Apr 3 at 21:03









                            Douglas HeldDouglas Held

                            21816




                            21816





















                                1














                                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.






                                share|improve this answer




















                                • 1





                                  Why do this when you can just use PGP, which is actually intended for things like this?

                                  – Ave
                                  2 days ago















                                1














                                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.






                                share|improve this answer




















                                • 1





                                  Why do this when you can just use PGP, which is actually intended for things like this?

                                  – Ave
                                  2 days ago













                                1












                                1








                                1







                                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.






                                share|improve this answer















                                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.







                                share|improve this answer














                                share|improve this answer



                                share|improve this answer








                                edited Apr 4 at 5:37

























                                answered Apr 4 at 5:31









                                bremen_mattbremen_matt

                                1113




                                1113







                                • 1





                                  Why do this when you can just use PGP, which is actually intended for things like this?

                                  – Ave
                                  2 days ago












                                • 1





                                  Why do this when you can just use PGP, which is actually intended for things like this?

                                  – Ave
                                  2 days ago







                                1




                                1





                                Why do this when you can just use PGP, which is actually intended for things like this?

                                – Ave
                                2 days ago





                                Why do this when you can just use PGP, which is actually intended for things like this?

                                – Ave
                                2 days ago











                                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.






                                share|improve this answer























                                • This does not answer the question

                                  – schroeder
                                  2 days ago











                                • @schroeder, could you elaborate?

                                  – n0rd
                                  2 days ago











                                • 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
                                  2 days ago











                                • 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
                                  2 days ago












                                • 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
                                  2 days ago















                                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.






                                share|improve this answer























                                • This does not answer the question

                                  – schroeder
                                  2 days ago











                                • @schroeder, could you elaborate?

                                  – n0rd
                                  2 days ago











                                • 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
                                  2 days ago











                                • 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
                                  2 days ago












                                • 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
                                  2 days ago













                                0












                                0








                                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.






                                share|improve this answer













                                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.







                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                answered Apr 4 at 4:46









                                n0rdn0rd

                                1094




                                1094












                                • This does not answer the question

                                  – schroeder
                                  2 days ago











                                • @schroeder, could you elaborate?

                                  – n0rd
                                  2 days ago











                                • 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
                                  2 days ago











                                • 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
                                  2 days ago












                                • 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
                                  2 days ago

















                                • This does not answer the question

                                  – schroeder
                                  2 days ago











                                • @schroeder, could you elaborate?

                                  – n0rd
                                  2 days ago











                                • 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
                                  2 days ago











                                • 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
                                  2 days ago












                                • 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
                                  2 days ago
















                                This does not answer the question

                                – schroeder
                                2 days ago





                                This does not answer the question

                                – schroeder
                                2 days ago













                                @schroeder, could you elaborate?

                                – n0rd
                                2 days ago





                                @schroeder, could you elaborate?

                                – n0rd
                                2 days ago













                                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
                                2 days ago





                                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
                                2 days ago













                                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
                                2 days ago






                                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
                                2 days ago














                                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
                                2 days ago





                                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
                                2 days ago











                                0














                                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 >






                                share|improve this answer























                                • already covered by other answers

                                  – schroeder
                                  2 days ago















                                0














                                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 >






                                share|improve this answer























                                • already covered by other answers

                                  – schroeder
                                  2 days ago













                                0












                                0








                                0







                                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 >






                                share|improve this answer













                                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 >







                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                answered 2 days ago









                                iBugSeciBugSec

                                761510




                                761510












                                • already covered by other answers

                                  – schroeder
                                  2 days ago

















                                • already covered by other answers

                                  – schroeder
                                  2 days ago
















                                already covered by other answers

                                – schroeder
                                2 days ago





                                already covered by other answers

                                – schroeder
                                2 days ago





                                protected by Rory Alsop Apr 4 at 10:40



                                Thank you for your interest in this question.
                                Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                                Would you like to answer one of these unanswered questions instead?



                                Popular posts from this blog

                                Tamil (spriik) Luke uk diar | Nawigatjuun

                                Align equal signs while including text over equalitiesAMS align: left aligned text/math plus multicolumn alignmentMultiple alignmentsAligning equations in multiple placesNumbering and aligning an equation with multiple columnsHow to align one equation with another multline equationUsing \ in environments inside the begintabularxNumber equations and preserving alignment of equal signsHow can I align equations to the left and to the right?Double equation alignment problem within align enviromentAligned within align: Why are they right-aligned?

                                Training a classifier when some of the features are unknownWhy does Gradient Boosting regression predict negative values when there are no negative y-values in my training set?How to improve an existing (trained) classifier?What is effect when I set up some self defined predisctor variables?Why Matlab neural network classification returns decimal values on prediction dataset?Fitting and transforming text data in training, testing, and validation setsHow to quantify the performance of the classifier (multi-class SVM) using the test data?How do I control for some patients providing multiple samples in my training data?Training and Test setTraining a convolutional neural network for image denoising in MatlabShouldn't an autoencoder with #(neurons in hidden layer) = #(neurons in input layer) be “perfect”?