Is sending only password (not username) by sms secure?

Question

Is it secure to send only password and not sending with username by sms? Is there any risk?

Answer 1

Really your question needs a lot more context to answer fully.

The likelihood is that your answer will be: 'No, its not inherently terrible to send a user a password via SMS if done with careful consideration.'

SIM spoofing/cloning risks are not really worth considering for the majority of applications, although yeah... if you are designing a system which launches nuclear missiles, SMS would not be adequate.

The biggest realistic technical risk to using a phone number as a point of contact to deliver a password is that phone numbers get recycled. While email services typically haven't let you re-use a dead account since the early 90's, many phone operators still recycle numbers quite quickly and autonomously - with there not being much you can do about it.

Secondarily, you are obviously going to have to involve a third-party's infrastructure to physically deliver the SMSs for you, which adds and expands to the attack surface of your application.

There are some quirks you get via SMS also, such as how the message can spread to multiple devices (like from an iPhone to a Mac) and that technically increases the exposure/footprint of the password, although the same is true of email these days; with users have several devices all signed into the same email.

You could argue that more people have insecure phones than email inboxes. But its a bit of a thin argument as if you have the phone of a victim that has no password protection, that phone is probably authenticated to their email already anyway.

The fact that you are going down a road much less travelled with this design leads me to also speculate that you might be doing odd/bad things elsewhere in the application. While its not related to your question, you might want to consider (if you have not already):

• After you send the password, are you storing it encrypted?
• How are you generating it?
• Does the user have to change it on first logon?

Answer 2

Security is hard.

The general principle of utilizing two factor authentication (2FA) is that of combining the need for secret knowledge (your password) and physical possession (of your token, phone, etc.) which greatly increases the difficulty of attack, and can offer protections against phishing or other man-in-the-middle type attacks. For this reason, it is highly recommended to enable 2FA.

Use of SMS, however, is highly problematic. Even more-so if you use it for password delivery. Even more-more-so if the password is static (e.g. stored with the account), and not generated uniquely on each use. Working backwards on these points:

• If not unique, message history storage (often just an SQLite database on the phone) becomes the thing to steal, as that'll net you the credential. Reference the questions hiburn8's answer ended on, too.
• Delivering single-use passwords on demand is less egregious, however still suffers from GSM problems such as SIM cloning (used in a "recent" NPM breach involving the release of malware-infected popular package).
• SMS is implemented as re-use of dead header space in GSM tower ping packets, which means they can be sniffed, in the clear, using a passive radio.

The last two points make SMS vulnerable to targeted attacks against specific, known users, both remotely (clone) and locally (radio interception). This somewhat eliminates the benefit of not including the username, since the attacker will likely already know that part as part of their targeting (generally public information on most sites), but it's always good to provide as little detail as possible in security sensitive messaging.

Superior to messaged passwords, and superior to messaged one-time codes, would be relaxed password composition rules (to allow passwords to be more memorable, even if weaker) combined with an HOTP or other one-time-password token (I'm a fan of Yubikeys) or phone app.