I'm new to spring cloud.
The user can able to decrypt when encrypted value passes in the decrypt post API. Even a normal developer can able to decrypt the encrypted value using decrypt post API. So this is not secure.
Is there any alternative for this?
I meant the secret is need to pass with decrypt post API. Then it can decrypt only who know the encrypt key and encrypted value.
Is this possible? This is my suggestion only.
Related
I have a security requirement that all the data flows through API should be encrypted. I don't see any OOTB implementation. So I have thought about having a filter to decrypt and a custom sanitizer to encrypt sounded like a plan but are there any other ways to implement this?
HTTPS protocol already has encryption. If you want to make it more, secure maybe you can add a client certificate option.
I just got my twitter oauth token (OAuth 1.0a), so before I store it in database, I have this question: do i need to encrypt it?
A similar question was posted here.
And the answer said:
So, getting just the user's access_token from your database won't help much if they don't also have the consumer_key and consumer_secret for complete access.
The service provider compares all 4 parameters on request. It would be smart to encrypt these 4 parameters before storage and decrypt them before response.
If the hacker can't do anything with only oauth token, then why would I encrypt it?
As far as I can see, if the hacker can get my consumer key with oauth token, he will also get my encryption key storing on the server running the application.
I am planning to use cryptosupport API to encryp/decrypt certain cookie keys bearing PCI/PII customer data. I am setting/reading these cookies at both client and server side. At server end (java), I am able to call API and encrypt/decrypt. How do I call the API from clientside (javascript) ? The usage is quite huge at clientside and I dont want to make ajax calls to server.
Is it advisable to use this API with requirement of encrypting cookie data used at both client and server side?
Or is there simpler encryption API for this purpose?
It is a server-side AEM capability only.
And think about it--if you were able to call an API to decrypt a cipher on the client side (JavaScript), what security would it provide? End users could easily also decrypt the cipher and see the secret, so it really would defeat the purpose of having an encrypted secret.
See What encryption algorithm is best for encrypting cookies? which says
Since this question is rather popular, I thought it useful to give
it an update.
Let me emphasise the correct answer as given by AviD to this question:
You should not store any data that needs encrypting in your cookie. Instead, store a good sized (128 bits/16 bytes) random key in
the cookie and store the information you want to keep secure on the
server, identified by the cookie's key.
We are implementing JWT to allow our client side to authenticate through our separate authentication server.
The client posts the username and password to the authentication server, receives a JWT and then logs in to the main site with the JWT.
Clearly, the token includes the username and some other non-secret information.
The question is if to use JWT to pass secret information and how.
Here are a few options that might be considered:
Don't do it. Have the main website server call a back-end API with the authenticated username to get the information it needs.
Pass the information as Private claims encrypting the values with a symmetric encryption and sharing the key/pass-phrase between the main website and the authentication server.
Encrypt the entire token.
Are there any best practices here? what are the ups and downs of these options?
You shouldn't use JWT for passing secret information.
These tokens are usually signed to protect against manipulation (not encrypted) so the data in the claims can be easily decoded and read.
If you need to pass sensitive information please look at JSON Web Encryption(JWE)
You should check JSON Web Encryption for this purpose
So I have a web Api that authenticates users by username and password. The clients talking to the API will android phones that have an internal app on it to get / send some data from / too the api.
I have hashed passwords in the database with a salt. The connection between the client and the API will be SSL.
Now on the website (MVC) I log users in by generating a new hash and matching this against the hash in the database.
The some of the android devices will have a config file that locks the app to a specific user. Now I rather not store the password in plain text on the device and would like to encrypt the password.
The question now is what would be the best practise here on comparing the hashed password. I dont think its save to just send the plain password to the API or is it?
It's safe, because you're using SSL.
Basic authentication isn't acceptable for plain-text requests, but since HTTPS encrypts everything, it shouldn't be an issue.
Storing the password is a completely separate concern, as you've noted, and that should be encrypted as well, which it sounds like you'll have Android do for you. The only consideration is that you will have to do a reversible encryption to be able to send up the password itself to your API.
Basically:
(client-side) User enters creds
(client-side) Encrypt creds, store in configuration
(client-side) Read from config, decrypt creds
(client-side) File HTTPS request to API with Basic authentication type, using decrypted creds
(server-side) Hash (one-way encrypt, basically) the password, compare against database
That sounds like exactly what you've got, and I see no problem with it.
That all said, just for what it's worth, I'd be tempted to implement an OAuth 2.0 server for this particular use-case, so you don't have to think about persisting the password at all. That's a pretty big undertaking (sort of--it doesn't take too long with those instructions), and you should evaluate it on a case-by-case basis. But any time I have to worry about API authentication, I generally wind up either going with that, or wishing I had.
I would consider using something like JWT (JSON Web Token, http://jwt.io). You can have a client authenticate against your API, and if they provide the right credentials you can issue a token to them, which they can persist on local storage. They would then provide this token in the header of any API requests that require authentication. You can use OWIN middleware to intercept requests, check/validate the token and let the requests through to your controllers if you consider the token to be valid.