Communicating secure details - how do you do it?

M

murraybiscuit

Executive Member
Joined
Oct 10, 2008
Messages
6,483
Reaction score
55
Location
Dubai
I generally can't stand sending usernames and passwords over email and avoid it at all costs. But from time to time, I have companies and clients send me emails with everything from ftp details, to cms admin logins, to root server pem's. WTF. Or I get forwarded an email that's gone back and forth ten times with u&p in the body somewhere down below. Now I would like to avoid this. But I'd also like to have a better solution. Generally I try to send a username via email and a pass via sms if it has to go electronically. Or in a google doc shared with the recipient. Is there not some better way in this modern day and age that we can transmit details? I know lastpass shares logins securely, but it requires an account on both sides.

What do you guys do? Clearly I'm not talking about super-sensitive state-secret DMZ-side stuff. If I really wanted to be secure, I wouldn't transmit anything electronically. I'm talking about run-of-the-mill web stuff here. Changing passwords after transmission is obviously good practice.
 
For a medium level of security I would suggest PGP. For more sensitive information you can use Truecrypt.
 
Why not just make use of a chat app like for example Wickr?

Tell your client to load it on his/her phone (both Android and iOS) and say that all passwords and the like will be send via the app. Maybe a bit of a 'slep' but at least you know its secure and you can set the message to expire so it gets delete from their phones automatically after a preset time from the time they read it.

https://www.mywickr.com/en/index.php

Edit: Wanted to add - Its simple [as they say on the site, a 3 year old can do it], everybody has a phone and know how to use it, its convenient and require no additional installing of software on both sides [except for the app off course], it makes use of a different channel than normal making it more secure.
 
Last edited:
Yours is a great question, OP, and one that should be more frequently asked. :D

This is a great blog post: "Everything you ever wanted to know about building a secure password reset feature". While it primarily focuses on password reset functionality, the principles are more widely applicable and should answer your questions.

Yes, it is a very good idea to use a separate communications channel to transmit sensitive information, but it has to be weighed against the user experience. Asking people to install an app on their phone to use your site will cost you a lot of potential users (myself being the first). Requiring them to install an app even more so. When it comes to relatively less sensitive data like user credentials (to a non-sensitive site), a time limited, single use link in an email is the better compromise. If, on the other hand, you are transferring confidential business documents, the disclosure of which could ruin you or your clients, I would recommend adding more layers: Password protected (sent via SMS/chat app) HTTPS download (from a properly configured HTTPS server) of an encrypted file (decryption passphrase relayed over the phone or in person), with the time bound, unique and random download link sent over PGP encrypted mail - multiple security mechanisms over multiple communication channels.

It should be quite clear that the latter is quite a hassle and not something that a user would put up with to register on a site.
 
I just send a passworded zip by email and the password for the zip by sms.
 
Wall said:
very clever solution!
Click to expand...

What else am I supposed to do with all these "free" sms's Vodacom keep giving me?

I apparently still have around 365 of the things I can use.
 
The email solution is quite a elegant one. I also like solutions where the password is a single use one and the user has to change the password at next login.
Of course you then end up with the classic error-between-user-and-laptop scenario.
'No. You can not write your new password on some tape and stick it to the top of your monitor.
...
Because then everyone can see it...
...
Put your manager on the phone.'

Or.
'You've forgotten your password again?
Its EdithF - same as your login.
Yes. I'm sure - I helped you to change it to that after the last time you forgot it.
Ok great. Bye.
sigh'
 
My company only uses cryptographic keys to log onto servers (now being replaced with a crypto USB thing).

Generally I think it is best to use that kind of thing. The user has his/her crypto key (.ssh/my_key.pem/pub) and the company that administrates it has their key. Setup scripting to automate crypto key rotation if you have a high churn rate (scp new key to .ssh using old key :p)

As for logins for servers, eh, crap one. I personally believe single sign on (OpenID for authentication + LDAP or just a simple ACL for authorization).

That isn't always possible tho, when that is the case I use something like LastPass.

LastPass allows you to share a username/password with other users. It links selected credentials with LastPass account and updates to it from your side reflects on their side. They cannot change or view the password (although technically they do have the password :p ).

LastPass is free and encrypts stuff on your local machine, then sends it to the LastPass servers for backup. It is free for all devices except mobile. Then you have to pay a yearly subscription. I don't use the mobile features but I still have a subscription. One of only 2 subscription services I have because I respect the effort they put into their product.

Last resort I guess would be PGP or similar but it becomes tedious for clients to use.

I kinda like push services. Amazon IAM Federation is a good example, you set usernames & passwords and they are pushed to your instances before it starts up, as soon as the instance starts you have your secrets on a mounted RAM drive. Apps don't have to worry about getting creds.
 
Last edited:
We use a combination of biometrics with one time pins and passwords to do various changes in our application.
 
Since this is in the development forum, I'll answer what we do.

We usually send a link with a one-time password to the user via sms when they click the link. It then logs them in automatically after entering the one-time pin (usually sent via SMS) and all they have to do is change their password. (much like semaphore does)

An alternative is that we also force a user to change their password when they first login. So when/if the password was transmitted via email the first time, when the user logs in, they need to choose a new password with strength/difficulty we choose. We have found that simply asking a user to change their password after their initial login means that 90% of them won't and will stay on the default password.
 
Put all the passwords etc in an Excel sheet.

Encrypted it. Plus password.

I now can email this Excel sheet, and SMS the password to this sheet.
 
Send a password setup link. Person clicks on a link, sets up password and thats that. No details transmitted via email.
 
ghoti said:
Send a password setup link. Person clicks on a link, sets up password and thats that. No details transmitted via email.
Click to expand...
That's what we do too. Problem is when someone else gains access to your client's email and then does the password reset request.

Maybe the password setup link can be combined with a one time pin via SMS. Not workable in our scenarios though. But I think that's the most secure solution.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X