Am trying to define an API spec, that is expecting the post body to be signed and encrypted. Is there any way we can define this in RAML? Security schemes etc allow you to define authN/authZ etc but not sure how to indicate that the data itself needs to be signed and encrypted a certain way.
Related
I'm currently working with ASP.Net Core 2.1.2 and I can't find a solution for my problem.
Currently I'm building a controlpanel together with Angular 5.
The data for a user is stored in a MySQL database.
To have access to the controlpanel you have to login - and the server will load some data. Important is the admin-level (1-?) - some actions are only allowed for admins with atleast a level.
For the authentication I'm using JWTBearer, which gets sent by the client at every HTTP action as header. But in some methods I also want to check the admin-level.
Now where can I store data for the client, like his admin-level?
Is it safe to save it with a Claim? But then wouldn't it be possible for the client to modify it clientside and send a "custom" header?
I also tried to put the data in a dictionary and use the (HttpContext.)User (of type ClaimsPrinciple) as the key, but that won't work because User is always different at every Request.
Is there any safe way to store the data for a User?
You can safely store your admin-level information in a Claim, unless you're worried that someone can read it. It's not possible to modify a Claim in JWT, because its value is signed by key which only you should know and after the modification this token will be invalid. Read this article to get more information about JWT
I'm working with a couple of API's that use basic auth. The credentials differ between environments and I have usernames and passwords as separate variables.
I really like how Paw 3 has encrypted password field and how it hides the base64 representation when using that, is there any way to have an environment variable in the encrypted field?
In the environments you can put your password in a Secure dynamic value. Then it will stay encrypted:
To insert it in the Basic Auth Dynamic value you should change to Secure field to Regular field and insert your environment variable in there:
Your password will stay encrypted as it is inside a Secure dynamic value:
I was reading article on JWT web token as an access token that is being response to the user. Some of it mention that the web token should be able to be decoded by the user.
Does it means that it is not a good practice to decrypt the entire web token? For example, I suppose to return following JWT web token to user where this piece of information can be decoded.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
However, I feel that I do not want to let user able to decode his/her access token, so I use another encryption algorithm to encrypt everything into another form as follow and pass back to user.
So, I would decrypt this new text when I'll get this access token in the server and decode it.
Is it recommended to do it this way if I do not wish to expose some of the value available in claim (such as user id) to the user? If not, what are the alternatives?
JWT (RFC7519) is just a compact way to safely transmit claims from an issuer to the audience over HTTP.
JWT can be:
signed (JWS - RFC7515)
encrypted (JWE - RFC7516)
signed then encrypted (this order is highly recommended). The whole JWS is the payload of the JWE
encrypted then signed.
It makes sense to encrypt a JWS if you want to keep sensitive information hidden from the bearer (client) or third parties.
The real questions are: does the audience support JWE? If yes, which algorithms are supported?
JWT are "signed" and therefore its contents are protected from tampering: you cannot change its contents without invalidating them.
You can optionally "encrypt" the contents and therefore turn them visible only to issuer (the entity creating the token) and the consumer (the entity that is destined to use its contents after verification).
There's a standard for that: JWE
A token contains user data and acts like a temp storage. It is not good to store sensitive data in a token.
At the first level, you should store the user name and maybe role or something like that. You should not include passwords, so it does not need to be encrypted.
Nevertheless, you can encrypt it if you want.
Yes, the best practice is use the JSON Web Encryption (JWE) RFC, the claims in the JWT after decode it are in plain text, so if the user lost the token, the sensitive information as email, username, access permissions can be visible and can be used as a the initial information of any attack.
So I was reading a neat article I found on /r/netsec:
https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly
One thing that really threw me for a loop is that one could flip a bit in an encrypted cookie and actually have a meaningful change in the contained data.
Making sure all traffic goes over SSL is easy enough (this isn't a question about secure transport), but this got me really thinking about message integrity and how to see if the original cookie has been tampered with. Typically I would store only the authenticated user ID in the cookie and handle all the other stuff behind my firewall. What if I could tamper with that cookie to change the user ID from the client side? The above article indicates that this is possible, as well as offering suggestions to solve this problem using preferably libsodium. I know of this library (haven't used it myself), but that leads me further down the rabbit hole in my thinking that something external to ASP's built-in security mechanisms are needed.
Regarding built-in ASP security specifically, do I need to do anything special not already implemented in the standard way of handling cookie security (letting OWIN do its thing or using FormsAuthentication.Encrypt)? If not, how is message integrity handled under the hood?
Further reading led me to this HttpSecureCookie class on code project:
http://www.codeproject.com/Articles/13665/HttpSecureCookie-A-Way-to-Encrypt-Cookies-with-ASP
The above indicates using the machine key to make a cookie tamper proof, but I am unclear as to exactly HOW it makes it tamper proof. How would this prevent the malicious user from doing that bit flipping indicated in the original article to an encrypted cookie?
Simply set the forms authentication protection method to Encryption and validation.
This will protect against bitflipping attacks as the signature will not match once a bit is flipped. Validation means the message is signed.
How does validation work?
The validation algorithm can be set in web.config in the validationAlgorithm attribute of the machineKey element.
By default it uses HMACSHA256 which is a SHA-256 hash applied using the HMAC construct.
The hash signs the cookie - if the cookie value changes, the hash will no longer match. As an end user does not know the secret, they cannot change the cookie value.
e.g. Try on here to generate a SHA-256 HMAC for message foo with the secret secret.
This should give you: 773ba44693c7553d6ee20f61ea5d2757a9a4f4a44d2841ae4e95b52e4cd62db4
Note that if you change the foo to something else, the hash will be different. This is how a cookie can be protected from tampering. This cookie would be set as follows.
Set-Cookie: id=foo&hash=773ba44693c7553d6ee20f61ea5d2757a9a4f4a44d2841ae4e95b52e4cd62db4
Notice that the value is in the clear, but the hash signature prevents any tampering. This is validation only.
With the encryption and validation option foo would be encrypted first and the signature would prevent any bit flipping. This enables values to be stored in private from the end user.
If you're implementing this outside of Forms Authentication, remember though to store some type of expiry date in the cookie and include this in the signature. This date can be checked server side. Forms authentication does this by default.
Otherwise, a user could make note of a valid cookie value. Say they are given administrator access for one day and the following cookie is issued:
username=admin&hash=71b3ba92493e92ce3c60042988e9de428f44b35a6be61c8da99fa43f950d3056
The next day when the administrator access is revoked, all the user would need to do is use a cookie editor to set their cookie to the above value and they would have administrator access to the system again.
To fix this you would issue a cookie like so:
username=admin&expiry=20150508100000&hash=e38a3a003b30ceb9060165d19bb8d2a2bca6c7c531a37e888448ca417166db3a
This has the expiry date in the cookie, which is signed in the hash. Any attempt to modify the expiry date will result in a HMAC mismatch, and the user will not have access. This will prevent any tampering with the cookie expiry date or any recreation client-side.
What are our other don't-mess-with-my-cookie options if not using forms authentication?
Another method is to store a completely random, cryptographically secure generated string and set that as the cookie value. On your server, store it hashed with SHA-2 (no need for salt) and lookup this value to retrieve details about the user's session. Of course this has some more overhead. The advantage is that sessions can be killed server side by deleting the entry.
This can be done with Forms Authentication too, however you would need to implement a custom provider.
What's the best way to save user credentials in flex? Local storage doesn't seem like good place for storing confidential data, because it saves information as a plain text.
You shouldn't. Use browser cookies or a session token to identify the user to the server. For instance:
User enters username and password into a form in Flex and clicks login.
Server validates credentials. Then either in memory or in a database the server associates a random (and sufficiently secure) token with the user. Then the server returns the token to the client.
Client saves the token in either a cookie, LocalSharedObject, or just in memory. Then subsequent requests also include the token.
You can use ExternalInterface to communicate with JavaScript and store data in browser cookies.
Don't store users' name or password in cookies - create a session in the server with credentials in it, and store the session id in the browser cookies.
if your service don't support credential, then the only think you can do is save user login state in SharedObject.
You can save hash value of UserName + Random Token to SharedObject and save a copy of UserName too in SharedObject, then when application created creationComplete check wheather the hash value match with the saved user name.
the good thing about this trick is:
Password never persisted locally.
Harder to fake login because need to
match username with the hash value.
a bit hard to explain here you can check it here, source code is available for download.
User credentials are normally stored in a session variable.
You don't necessarily need to save the credentials as plain text in Local Storage; in fact, Local Storage (SharedObject) is actually serialized as AMF, so it's not plain text to begin with. Whatever medium you use to store your sensitive data, you should certainly consider using some sort of hashing or encryption techniques like SHA1 or RSA.
The difference between hashing and encryption is this:
Hashing (SHA1, MD5, etc) is a one-way encryption - in other words, it's very difficult to determine the original value of the hashed value, so what you can do is compare one hashed value to another since these hashing algorithms will always spit out the same thing.
Encryption (RSA, AES, etc) is a two-way encryption - in other words, you can determine the original value of the encrypted data, usually by using a public/private key combination
It really depends on what you're trying to do.
Hope you come right
SharedObject is a very bad place to store your password in.
Please see this:
http://livedocs.adobe.com/flex/3/html/help.html?content=security2_22.html