One of my hosting providers is sending a new password in plain text per e-mail, on request.
How insecure is this practice?
What would be a good (more secure) alternative to this?
It's probably fine, as long as the user is prompted to login and change it immediately (and assuming it expires within hours if the user does nothing, forcing another reset cycle). A similar question is "Temporary passwords e-mailed out as plain text".
You're probably thinking of the much worse scenario whereby a system stores your passwords in plaintext, and then emails you your password if you forget it. There are a few questions dealing with why that is a bad process (and what you can do about it).
It's an interesting one, because you face two problems. You need to let someone know the password but:
Myself, I would plump for transmitting by plain text, but forcing a password change on first use, and if the situation needed it, I'd contact the client by another means to tell them the password would be with them shortly - cajole them into setting their own immediately.
One option would be one-time access to a 'Set Password' interface of some sort - that's not a bad idea in some ways, because no one will ever see the password, and it need never be stored as anything but a hash.
Like everything, it all depends on what's behind the locked door.
Passwords and password reset links sent in the clear is not optimal. As you become susceptible to any traffic snooping, rogue ISPs and any people with access to your mail server.
What you are seeing here is the classic problem of public key encryption not being widely used.
If citizens had a government-signed* public key, the provider could simply send the email encrypted with the citizen's public key - confident that only the real customer** could read the message.
As we don't have that yet, what the hosting provider could do is:
Require that all support enquiries for password resets go through a HTTPS encrypted chat service.
This way - whatever proof the customer gave of their identity is protected from snooping and the temporary password (or better yet, a single-use
https://reset-password link) is only provided through the HTTPS chat session. The customer being instructed not to save the link and click the reset link before it expires.
* Or better yet each citizen's public key is signed by multiple mutually-antagonistic governments to reduce collusion and government misuse.
** And government spies of course if no government or only cooperating governments signed it.
On #2 - One of my employers' IT department did not allow any passwords to be sent by email at all. Even the new accounts' passwords were communicated in person or by (landline) phone, not alternative email addresses.
No password, encrypted or not, was transmitted over the network. One must be an organized criminal to somehow intercept the phone line at the right time to get the password.
The LastPass password manager can send passwords safely to other LP users. They support 2 share modes, one to share all of the info including the password string. And one mode that shares only the capability to log onto sites. The password however, is not shared visibly, unless perhaps if the site has a show password option.
It varies: what do you have that will get hacked. Public info? Secure info? HIPPA?
Over the phone, or a reset password link and token.
Also, at work I have found that because of the strict password configurations--set by the powers that be-- users just keep the gobbly-gook password in a PostIt on the edge of their computer screen since they have no way of memorising it.
sending passwords in an email is pretty poor practice. generally speaking email is insecure, even if email is encrypted in transit you typically have system admins who have access to email especially in corporate settings so now the system admin can access the account.
if your email data is not encrypted in transit MITM sniffing can access the contents.
I would not use a system where passwords are sent in plaintext in an email as this would lead me to question other security elements at the offending organisation.
I like the idea that it all depends on what is behind the door. Most small to medium Enterprises have email systems that don't span multiple mxhosts and so internal delivery is very much local host only, so that and the use of imap or pop over tls should mitigate most mitm issues. On the hand you could diceware the password and send it in an envelope, which then depends on the envelope budget. Most organisations probably aren't paranoid enough to do the envelope thing. The other method would be to get all users to generate their own keys and you retrieve their keys from a hkp server and you sign and encrypt the password in that.