I often create logins for new employees and then send them an email with their login credentials. While doing so I also CC their manager to let him know his user has been setup.
Is this the right thing to do? Should the manager be CC'd when sending a username and password to the user?
In this case, the employes are part of an operation team who basically process paperwork and things in the database. They do not do anything confidential as such, but of course are responsible for what they do.
You should inform the manager that the credentials were created.
You should not send said credentials to the manager - in particular, if you have an audit trail that involves users, how can you be certain that when such a user is flagged by the system it is indeed the user and not their manager?
The whole point of login credentials is to ensure a logged in user is who they say they are (authentication), in order to give them access to whatever they need (authorization) and in some cases to allow for an audit trail.
Giving their credentials to someone else completely subverts this.
Sure, go ahead - as long as the user is required to change the password upon first login. They are, right? I mean, the goal here is to get the employee their credentials, and prove you've done so / get them to someone with a vested interest in assisting that new employee, while maintaining security.
This way you get all that, plus the user has to change their password "on first login" or whatever it's called now, so nothing is compromised.
I've seen systems that handle password changes this way too - forget your password, they email a new (temporary) one to your direct manager.
You can send two emails for this. This is what is followed in our company and the managers never have a problem with it.
To: Employee
Cc: Manager1, Manager2
Dear Employee,
You have been registered in the system. Your username is firstname.lastname.
To adhere to the company's security policies, the password will be sent in the next e-mail marked only to you.
Regards, IT Team
To: Employee
Dear Employee,
The password to the username firstname.lastname is mynewpassword. We request you to change it immediately.
Regards, IT Team
While it's appropriate to send a password via email, that password must be temporary; upon first login, the system must force a password change. Most enterprise-grade products support this option.
The problem is that credentials should not be stored anywhere in the open -- email least of all, since that's the first place attackers will look. Sending the password in a separate email doesn't really help, since a hacker who gets into your email will be able to see both messages, so you're no safer that way. Also, you may be required by a manager or anyone else for that matter to copy them on emails like this, significantly increasing your attack surface and the likelihood of an attacker getting the password.
The best solution is to simply force the user to change his password. Do not request that that the user change his password, since he never will. There are thousands of accounts out there with the password 12345 which was assigned as a temporary password and which the user was requested to change... and which he never did change.
NO! it is not - this is security and sysadmin 101.
Also you do not ever send the user name and password in the clear, in the same document. Best practice is to create a temp password and communicate this to the employee via some other method and have the user change the password on login.
No, the password should not even be in the email in the first place. At my place of work, one tells the login ID to a user and requests the user to call IT to obtain a temporary password.
There are some other security considerations to think about.
If your company has the robust technology to support it, passwords should be hashed using a strong algorithm such as bcrypt. Insecure protocols such as MD5 and SHA 1 should never be used.
The email itself should be sent encrypted.
Avoid using SSL and early version TLS as the encryption method as these are longer considered secure. AES can be used to encrypt symmetrically or a algorithm like RSA can be used to encrypt asymmetrically (2 keys). When encrypting, choose a long key length to maximize security as the security of the key is directly correlated with its character length.
Secure emails with sensitive information should be digitally signed so that the recipient can verify the authenticity of the sender and to ensure non - repudiation by the sender.
A one way hash function such as HMAC-SHA 256 is applied to transform email into a cryptographic message digest. Do not sign using the SHA 1 algorithm as such algorithm has been cryptographically broken and is no longer secure as a result. Using PKI, a private key only you know is used to encrypt. Once the receiver uses your public key to decrypt, the resulting message hash should be the same. The public key is protected from tampering by a certificate that binds the identity of the owner with his / her public key. The certificate is obtained via a CA upon validating the credentials you supplied in your certificate request.
Otherwise, message integrity is lost and the received message cannot be trusted to be the message you sent.
The private key is known only to the sender and is associated with a unique public key known to the receiver of the email. By the fact that the receiver is able to use the public key associated with the sender of the email to decrypt the email message, means that the sender cannot deny having sent the message>>
Point 2 ensures that the Confidentiality of the email is not compromised. Confidentiality means no unauthorized disclosure occurred such as through MITM.
Point 3 ensures integrity and non - repudiation or that the contents of the email has not been altered by an unauthorized party, and that sender of the email cannot deny having sent the email, due to the presence of his or her public key used to decrypt the message by the receiver of the email.
Finally, you can mask the data when displayed for extra security.
If you're asking this, then you're in IT. ask your boss what company policy is. That's the safest path. Otherwise, I'd be inclined to say no, do not give managers the credentials.
However, ALWAYS let the manager know that a logon has been created for their underling. If they then request the credentials, ask them to submit that via your boss, so that it goes through proper channels.
I deal with this regularly.
This is my best solution so far:
Obviously this may not work if your organization is so large that you have multiple campuses, but this method:
Obviously this works well in a single-building environment, but it does work very well for me. It also lets my front-line techs handle things easily, as I just give them the script (C# Console App that asks for user's first/last name, and pick employee role).
Hope it helps you.
If you are located near the new employees you can have them pickup a hard copy of the login information. You will just need to let the manager know that it is ready.
If there is a great distance between you and the employees, you will have to email the manger the credentials. This is to let them give the credentials to the new employee.
I worked for a place that tried to tell you to pickup the passwords by leaving a voice mail. They also sent you an email to tell you your voice mail was now enabled. Needless to say that method didn't work very well for new employees.
I also sent credentials to a manger once because the employee wouldn't try to login. They told their manager they never got them. After 4 or 5 cycles of creating a new temporary password and sending it out, they miraculously arrived after I also sent them to the manager.
A solution I've used, but didn't see suggested: Send the new user an email letting them know their account has been set up. If cc'ing their manager seems appropriate or necessary, then do so. However, you send them your telephone number and have them call (or visit) you to get their credentials. Or, you might send them their login id in this email; however, do not send the password via email.
Imagine some criminal damage is done, with incontrovertible evidence that it was done by someone having that person's username and password. Now you have a problem. There are two people, and you are quite sure that one is a criminal and one is quite innocent. Your company has a big problem. In Europe you have a huge problem because you know someone caused criminal damage and you can't fire them. In the USA, you still have a huge problem because there are two persons that you could fire, but one of them is totally innocent and you would lose what is likely a good employee. In addition, the employee and the manager know this, so it's likely the damage wouldn't have been done if only one person knew the password.
Nobody but that user must know the password. IT may have means to reset the password, and may be able to get into the computer after resetting the password, but they also must not know the current password and must not be able to change the password, cause damage from that user's account, and change the password back.
