1

I want to call my REST API with encrypted SMS(with some intermediate server and a shared key by client and server which is transmitted via SSL), I have problem with sending requests that need authentication, When user have internet connection, JWT tokens are sent and everything is good, But if I want to call the same method with SMS, Sending JWT token makes my request very long which is not acceptable for me.

I was wondering instead of JWT tokens, I store information inside token into a table named token and only send encrypted id of that table to mobile client and since the id is much smaller than token, It satisfies my requirement.

I was wondering what is drawback of this approach? I mean instead of sending a signed token, I send an encrypted id to client. All the information about token(userId, timeStamp, clientIP, user mobile number ...) are stored in a table named Tokens which has foreign key to signed in user.

Replay attacks, Stolen token I guess are handled by client IP or mobile number, What else do you think?

Another point I want to add is that my server is only used by a web client and a mobile app and nothing more !

Improve this question
4
  • 3
    How exactly are you using SMS, and are you sure that's the best way? What does the encrypted ID look like?
    – multithr3at3d
    Commented Jul 13, 2019 at 15:41
  • I send my own protocol for calling API via SMS to a SMS server, SMS server interpret SMS content, Calls the API and returns result in my own protocol to the moible client via SMS, ID is a GUID encrypted with a secure key. In case of no internet connection, Using GSM network is the only way possible.
    – Rathma
    Commented Jul 13, 2019 at 20:10
  • 3
    SMS only supports very small datagrams - and all the other technologies you mention use stream based protocols. SMS is hugely expensive compared with IP over GPRS which will be available anywhere SMS is available at a massively lower cost and predictable latency. You seem to be trying very hard to create a difficult solution to a problem which does not exist.
    – symcbean
    Commented Jul 14, 2019 at 22:18
  • @symcbean You are right, But there are similar apps in our market which can do a transaction with 3 SMS messages (login, transfer and result !). If I solve the login message with a very short SMS message(below 160 characters), Other methods are not that expensive compared to the service user receive when there is absolutely no internet connection.
    – Rathma
    Commented Jul 15, 2019 at 10:33

1 Answer 1

Reset to default
3

By storing the token in the database and sending the (encrypted) id of it to client you've just created new token. Forget about JWT tokens, you new token is the encrypted integer ID in the database.

You shouldn't use ID as the new token: IDs are usually incremented (and therefore predictable), and in some encryption schemes flipping the bit in cyphertext flips it after decryption in plaintext, so attacker can increment the ID without being able to read its plaintext. You can skip the whole encryption step and just use a (cryptographically secure) random number. Better yet - use longest acceptable string of random characters that are valid to transmit in SMS.

Encryption is a bijection between plaintexts and ciphertexts, so encrypting a random number doesn't make it harder to guess. Also encryption can't check that cyphertext wasn't modified before decryption unless you've added MAC to the protocol, but MAC would be too long for your case.

Also you shouldn't rely on the sender's phone number to identify the sender (or on confidentiality of SMS), SS7 is pretty vulnerable to eavesdropping and impersonation attacks. However everyone acts like it's secure for some reason...

Improve this answer

You must log in to answer this question.

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