Title: Re: securely getting passwords to remote
users
At 11:15 PM -0400 6/5/06, Jaime Magiera wrote:
Hello,
This is a general admin type question, but the brains around here are
ripe for pickin'...
More and more, my clients are folks whom
I've never met. For example, I've just closed a deal with a consulting
firm in South Africa. Way cool. However, I'm realizing that the old
"send password via email" approach is not really very
secure.
It's not the "sending" that's insecure, it's the nature
of the message that's possibly insecure.
These are just temp passwords which
the user will change.
If the account is new, and there's no security concerns about
data they might read from outside the files in their account, since
their account is empty there is no risk from this practice. Presuming
someone did have their initial password, and did log in and change it
to something, they'd have had no access to sensitive info other than
what the man in the middle might have created themselves. It is theft
of service, but theirs no security risk to data. It's also painfully
obvious as the real user can't log in. It also indicates a breach in
the channel.
You can stop the man in the middle by not sending the initial
password but using a combo of something known and something shared by
both parties already. This could be the user's employee ID number, or
birthdate, or SSN, or ...
"Your initial password is your name plus ____________, and
you will be required to change it on your first login."
However if the account permits access to sensitive information on
the host, or access to sensitive user files in the account then this
practice is wholly unacceptable.
Also, the user must have a mechanism that supports the mandatory
change policy. While that includes AFP, it doesn't work for SMB, FTP,
ssh, mail, ...
However, when the email is going to their
previous/other ISP, I don't know if there is a break in security along
the way.
You have no way of knowing how many parties an email message may
be relayed through.
What are some of the methods that admins
are using to securely get passwords and login info to new remote
system/email users?
Obviously, phone would be one
way.
And is just as insecure. How do you know you're speaking to the
right party? You give the password to his rival cow-orker[sic] and now
Bob is rummaging through Alice the accountant's sensitive files.
Any techniques on the network
side?
Well then you'd still need to secure the initial configuration
info for that too ;)
The answer is you use encryption or at least obfuscation.
There's two issues here to consider:
1) Securing the password
2) verifying the integrity of the parties
In terms of obfuscation, there's the classic ROT13. It's easy to
notice and decode. It's value is to simply obscure so that it's not as
noticeable in messages but provides little real protection.
For example:
Username: Bob
Password: 12345678
becomes:
Hfreanzr: Obo
Cnffjbeq: 12345678
Note the problem with digits ;)
There's also stenegraphy and transpositions. Programs like
Sapphire allow you to "hide" text in a graphic file. Think
Jihadis with secret messages hidden in their porn (a well used
technique.)
Transpositions are common cipher techniques. Both parties need to
understand it from the start and agree on the transposition. For
instance adding 3 to the value of each letter or digit. Hence
"ABC" becomes "DEF". Another technique is the
"keyboard shift" where "this text" becomes
"yjod yrcy". Such methods are easy to explain, but must be
explained in advance. So any parties monitoring the communications
channel who may intercept the "here's your initial password,
encoded" message will probably also get the "the encoding
we're using to obfuscate your password is xyz" message.
Private / Public key encryption techniques solve the problem
nicely. DHA and RSA are commonly deployed. Examples here are Pretty
Good Privacy and GnuGP.
So the best method is generally to use GPG or PGP. With it you
can both digitally sign the message (so the recipient can verify that
it indeed came from you) and it's encrypted so only the recipient can
decode it. This solves all the problems.
Implementation is relatively easy. Both sender and recipient
install GPG or PGP and generate their own private key and public key.
You publish your private key at one of the canonical sites that
provide lookup services so anyone can grab it. Or you can exchange it
in the clear by email.
For example:
Username: Bob
Password: 12345678
becomes (encoded so that ONLY email@hidden can read
it):
Using the above signature you should be able to verify that I
wrote this but looking up my public key (available online at the
canonical spots) and verifying the text against the signature. (The
same sort of signatures are used to sign Software Updates, etc.)
See:
http://macgpg.sf.net/
http://www.gnupg.org/
--
-dhan
------------------------------------------------------------------------
Dan
Shoop AIM: iWiring
Systems & Networks
Architect
http://www.ustsvs.com/
email@hidden
http://www.iwiring.net/
1-714-363-1174
iWiring provides systems and networks support for Mac OS X, unix,
and
Open Source application technologies at affordable rates.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
This email sent to email@hidden
