Tag Info

New answers tagged

2

I think there is an additional problem/challenge with your scheme: Beside the problem of having the key pairs generated by the server, this scheme also allows for a man in the middle attack: A asks for the key of B, server answers with his own key C. Now the server can decrypt, read and encrypt again for B and send the new ciphertext to B. Neither A nor B ...


0

The system you're describing sounds a lot like standard cookie based authentication/session management systems, in that you authenticate the user and then provide a session token to them which allows you to identify requests from that user for the duration of their session. Whilst you could implement this manually, I would recommend against it, as there are ...


3

All your client side security efforts are doomed to failure. Obfuscation and hiding your source just isn't going to work. The more valuable the data you are working with the sooner your code is going to be reverse engineered. The only logical approach to consider everything client side public. Your approach should be to focus your security on server ...


2

This approach is weak as a security control and adds no authentication value. Other commentators are correct that a certificate embedded in an app is easily extracted by a malicious actor. HOWEVER, there is a secure way to do this. Your goal of hiding the server API interface behind a TLS connection requiring mutual authentication in order to prevent it ...


1

No, you cannot secure data completely if the user has total control of the system and its hardware (and possibly a lot of money; attacking hardware can get quite expensive). If this is just to prevent cheating, hardcoding the encryption key in an obfuscated manner (so that strings doesn't find it) should be enough though (any student breaking that probably ...



Top 50 recent answers are included