3

When I need to send a password to someone, I usually send all the info except the password (i.e. server and user) through a certain channel (email, IM, etc.) and the password itself (with no explanation of what it's for) by text message.

Is this acceptable or is there a better method?

Improve this question
4
  • Text message, as in SMS over mobile networks, that isn't guaranteed?
    – user3914
    Feb 17, 2011 at 6:43
  • 2
    @Randolph - it's 'good enough' most of the time in a real world sense, but neither SMS or email are 'guaranteed' services in theory; both are best efforts. If a message absolutely positively must reach the recipient or else really bad things will happen, then I'd certainly be unhappy with using just one of the above methods.
    – Rob Moir
    Feb 17, 2011 at 7:17
  • A fair statement, Robert. And that's the complexity of the question, isn't it? Too many points of contact reduces the security of the thing.
    – user3914
    Feb 17, 2011 at 7:58
  • Absolutely - this is one of those problems that sounds easy but actually gets more and more complex with each bit of work you do to solve it!
    – Rob Moir
    Feb 17, 2011 at 8:29

6 Answers 6

Reset to default
3

The intended recipient may need to repeat the request if they don't get the message. However, you should consider that it's fairly common that people get email and IMs on their phones, so the communication may not be as separated as you might think. Considering that a request might be initiated from the phone as well, it's not all that secure.

Improve this answer
3

Whilst I share some of the concerns of other correspondents, I also note an argument of pragmatism.

I have to issue a lot of passwords to people in other countries. I don't know them; I have no means of contacting them face-to-face; I can't engage a courier to hand-deliver a password each time; and the delays of postal mail (which also is by no means a guaranteed person-to-person service) are considered business-unacceptable.

So what's a sysadmin to do? I have to get passwords to people somehow, or noone will ever be able to log in.

So for some time I've done as you do. I require a GSM phone number for each validated new password (or change) request, and I SMS the password to that number; username, system addresses etc. all go through email from the ticketing system they've used to log the request. The only wrinkle I've added is to pre-expire the password, which requires it to be changed on first login. On Linux, I do this with chage -d 0 username after setting the password, and on Solaris with passwd -f username.

This means that the token isn't infinitely reusable if it's disclosed; a black hat coming across the discarded text message will only know what the password used to be. It also means that if someone else gets it first, I'll find out about it, because the legitimate user won't be able to log in after the black hat has got there and changed it first.

It's still not perfect, and there are still ways it can fail, but I have yet to find anything better. Anyone?

Improve this answer
3

I think you might be surprised at just how common this practice is and realistically it's quite acceptable for a lot of cases. However, as you obviously already suspect, it's far from ideal.

Ideally the communication should be encrypted using some form of pre-shared secret but of course the very sharing of that secret presents problems. PGP/GPG is a great solution to the problem. This used to be quite common practice but as far as I can tell is not used much these days, although I can't understand why not. Last time I checked GPG was freely available for all major platforms.

Improve this answer
9
  • John, in addition to the training problem with pgp/gpg is the issue of authenticating the identity of a person you don't know. In many cases for me, the other person is an operator in the Philippines. They know their manager, who knows some high-level manager who flies around a lot, who knows my service delivery guy, who knows me, so a web of trust could be established; but do I trust all those intermediate persons to correctly understand what it means, by way of correctly authenticating someone, to sign someone else's key? Frankly, no.
    – MadHatter
    Feb 17, 2011 at 11:21
  • That doesn't mean i don't use gpg. I love it, and for communicating securely with people I know face-to-face, and whose keys I have verified, it's indispensable. Every time I take on a new client, I find someone at that site who has clue, make them generate a keypair if they don't already have one, and we exchange keys then and there, so if I ever need to send them a root password, or authenticate a request for some secure access token, my channels are in place. For that sort of password exchange, gpg is king; it's the issue above where it doesn't work so well, for me.
    – MadHatter
    Feb 17, 2011 at 11:25
  • @MadHatter, if you perceive a "training problem" for PGP?GPG then perhaps those people shouldn't be allowed to log onto a computer. I've never known anyone, including senior managers, who couldn't use it within a few minutes. The web of trust issue is overstated and has a gazillion solutions.
    – John Gardeniers
    Feb 17, 2011 at 11:32
  • John, fair point! It's not the UI, which I agree can be made comprehensible with a few minutes of direction. It's the understanding of cryptographic protocols, the nature of Man-In-The-Middle attacks, what it means to sign another's key, and what precautions should be taken before so doing, that I have never been able to convince myself that irregular crypto users - such as those in the middle of the chain in my example above, who only need to sign keys, and infrequently at that - really understand.
    – MadHatter
    Feb 17, 2011 at 12:00
  • @MadHatter, this is no different to secure on-line transactions. Normal users neither know nor care about the technologies or potential vulnerabilities.
    – John Gardeniers
    Feb 17, 2011 at 20:28
2

You should have a way to be sure that your correspondent is the only one who knows the password:

  • the text message arrives to the right person
  • the text message was not read by anybody else, during and after the transmission. Suppose that your correspondent has put the text message on the back of his keyboard after receiving it
  • your correspondent (and nobody else) has changed the password. If the password was not changed, there are at least two persons who know the password: you and your correspondent.

You also need a way to know if one of the previous points did not happen and in that case, a way to deactivate the access to the protected resource.

If it is acceptable or not, it depends on the resource you would like to protect. If you just would like to protect the photos of you last holiday and you just matter that they are not freely visible by search engines on the Internet but require a password to access it, it is probably less important than an access to confidential documents of your company.

Improve this answer
2

An asymmetric encryption (e.g. RSA) is probably the safest way.

Your friend sends you the public key that you will use for password encryption. Then, your friend uses the private key to decrypt it.

I've encountered this pain and decided to build a simple tool to solve this pain: http://tanin.nanakorn.com/labs/secureMessage

It uses Javascript to do RSA encryption. Therefore, your password never leaves your or your friend's machine. Also, the keys are destroyed when you leave the page.

One caveat is that, if you leave the page, you'll lose your private key... so this tool might be better for sending password over IM (not email)

Improve this answer
0

Might want to consider some form of 2-factor auth. The identity validation replies earlier totally make sense and are valid concerns.

Another option I do sometimes is taking a picture of a written password, can use MMS or anything else. It isn't as easy to "detect" in case of rootkits/malware you may be trying to avoid.

Improve this answer

You must log in to answer this question.

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