Based on what i know (correct me if i am wrong) the 'access_token' is equivalent to the 'protected ticket' field in AspNetUser table. It's just hashed.
What i am planning to do is deserialize the protected ticket to get the access_token value.
I am trying to support a SSO scenario wherein, the user can access multiple application using the same access token.
Unfortunately, if the hash function used is a cryptographic hash, which the circumstances suggest, this is definitionally impossible (or should be...). Cryptographic hash functions are designed to be extremely expensive (ideally impossible) to reverse, and so the most effective method you have would be to attempt to brute-force the hash, I.e. running inputs through the hash function until you get one that produces the output you want. Even then, there's no telling how long it would take you to find it. It is strongly recommended not to write anything that depends on routinely brute-forcing a cryptographic hash.
Of course, its possible that the possible inputs are incredibly small (I.e. at most 16 bits or so), or that the function used is not a cryptographic hash function (I.e. its something like base64 encoding or rot-13). In that case, you might have a method to reverse the "hash" efficiently.
However, I strongly suspect that is not the case. In this endeavour, I think you are simply out of luck, and will have to find another way to get the functionality you desire.
I think I'm a bit late, but it should be possible. The data of ProtectedTicket will be secured by Microsoft.Owin.Security.ISecureDataFormat.Protect. It's not a one way hash. So it can be reversed. You can look this up on Github in the Katana project (Microsoft's Owin implementation):
https://github.com/aspnet/AspNetKatana/blob/dev/src/Microsoft.Owin.Security/DataHandler/SecureDataFormat.cs
As you can see, this interface provides a method Unprotect also. Didn't test it, but you could give it a shoot.
you can use the same token on the same apps as long the jwt token is signed with the same credentials (audience and secret) on every app. This allows every app to verify that the token is valid. this means, how-ever, that every app must know audience id and secret in the backend
Related
Scenario: I need to store document accepted by the customer in my database. Customer needs to be sure that I don't modify it through time, and I need to have possibility to prove that stored document was accepted by the customer.
Do you know proven ways how to achieve this without doubts from any side?
I think I can create checksum from stored data for the customer, but I need to ensure that this checksum is unmodifiable by the customer. Any ideas?
PS. If you have better idea how to title this question then tell me, please.
PS. Let me know if you see better forum to ask this question, please.
What we call this in Cryptography is data integrity.
To ensure that the data is not changed by you or someone else, your customer can calculate the hash of the file with a cryptographic hash functions, which are designed to have collision resistance. I.e.
Hash(Original) != Hash(Modified) // equality almost impossible
In short, when you modify it is expected that the new modified document has the same hash value is impossible (in Cryptology term, negligible).
Your customer can use SHA-3 hash function which is standardized by NIST.
Don't use SHA-1 which has shattered.
If you want to go further, your customer can use HMAC which are key-based hash functions which supply data integrity and the authentication of data.
For the second part, we can solve it by digital signatures. Your customer signs the message
Sign(hash(message))
and gives you
( Sign(hash(message)), message ) )
and his public key.
You can verify the signature with the public key of the customer to see that the customer changed the data or not. Digital signatures gives us Non-Repudation.
This part actually solves your two problems. Even third parties can check that the data is not modified and comes from the signer (your customer).
Note : don't use checksums which are not Cryptographically secure and mostly easy to modify the document in a way that they have the same checksums.
I am doing the setup of OAuth with Firebase for a Google Actions app.
I chose the Authorization Code Flow and I am following the steps from the doc here :
https://developers.google.com/actions/identity/oauth2-code-flow
Step 4 of Handle user sign-in, there are two ways to create an authorization code.
I prefer the one that use a json to store the expiration date to save a database call in the next step.
Now, I would like to store all the authorization codes generated and I am not sure about what is the best way to do so. My auth codes are very long (170 characters), and I am not sure if it is a great way to store them as Index in Firebase.
Here is what my DB looks like :
I thought about using a hash to shorten them, but I am afraid about hash not being unique.
What would be the cleanest way to store auth codes in Firebase ?
Thanks!
Keys can be up to 768 characters, so using the auth code as a key makes perfect sense.
Using a hash is reasonable since a good hash has a very low chance of collision, but doesn't provide you much additional value in your case and will (slightly) increase computation time and program complexity.
In order to construct an entity with quite a lot of information, I need to performe a sequence of forms submitting. Every time I return a view from a controller, I need to pass some id's about the not yet established entity. Right now I inject these pieces of info into hidden fields, and when post back to server, continuing to construct the entity.
This scenario continues for a few times.
I'm very not satisfied with this way of passing sensitive information, and was wonder if there're other more appropriate ways of doing it. I use authorization and authentication, but still worried of some scenarios in which one user could hack these id's, before sending it back to server, and by that, modifying the wrong entity.
Also, seems kind of hard work to pass back and forth the same data. I disqualified the use of sessions, because it reveals a different kind of data disruption threat . (in case of using more than one browser at a time).
How should I perform the mentioned operation?
You can use a secure hash of the data in another hidden field to detect tampering with the values.
Here is an example of how to generate a cryptographically secure hash http://www.bytemycode.com/snippets/snippet/379/
You can secure your data using many approaches, I discussed some of it in this post
http://miroprocessordev.blogspot.com/2012/03/save-aspnet-mvc-application-against.html
http://miroprocessordev.blogspot.com/2012/03/safe-aspnet-mvc-application-against.html
use Cross-site request forgery with token to identify that everytime u send an info it contains same token generated at server side and returned from your html
I am debating using user-names as a means to salt passwords, instead of storing a random string along with the names. My justification is that the purpose of the salt is to prevent rainbow tables, so what makes this realistically less secure than another set of data in there?
For example,
hash( md5(johnny_381#example.com), p4ss\/\/0rD)
vs
hash( md5(some_UUID_value), p4ss\/\/0rD)
Is there a real reason I couldn't just stick with the user name and simplify things? The only thing my web searching resulted was debates as to how a salt should be like a password, but ended without any reasoning behind it, where I'm under the impression this is just to prevent something like a cain-and-able cracker to run against it without being in the range of a million years. Thinking about processing limitations of reality, I don't believe this is a big deal if people know the hash, they still don't know the password, and they've moved into the super-computer range to brute force each individual hash.
Could someone please enlighten me here?
You'll run into problems, when the username changes (if it can be changed). There's no way you can update the hashed password, because you don't store the unsalted, unhashed password.
I don't see a problem with utilizing the username as the salt value.
A more secure way of storing passwords involves using a different salt value for each record anyway.
If you look at the aspnet_Membership table of the asp.net membership provider you'll see that they have stored the password, passwordsalt, and username fields in pretty much the same record. So, from that perspective, there's no security difference in just using the username for the salt value.
Note that some systems use a single salt value for all of the passwords, and store that in a config file. The only difference in security here is that if they gained access to a single salt value, then they can more easily build a rainbow table to crack all of the passwords at once...
But then again, if they have access to the encrypted form of the passwords, then they probably would have access to the salt value stored in the user table right along with it... Which might mean that they would have a slightly harder time of figuring out the password values.
However, at the end of the day I believe nearly all applications fail on the encryption front because they only encrypt what is ostensibly one of the least important pieces of data: the password. What should really be encrypted is nearly everything else.
After all, if I have access to your database, why would I care if the password is encrypted? I already have access to the important things...
There are obviously other considerations at play, but at the end of the day I wouldn't sweat this one too much as it's a minor issue compared others.
If you use the username as password and there are many instances of your application, people may create rainbow tables for specific users like "admin" or "system" like it is the case with Oracle databases or with a whole list of common names like they did for WPA (CowPatty)
You better take a really random salt, it is not that difficult and it will not come back haunting you.
This method was deemed secure enough for the working group that created HTTP digest authentication which operates with a hash of the string "username:realm:password".
I think you would be fine seeing as this decision is secret. If someone steals your database and source code to see how you actually implemented your hashing, well what are they logging in to access at that point? The website that displays the data in the database that they've already stolen?
In this case a salt buys your user a couple of security benefits. First, if the thief has precomputed values (rainbow tables) they would have to recompute them for every single user in order to do their attack; if the thief is after a single user's password this isn't a big win.
Second, the hashes for all users will always be different even if they share the same password, so the thief wouldn't get any hash collisions for free (crack one user get 300 passwords).
These two benefits help protect your users that may use the same password at multiple sites even if the thief happens to acquire the databases of other sites.
So while a salt for password hashing is best kept secret (which in your case the exact data used for the salt would be) it does still provide benefits even if it is compromised.
Random salting prevents comparison of two independently-computed password hashes for the same username. Without it, it would be possible to test whether a person's password on one machine matched the one on another, or whether a password matched one that was used in the past, etc., without having to have the actual password. It would also greatly facilitate searching for criteria like the above even when the password is available (since one could search for the computed hash, rather than computing the hash separately for each old password hash value).
As to whether such prevention is a good thing or a bad thing, who knows.
I know this is an old question but for anyone searching for a solution based on this question.
If you use a derived salt (as opposed to random salt), the salt source should be strengthened by using a key derivation function like PBKDF2.
Thus if your username is "theunhandledexception" pass that through PBKDF2 for x iterations to generate a 32 bit (or whatever length salt you need) value.
Make x pseudo random (as opposed to even numbers like 1,000) and pass in a static site specific salt to the PBKDF2 and you make it highly improbable that your username salt will match any other site's username salt.
I'm using ASP.Net but my question is a little more general than that. I'm interested in reading about strategies to prevent users from fooling with their HTML form values and links in an attempt to update records that don't belong to them.
For instance, if my application dealt with used cars and had links to add/remove inventory, which included as part of the URL the userid, what can I do to intercept attempts to munge the link and put someone else's ID in there? In this limited instance I can always run a check at the server to ensure that userid XYZ actually has rights to car ABC, but I was curious what other strategies are out there to keep the clever at bay. (Doing a checksum of the page, perhaps? Not sure.)
Thanks for your input.
The following that you are describing is a vulnerability called "Insecure Direct Object References" And it is recognized by A4 in the The OWASP top 10 for 2010.
what can I do to intercept attempts to
munge the link and put someone else's
ID in there?
There are a few ways that this vulnerability can be addressed. The first is to store the User's primary key in a session variable so you don't have to worry about it being manipulated by an attacker. For all future requests, especially ones that update user information like password, make sure to check this session variable.
Here is an example of the security system i am describing:
"update users set password='new_pass_hash' where user_id='"&Session("user_id")&"'";
Edit:
Another approach is a Hashed Message Authentication Code. This approach is much less secure than using Session as it introduces a new attack pattern of brute force instead of avoiding the problem all togather. An hmac allows you to see if a message has been modified by someone who doesn't have the secret key. The hmac value could be calculated as follows on the server side and then stored as a hidden variable.
hmac_value=hash('secret'&user_name&user_id&todays_date)
The idea is that if the user trys to change his username or userid then the hmac_value will not be valid unless the attacker can obtain the 'secret', which can be brute forced. Again you should avoid this security system at all costs. Although sometimes you don't have a choice (You do have a choice in your example vulnerability).
You want to find out how to use a session.
Sessions on tiztag.
If you keep track of the user session you don't need to keep looking at the URL to find out who is making a request/post.