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.
Good point. I was thinking in a general "they have access to the
system" vein. However, if the user just has regular privileges, all
it permits is access to an empty account. On the other hand, they
could steal mail services for abuse.
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."
Good idea. As we both know, that depends on getting such info in the
first place.
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.
Right. I imagine that will come up at some point.
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, ...
Ok, I've always wondered about this... I would love to set the
"change password on next login" option on every new account. However,
it always ends up screwing my clients. Their application will hit the
server, make an authentication attempt and change the password to
something unknown by both of us. They essentially become locked out.
Other than AFP, how can clients (in particular, Linux and Windows)
change their password on initial login? I know there are third party
user management web apps out there, but that's about all I know.
You have no way of knowing how many parties an email message may be
relayed through.
... and how many government agencies it hits along the way =)
Well then you'd still need to secure the initial configuration info
for that too ;)
Yeah, there's a chicken and there's an egg.
The answer is you use encryption or at least obfuscation.
That must be the ticket. A lot of folks are suggesting it.
There's two issues here to consider:
1) Securing the password
2) verifying the integrity of the parties
Right.
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.)
That would screw any handicap customers though. Visual things are
kind of unfair to them. If it's text based, at least a screen reader
can deal with it.
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.
I remember looking at PGP when it first made the rounds. It seems to
have gone through some changes though. Also, it's not as prevalent as
I had expected. Back then, it seemed to just a matter of time before
it was ubiquitous. (Coincidentally, I happen to be re-reading "Crypto
Anarchy,..." this week. Man, lots of hyperbole =) PGP seems like a
good thing to re-explore.
Jaime
_______________________________________________
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
