I'm involved in a project that's building a chat-bot that users can communicate with via SMS from their mobile phones. We'd like the users to be able to use the bot to do some basic account-management tasks over SMS for their accounts with us - changing their base plan, purchasing additional features, etc.

We're wondering if there's any way to (reasonably) securely identify that the user sending the text message is truly the account owner? Options we've considered are 1) ask for the last 4 of the user's credit card and 2) send a one-time-use passcode to the user via email.

Obviously, neither of those provides air-tight security, but the liability involved here is fairly low. If somebody loses their smartphone, the charges that the thief could make using this chat bot would be the least of the person's worries. In the rare event that somebody's phone was compromised, we'd be willing to eat the costs necessary to make the user whole.

However, we'd still like to make this identification process as secure as possible. Problems we see:

With scenario 1, the last 4 of the credit card are potentially left in the SMS history, so anybody who gets the phone (or installs a malicious app) has access to the last 4 of the card and can now authenticate.

With scenario 2, anybody that has access to the phone has access to the email, so it's not really much of an improvement over 1.

Are there any other techniques that we could use to authenticate that might provide more security than those two methods? I'm aware nothing will be air-tight, but I'm looking for good suggestions.

I've considered something like send a salt, have them compute a hash of their last-4, and send it back, but that's prohibitively complex, and still not much of a security improvement.

  • Generally, once an attacker has physical access to someone's computer/phone it's not their computer/phone anymore, so other than reminding users to delete the SMS history containing the cc digits and to use a strong password on the phone itself, there's no much else that can be done from your end. Also, maybe consider using something less risky than cc digits for authentication? I can't speak for it's implementation difficulty personally, but something like Google 2-Factor Authenticator might be a better option IMO. Commented Mar 29, 2016 at 15:17

3 Answers 3


It sounds like what you're looking for is an "out of band" code or token. This means you want something that's not accessible to someone who physically has the phone. So things like emails and Google Authenticator are out.

I'm assuming that users will do (at least) first-time account setup through a web-browser, what about having them enter an "SMS PIN" which the chatbot will later prompt them for?

This is similar to using the last 4 digits of their credit card number in that it will be in their SMS history and a phone thief can make charges to your chat bot. What makes me nervous about CC digits is that for convenience of your service, you are increasing your users' risk of identity theft.

As you pointed out in your question: if the user gets their phone stolen and the attacker gets past the lock screen, they're kinda sunk anyway. What you are really protecting against is somebody impersonating your user from a different phone through SMS spoofing the from: number. In this regard either an email one-time password, or a pre-set pin will give you the security you need.

  • Same issue though, no? Just like the cc digits, the PIN would still be in the SMS history if someone with physical access were to scroll up. Commented Mar 29, 2016 at 15:46
  • 2
    Right, I'm an idiot. Let me think some more. My issue with CC is that using your service increases their risk of identity theft. Commented Mar 29, 2016 at 15:46
  • 1
    Also, if they do lose their phone, a PIN can be easily changed, the last 4 digits of their credit card number, not so much. Commented Mar 29, 2016 at 15:52
  • This answer seems to be an opinion. Perhaps you could include some references to some sources. Commented Mar 29, 2016 at 17:05
  • 1
    Ah, in this context the "band" or "communication channel" would be the cell phone, so an "out of band token" would mean establishing a token by some communication method other than the cell phone. Logging in to your account from a PC would count. Some code on your paper monthly statement would count. Calling them and having them read you a code over the phone would count. Mailing you a physical key generator would count. Etc. "Out of band" is a common term and you should be able to google for more info. Commented Mar 29, 2016 at 17:58

Would a small mobile app be out of the question?

It would handle all incoming and outgoing messages (for the relevant messages of course) it would delete all sent and received messages (from the app). It would require a pin number to access which the user would have to enter each time. Maybe some basic encryption of the message as well?

As an additional benefit it would increase usability in that it could create the SMS using prompts rather then having to remember the right abbreviations and formatting of messages.

  • 1
    Good suggestion. I think if we were going to go that route, though, we'd just have them log into our mobile site. The idea behind using a chat bot was that it's much easier to develop than a mobile app or site, and it doesn't require any UI/design work... Commented Mar 30, 2016 at 17:38

Barring something weird, like switching to something like robot-calling instead of SMS, this seems like an issue that the user has to deal with unfortunately. If you're definitely stuck using SMS to authenticate, there's very little you can do on your end to deal with physical access by an attacker.

Perhaps, make sure to remind users after each authentication message to use strong phone-passwords, and to delete their text history with the chat bot.

It's not really a solution per say, but if an attacker has physical access and can get past the password on the phone itself, there's a bigger issue than charging to your chat bot.

And like Mike suggested, try not to use the cc digits to authenticate, it's just bad practice.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .