Situation
I'm making an API from scratch, and security is a big problem for me when thinking about APIs (especially REST-APIs). I'm using a method similar to JWT (hashing data like 'issued_at', 'expiration_at' and user-info (email, userid) into a single hash string with salt when the login was successfull, and give it to the user, but not exactly like it), and every time a user wants to access anything beyond the login endpoint, I'm checking the provided token (hash) if it is still valid or not.
My question:
I want to check more things than the validity of the hash, because if some hackers steal someone's hash and use it before it expires, they can do things unauthorized (even when the hashes expire after 5 minutes by default). I was thinking about hashing the IP and the User-Agent string of the HTTP request along with the other details said previously when the login was successfull and I generate the hash, and checking it every time if the requesting UA+IP and the hashed UA+IP are the same. (so when someone tries to use the hash from another IP or UA, I can assume it was stolen, so I can invalidate it and request the requester to log in again). Since the hacker who stole the hash doesn't know what exact data I'm hashing, it looks like a good security door (it isn't intended to be 100% security-proof). Is it a good thing to do, or in other words, does it really adds another layer of security to the whole authorization/authentication? (of course, the main security layer stays the same, the validity of the hash itself. But would this thing make it any safer?)
Disclaimer
I know that a lot of other types and methods of authorization exists, but I don't need answers like "use xyz's method, oauth2, its safer", but answers that really give me an explanation about the dos and don'ts, strictly about the UA and IP address. I want to make my own authorization (at least the concept), to learn more about these things. Thank you in advance!
Related
It might sound like a silly question, because passwords of course need to be hashed and never store the original.
However, for API secrets, generally I see them displayed in the clear when signing up for them.
For example, if I go to the google api console and look at my credentials page, I can view my client secret, same for twitter.
Surely api keys are just as sensitive as passwords?
Is it just because from the provider side, you can be confident that a sufficiently strong password is being generated?
If that's the case, then that doesn't provide any protection is your database is compromised.
Or is it perhaps because if you are using token based authentication, you're either doing password grant type, which requires you to send your credentials along with the client id and secret, or a refresh token, so a user would have already had to have been compromised?
I can imagine a few possible answers to this:
In some cases, it may be required for the server to have persistent storage of the plaintext API key in order to satisfy usability requirements (Google and Twitter being examples).
In some cases, the API key alone is not enough to do much at all -- additionally one needs to have an authenticated account -- and therefore the API key by itself is of limited value (hence less value than a password).
In a number of cases, the API key is hardcoded in a client application (especially mobile applications, which almost always do this) and therefore it does not make sense to add the extra protection on the server side when the same token can be trivially extracted from the client.
The security industry is just not that mature yet. Maybe once hackers start dumping API keys, ideas like this may be taken more seriously.
BTW, I am very serious about the last point. The truth is that a lot of good ideas don't become a reality until there is a critical mass of support behind them. As an example, I once blogged about a related topic -- protecting user confidential information by hashing it in the database but in a way that it could be recovered when the legitimate user logs in. I used Ashley Madison as an example -- in that case, the hackers were more after email addresses, phone numbers, and physical addresses than passwords. So when the hackers snatched the database, they immediately had what they wanted, and they could care less about the bcrypt encoded passwords (in fact, some older passwords were encoded with only MD5!) Unfortunately, concepts like this do not have enough of a push to make them a reality. Even zero-knowledge web designs are very few in the real world.
I have a simple web app that does the authentication of a user. It is working under https, as it is simple it requires two fields username, password + csrf token.
Now I have implemented a simple API, that verifies if the user with the given username and password exist. It is called with jquery.post() method, on the same domain, also using https, but I supply only username and password.
Assuming that my API has only one function for the moment "is-registered" do I need to worry about something? Except of course brute-force.
Assuming that my API has only one function for the moment "is-registered" do I need to worry about something?
"Something" is quite too broad for me to competently answer, but you do not need to worry about CSRF in your case, as long as you keep the request and its result and causes like you described. Let me tell you why.
CSRF attack means that an attacker tricks or forces an user to do an action (send request) which attacker wants with parameters and data an attacker wants, but in the name of the user (with user's valid session and/or other private information of the user).
You do not need CSRF tokens if it may never cause any harm to anyone if the website thinks that the user made the request, although he was just forced to do so. It seems like you case, because it does no harm if an user is forced to ask whether an account with name and password provided by attacker exists.
You just need to be careful not to change causes of such request and its result based on which user sent it.
I am planning to use only cookies (and not sessions) to authenticate users around the private section of my website. I want users to stay logged in indefinitely, unless they logout themselves. It will work like this:
1. Upon successful login I generate a random hash and store it as a HTTP cookie on the user (using SSL). I also store the hash in my database, along with the user id and the user's device.
2. Whenever a new page is requested I check to see if the user has a cookie. If he has I get the hash and search it in my database. If I find a match and the device is the same I assume it's the user and give the page. If I can't find the hash or the device changed I assume it's not the user and ask for login again.
My question: would this method be acceptable, security-wise? I can't see why this would be less secure than using sessions (keeping the users logged in in both cases), as in the end the risk is the same, which is having an attacker discover the hash to impersonate the user. My defense against this is tracking the users device, so the attacker would need to discover the hash and have the same device.
Thanks for your feedback.
What you're describing is basically the session functionality offered by most languages/frameworks.
Just make sure your hash values don't use the time the user logged in as a source of entropy, ie. don't use h(username + login_time) because this could be brute forced fairly easily if the attacker knew the approximate login time.
What language / framework are you actually using? You'll find in most cases there's an option to use the session "functionality" with a persistent cookie (rather than a session one) which would save you implementing this from scratch and possibly creating additional security concerns.
I'm creating an app where user submissions (e.g. photo) are designed to be captured via crowdsourcing. The app connects to an API using an API key, and the app then submits the data anonymously.
We want to avoid the overhead of people creating user accounts and passwords.
However, it seems to me this is vulnerable to a the problem of the key getting revealed. The result is that spammy submissions could be made much more quickly via browser/wget HTTP requests. Because the app is installed on people's devices, it would take a long time for us to be able to withdraw a key and replace it with another.
The approaches to deal with this problem I can think of are:
Hope that the key stays secret. Not ideal from a risk perspective. Using HTTPS for the API endpoint would reduce this risk, but presumably the app could still be decompiled to reveal it (not that in practice anyone would really bother)
Store a fixed username and password in the app, and submit as that. That basically seems to run the same problem - if the credentials are leaked then this has the same problem as 1.
Require a first-run fetch of a token to auto-create a username and password. However, if the key is compromised then this is no more secure. Also, this means we end up with lots of junky usernames and passwords in our database that really don't mean anything.
Not considered desirable: force users to create a username/password. However, that then means a lot of messing around with accounts, and compromises the anonymity of submissions, meaning data protection implications.
Are there standard patterns dealing with this scenario?
The first time the app runs, it could get a random token from the server, store this, and use it on all subsequent requests. The server just checks that the token is one it produced itself. After each request, block the token for 5 minutes (or make a counter so 10 requests are ok but the 11th gets blocked, depending on your use case). When a token gets misused, block it, so the user will have to deinstall/reinstall your app, or, if he made a script to emulate the app, he'd have to re-register after every few posts (plus you can limit the numer of registrations per IP or something similar).
You can assume any fixed credentials will be compromised. A good attacker can and will reverse-engineer the client. On the flip-side, a username/password combo will compromise anonymity (and nothing is stopping a spammer from creating an account).
Honestly, this is a very difficult problem. The (inelegant) solution involves something like a captcha where you provide a problem that is difficult for a bot but easy for a human to solve (for the record, I think captchas are almost useless, although there have been some less annoying alternatives).
Alternatively, sites like Facebook use sophisticated algorithms to detect spam. (This is a difficult approach so I would not recommend it unless you have the manpower to dedicate to it).
I have been following a couple of articles regarding RESTful web services with WCF and more specifically, how to go about authentication in these. The main article I have been referencing is Aaron Skonnard's RESTful Web Services with WCF 3.5. Another one that specifically deals with HMAC authentication is Itai Goldstiens article which is based on Skonnards article.
I am confused about the "User Key" that is referenced to in both articles. I have a client application that is going to require a user to have both a user name and password.
Does this then mean that the key I use to initialise the
System.Security.Cryptography.HMACMD5 class is simply the users
password?
Given the method used to create the Mac in Itai's article
(shown below), am I right is thinking that key is the users
password and text is the string we are using confirm that the
details are in fact correct?
public static string EncodeText(byte[] key, string text, Encoding encoding)
{
HMACMD5 hmacMD5 = new HMACMD5(key);
byte[] textBytes = encoding.GetBytes(text);
byte[] encodedTextBytes =
hmacMD5.ComputeHash(textBytes);
string encodedText =
Convert.ToBase64String(encodedTextBytes);
return encodedText;
}
In my example, the text parameter would be a combination of request uri, a shared secret and timestamp (which will be available as a request header and used to prevent replay attacks).
Is this form of authentication decent? I've come across another thread here that suggests that the method defined in the articles above is "..a (sic) ugly hack." The author doesn't suggest why, but it is discouraging given that I've spent a few hours reading about this and getting it working. However, it's worth noting that the accepted answer on this question talks about a custom HMAC authorisation scheme so it is possible the ugly hack reference is simply the implementation of it rather than the use of HMAC algorithms themselves.
The diagram below if from the wikipedia article on Message Authentication Code. I feel like this should be a secure way to go, but I just want to make sure I understand it's use correctly and also make sure this isn't simply some dated mechanism that has been surpassed by something much better.
The key can be the user's password, but you absolutely should not do this.
First - the key has an optimal length equal to the size of the output hash, and a user's password will rarely be equal to that.
Second, there will never be enough randomness (entropy to use the technical term) in those bytes to be an adequate key.
Third, although you're preventing replay attacks, you're allowing anyone potentially to sign any kind of request, assuming they can also get hold of the shared secret (is that broadcast by the server at some point or is it derived only on the client and server? If broadcast, a man-in-the-middle attack can easily grab and store that - height of paranoia, yes, but I think you should think about it) unless the user changes their password.
Fourth - stop using HMACMD5 - use HMAC-SHA-256 as a minimum.
This key should at the very least be a series of bytes that are generated from the user's password - typically using something like PBKDF2 - however you should also include something transitory that is session-based and which, ideally, can't be known by an attacker.
That said, a lot of people might tell you that I'm being far too paranoid.
Personally I know I'm not an expert in authentication - it's a very delicate balancing act - so I rely on peer-reviewed and proven technologies. SSL (in this case authentication via client certificates), for example, might have it's weaknesses, but most people use it and if one of my systems gets exploited because of an SSL weakness, it's not going to be my fault. However if an exploit occurs because of some weakness that I wasn't clever enough to identify? I'd kick myself out of the front door.
Indidentally, for my rest services I now use SCRAM for authentication, using SHA512 and 512 bits of random salt for the stretching operation (many people will say that's excessive, but I won't have to change it for a while!), and then use a secure token (signed with an HMAC and encrypted with AES) derived from the authentication and other server-only-known information to persist an authenticated session. The token is stateless in the same way that Asp.Net forms authentication cookies are.
The password exchange works very well indeed, is secure even without SSL (in protecting the password) and has the added advantage of authenticating both client and server. The session persistence can be tuned based on the site and client - the token carries its own expiry and absolute expiry values within it, and these can be tuned easily. By encrypting client ID information into that token as well, it's possible to prevent duplication on to another machine by simply comparing the decrypted values from the client-supplied values. Only thing about that is watching out for IP address information, yes it can be spoofed but, primarily, you have to consider legitimate users on roaming networks.