I am creating a Flutter app which uses Node Js server API. For the authorization I decided to use JWT with private/public keys. Communication between Server and mobile client uses HTTPS. Flutter app stores the token in a keychain (ios) or a keystore (android). My question is related to the need of the additional security measures implementations. I am wondering if the following points are required:
Verification of the server responses with public key by checking the token to identify the server
Verification of the client requests with the private key on the server side (client signs the token with public key)
Are these really needed in order to avoid man in the middle attacs? My objection is related to the performance related to signing/verifying tokens for each communication.
Thank you
I've used JWT our mobile apps for security and these apps had taken the security test(3.party company). The company says: secret your stored token or any keys.
And we know doesn't enough just JWT security. We wrote a custom encrypted algorithm to hide JWT (like sha-1) so we encrypt JWT to this.( you must write encryption code client-side & backend side)
Normal jwt : eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
After encriypt: xxs{4=-23dasdxe3 (example)
We passed the security rules with this solution.
Related
Let say i have an android app with Reddit OAuth2 authentication. I initiate authorize request with my client id and user accepts the consent. Now i got the authorization code which will be exchanged for token in my server via HTTP request. This process will protect my client secret as it is in my server, but it actually doesn't. Anyone can take the client ID from the app by decompiling and initiate authorize request to reddit and exchange code for token from my server. They don't even need to know secret to get the token.
How can one protect the API against this kind of misuse (or attack?)?
Is there any way i can allow my API to accept requests only from my app and reject other requests (using SHA256 or etc.)?
I have looked up and studied about PKCE. But this is not useful in case as it only protect again code sniffing/intercepting and accept only the original authorize request initiator.
You will probably want to store a secret. When first opening the app (and after certain interval of times to keep it secure) you will need to generate a keypair. Store the private key on the device's Keystore and send over the public key to your backend. When authenticating to your api, sign the client's secret with the private key and verify it using the public key on the backend.
Note that this will induce substantial overhead to your login process. Because mobile devices are not necessarily well equipped to perform cryptography. Though this is less and less true.
EDIT: Your keypair will need to be issued from a CA you trust, otherwise this is all useless.
I'm working on an ionic app which start with a login system, I already create a basic authentication system which fetch in the database for the username and the password if exist I get as output the ID of the user and his full name and I store them in the local storage but I can see that this way isn't secure enough so how I can build a strong and a secure authentication system using ionic 4v, I found something like using a token and store but i didn't get the idea
Note : for the Backend there is an other team works on it they use JEE with SpringBoot Framework
I would suggest going with the JSON Web Token (JWT) approach. You can find more information on it here. You basically want to create an API endpoint that consumes the users username and password then validates it and if it is successful it returns a JWT.
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a
compact and self-contained way for securely transmitting information
between parties as a JSON object. This information can be verified and
trusted because it is digitally signed. JWTs can be signed using a
secret (with the HMAC algorithm) or a public/private key pair using
RSA or ECDSA.
You might also want to include refresh tokens so that you can get a new JWT when the current one expires as putting a long expiry on a JWT is not recommended.
You will need to provide more information on what programming language your backend/API is in so that we can assist you with the correct implementation thereof.
I'm building a mobile application interacting with backend providing REST APIs. Most of the APIs are protected by access_token provided to a success login.
However I'm curious that WHO will protect the signup, login APIs from anonymous callers, as those APIs don't require access_token (assuming that the system handle DDOS well)? Using API Gateway like Kong with its OAuth to protect all APIs seems to be proper solution but somehow a bit overkill for small/medium/no-micro-service projects.
Some of my simple ideas is to use a set of predefined username-password pairs for Basic auth or more complicated one like Digest auth or an OAuth layer putted before API routes. Mobile app keep those secrets then use them to make signup, login API requests.
Do we any other solutions here?
Mobile app keep those secrets then use them to make signup, login API requests.
Please do not put any secret at all in your Mobile App once they can be easily reverse engineered with frameworks like Xposed.
Mobile Apps can be made more secure and difficult to reverse engineer by using some techniques to secure the secrets both in the Mobile APP and in the API server, like:
Certificate Pinning to protect the communication channel between the Mobile App and the API.
HMAC signed/encrypted messages.
Signed JWT Tokens with encrypted content.
OAUTH2 as a more secure alternative for authenticate your users.
Advanced code obfuscation techniques in the Mobile App code.
You can read more about how some of this techniques can be used and bypassed on this article.
However I'm curious that WHO will protect the signup, login APIs from anonymous callers
If you have read the article I linked above, about Mobile API techniques, you are aware that you need to protect all API endpoints, even the ones behind the authentication, otherwise you will be subject to API abuse of your endpoints by automated scripts, bots, crawlers and all kind of attackers that may profit from your service or data.
For hardening the security between your Mobile App and the API server you should use a Mobile App Attestation service, that will guarantee at run-time that your App was not tampered or is not running in a rooted device by using an SDK integrated in you App and an attestation service running in the cloud, that will emit a signed JWT token that then the API server can validate to distinguish a valid request from a fake one.
JWT Token
Token Based Authentication
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
Certificate Pinning
Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.
OAUTH2
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849.
I'm reading about JWT and I'm confused about why there's a signature:
JWT site
What is the purpose of the signature if it's just a hashed version of the header and payload?
Also, why not just use oAuth? Or whatever 2 factor auth uses?
The purpose of Oauth2 and JWT is different, so it is not possible to compare them directly
JWT is a compact way of representing claims to be transferred between two parties (JSON with digital signature).
OAuth2 is an authorization framework used by third party applications (websites, mobile apps) to access on resources on a resource server, without exposing user password. OAuth2 can use JWT as the exchanged token
JWT is self contained and does not need server sessions . The digital signature is performed with server private key and protects the content. Any alteration of the header, the payload or the signature will be detected by the server and reject the token.
Although Thinktecture.IdentityServer supports signing a jwt using a symmetric key, the OidcClient class does not support validating a token using one - it only supports validating tokens signed using a certificate.
Is this deliberate and are there problems or any limitations with signing a jwt with the client secret?
I am getting some push back with requiring client apps to have a certificate and if I can avoid it without compromising security I would like to do so.
IIRC OidcClient is quite old - we just did not implement it. And you apps don't need a certificate, they just need to be able to verify a signature using asymmetric crypto.
Using a symmetric key makes only sense for server-based apps since that key must be stored securely (otherwise anyone who reverse engineers the app can create valid identity tokens).
The other option is to send the id token back to idsrv to validation (for clients that don't have the required crypto libraries). This endpoint does not exist currently in beta 1 - but is on our todo list.