7 ms·

Could someone with a solid security background provide a example of how to properly handle the issues that this API fails so badly at? While some developers ma

by Osiris 13y ago

Could someone with a solid security background provide a example of how to properly handle the issues that this API fails so badly at? While some developers may be able to clearly identify bad practices, best practices may not always be so clear. I'd love to know what a best practice would be for things like authentication to an API and some of the other issues brought up here.

deleted 13y ago
[deleted]
cjfont 13y ago
When I have a simple app send a password to the server, I like to generate a hash on the client side and then rehash again on the server for storing. As far as APIs, the good ones will hash your secret key together along with other data unique to your HTTP request, in particular the headers and the datetime. This is a good idea because: 1. you are not sending your secret key in clear text 2. it makes it difficult for a man-in-the-middle attack because they cannot just take your hash from one of your requests since it will be invalid after received or if some time has elapsed. For an example, see how Knox sets up requests for Amazon AWS: https://github.com/LearnBoost/knox https://github.com/LearnBoost/knox
- viraptor 13y ago
  > I like to generate a hash on the client side I'm confused. What do you do with that hash then?
  - cjfont 13y ago
    It is sent to the server, instead of the clear-text password. This isn't really necessary if you're using HTTPS, however.
    - skyebook 13y ago
      For anyone reading: please just use HTTPS!
    - duskwuff 13y ago
      Sending a straight hash of the password is no more secure than sending the password in cleartext - an attacker can just replay the hash they sniffed off the network. As skyebook said, use HTTPS. There's no excuse.
      - cjfont 13y ago
        This practice is more to prevent the user's password from being revealed than it is to prevent others from logging in as you. In a trusted environment, you may not care that someone there has access to your account, but you don't want them to know what password you chose. Having said that, do use HTTPS when possible, but keep in mind some corporate environments force proxies that can see your traffic anyway.
      - deleted 13y ago
        [deleted]
      - icambron 13y ago
        I agree there's no excuse not to use (and force) HTTPS, but the parent did say: > hash your secret key together along with other data unique to your HTTP request, in particular the headers and the datetime So that isn't a straight hash and you can't just trivially replay. It does require you store the secret in the clear (or at least reversibly) on the server, but I see a lot of APIs do that...
    - deleted 13y ago
      [deleted]
fauigerzigerk 13y ago
First of all you need to make a decision. Do you require your users to entrust the client software with their passwords or not. If you can do that, the solution is pretty simple. Do it as you would do it with any website. Simply use https (TLS) to transmit username and password and return a session cookie to use in subsequent requests. Run your API over https only. If you don't want your users to entrust client software (i.e. apps) with their passwords then use https with OAuth. The reason why using https alone works well for web apps is that users can trust their browsers. Browsers can know the password and they probably won't steal it. However, if you provide an API and you expect many different client apps, including some dubious ones, to use that API on behalf of your users then users cannot trust the client software and hence you should use OAuth. The decision doesn't depend on whether or not your application stores sensitive data, because users often use the same password for different sites. So if you like your users and you provide an API for mobile apps to use, you should use OAuth.
JangoSteve 13y ago
I wouldn't say I have a solid security background, but there are four best-practices I can think of that would have prevented the security vulnerabilities outlined by this post: 1. Hash the secret API token/key given to each client that is sent to the server with each API request. This will prevent attackers from being able to find out your secret token. If you only hash the secret token though, this still won't help, as attackers could just send other API requests along with the hashed token. Instead, you will want the client to hash other data unique to the specific API request as well. For example: http://api.example.com/api_function_name?app_id=my_app&hash={hash_value}&other=stuff Where the hash_value is computed by the client with something like: EDIT: Clarified hash_function parameters, thanks @eru. hash_function( secret_key, api_function_name) The API server will then receive the request, look up the client's secret_key based on the app_id, and run the same hash_function to make sure it matches hash_value in the request. This would mean attackers couldn't reuse the hashed value to send other API calls. But they'd still be able to send calls to that function and just change the parameters to the call to get other information from that API call. So, you could also include the other API call parameters in the hash_function as well, which would mean attackers could only replay that exact API call and not change any of the parameters. You might notice, this is still not good. So, to prevent this "replay attack", you would also generally include the current datetime in the API call as well: hash_function( secret_key, api_function_name, datetime ) Now, attackers can't even replay the exact request, because by the time they do, the datetime will have changed and so the API server would reject the request if it was replayed later. And since the attacker still doesn't know the unhashed secret_key (since it's never been transmitted in plain text), they can't change the datetime without invalidating the hash_value. This is theoretical though, because in reality the above wouldn't work well if the clocks on the client and server were at all out of sync (and they probably will be). So, usually, you'd also have to include the current datetime of the request as another parameter in the call to let the server know exactly what datetimestamp was used in the hash_function, and the server will simply make sure the datetime is within an acceptable window of the current datetime on the server. Of course, the bigger the window, the easier to get the API working with clients, but the larger the window for allowing replay attacks. http://api.example.com/api_function_name?app_id=my_app&hash={hash_value}&other=stuff&time=datetime And lastly, the chosen hash_function for the API should be something not easy to brute-force (meaning don't make it easy for attackers to listen to a few API calls and be able to reverse-engineer the secret_key, since they'll already know what hash_function is from the API documentation). OK, 1 was longer than I anticipated, but the others are pretty short. 2. Another more full-proof way to prevent attackers from getting secret tokens, hashed or unhashed, would be to make all API requests work only via HTTPS. 3. Don't provide API (or any) access to user passwords. 4. Don't store user passwords in plain-text, or even via simple hashes. Instead use a cryptographically secure hashing function with salts.
balls187 13y ago
Usually with an APIkey, you have a corresponding "Secret" Key. This is called a shared secret. Using the shared secret, you can come up with a unique signature, that only yourself and the host can generate. You also want to use some sort of TTL for the signature, to prevent replay attacks. Passwords should never be stored in plaintext. They should be hashed using a cryptographically secure hashing function (bcrypt is easy enough). Password hashes shouldn't ever be exposed to anyone. If you need to provide login functionality, provide a method that takes a username and password. Make sure that username and password method has a backoff time to prevent someone from partying on that api (calling it with username and password combinations) As the password has to be sent in clear text, make sure your login api is over SSL.
misterjangles 13y ago
Using a standard library for authentication like oAuth or similar is generally a better idea than creating your own. It's also usually easier since you don't have to re-invent the wheel. Aside from that, I don't see a reason for an API to be able to retrieve passwords. If passwords need to be reset then the API could maybe issue a pass reset request that would email a confirmation link. The plain text password is something that's beyond the API design, but a one way hash is generally better with an algorithm that is recognized as being secure (not MD5). Basically, to repeat, simply not designing your own security but using recognized libraries will typically be a better idea.

by Osiris 13y ago

deleted 13y ago

[deleted]

cjfont 13y ago

When I have a simple app send a password to the server, I like to generate a hash on the client side and then rehash again on the server for storing. As far as APIs, the good ones will hash your secret key together along with other data unique to your HTTP request, in particular the headers and the datetime. This is a good idea because: 1. you are not sending your secret key in clear text 2. it makes it difficult for a man-in-the-middle attack because they cannot just take your hash from one of your requests since it will be invalid after received or if some time has elapsed. For an example, see how Knox sets up requests for Amazon AWS: https://github.com/LearnBoost/knox https://github.com/LearnBoost/knox

viraptor 13y ago
> I like to generate a hash on the client side I'm confused. What do you do with that hash then?
- cjfont 13y ago
  It is sent to the server, instead of the clear-text password. This isn't really necessary if you're using HTTPS, however.
  - skyebook 13y ago
    For anyone reading: please just use HTTPS!
  - duskwuff 13y ago
    Sending a straight hash of the password is no more secure than sending the password in cleartext - an attacker can just replay the hash they sniffed off the network. As skyebook said, use HTTPS. There's no excuse.
    - cjfont 13y ago
      This practice is more to prevent the user's password from being revealed than it is to prevent others from logging in as you. In a trusted environment, you may not care that someone there has access to your account, but you don't want them to know what password you chose. Having said that, do use HTTPS when possible, but keep in mind some corporate environments force proxies that can see your traffic anyway.
    - deleted 13y ago
      [deleted]
    - icambron 13y ago
      I agree there's no excuse not to use (and force) HTTPS, but the parent did say: > hash your secret key together along with other data unique to your HTTP request, in particular the headers and the datetime So that isn't a straight hash and you can't just trivially replay. It does require you store the secret in the clear (or at least reversibly) on the server, but I see a lot of APIs do that...
  - deleted 13y ago
    [deleted]

fauigerzigerk 13y ago

First of all you need to make a decision. Do you require your users to entrust the client software with their passwords or not. If you can do that, the solution is pretty simple. Do it as you would do it with any website. Simply use https (TLS) to transmit username and password and return a session cookie to use in subsequent requests. Run your API over https only. If you don't want your users to entrust client software (i.e. apps) with their passwords then use https with OAuth. The reason why using https alone works well for web apps is that users can trust their browsers. Browsers can know the password and they probably won't steal it. However, if you provide an API and you expect many different client apps, including some dubious ones, to use that API on behalf of your users then users cannot trust the client software and hence you should use OAuth. The decision doesn't depend on whether or not your application stores sensitive data, because users often use the same password for different sites. So if you like your users and you provide an API for mobile apps to use, you should use OAuth.

JangoSteve 13y ago

I wouldn't say I have a solid security background, but there are four best-practices I can think of that would have prevented the security vulnerabilities outlined by this post: 1. Hash the secret API token/key given to each client that is sent to the server with each API request. This will prevent attackers from being able to find out your secret token. If you only hash the secret token though, this still won't help, as attackers could just send other API requests along with the hashed token. Instead, you will want the client to hash other data unique to the specific API request as well. For example: http://api.example.com/api_function_name?app_id=my_app&hash={hash_value}&other=stuff Where the hash_value is computed by the client with something like: EDIT: Clarified hash_function parameters, thanks @eru. hash_function( secret_key, api_function_name) The API server will then receive the request, look up the client's secret_key based on the app_id, and run the same hash_function to make sure it matches hash_value in the request. This would mean attackers couldn't reuse the hashed value to send other API calls. But they'd still be able to send calls to that function and just change the parameters to the call to get other information from that API call. So, you could also include the other API call parameters in the hash_function as well, which would mean attackers could only replay that exact API call and not change any of the parameters. You might notice, this is still not good. So, to prevent this "replay attack", you would also generally include the current datetime in the API call as well: hash_function( secret_key, api_function_name, datetime ) Now, attackers can't even replay the exact request, because by the time they do, the datetime will have changed and so the API server would reject the request if it was replayed later. And since the attacker still doesn't know the unhashed secret_key (since it's never been transmitted in plain text), they can't change the datetime without invalidating the hash_value. This is theoretical though, because in reality the above wouldn't work well if the clocks on the client and server were at all out of sync (and they probably will be). So, usually, you'd also have to include the current datetime of the request as another parameter in the call to let the server know exactly what datetimestamp was used in the hash_function, and the server will simply make sure the datetime is within an acceptable window of the current datetime on the server. Of course, the bigger the window, the easier to get the API working with clients, but the larger the window for allowing replay attacks. http://api.example.com/api_function_name?app_id=my_app&hash={hash_value}&other=stuff&time=datetime And lastly, the chosen hash_function for the API should be something not easy to brute-force (meaning don't make it easy for attackers to listen to a few API calls and be able to reverse-engineer the secret_key, since they'll already know what hash_function is from the API documentation). OK, 1 was longer than I anticipated, but the others are pretty short. 2. Another more full-proof way to prevent attackers from getting secret tokens, hashed or unhashed, would be to make all API requests work only via HTTPS. 3. Don't provide API (or any) access to user passwords. 4. Don't store user passwords in plain-text, or even via simple hashes. Instead use a cryptographically secure hashing function with salts.

balls187 13y ago

Usually with an APIkey, you have a corresponding "Secret" Key. This is called a shared secret. Using the shared secret, you can come up with a unique signature, that only yourself and the host can generate. You also want to use some sort of TTL for the signature, to prevent replay attacks. Passwords should never be stored in plaintext. They should be hashed using a cryptographically secure hashing function (bcrypt is easy enough). Password hashes shouldn't ever be exposed to anyone. If you need to provide login functionality, provide a method that takes a username and password. Make sure that username and password method has a backoff time to prevent someone from partying on that api (calling it with username and password combinations) As the password has to be sent in clear text, make sure your login api is over SSL.

misterjangles 13y ago

Using a standard library for authentication like oAuth or similar is generally a better idea than creating your own. It's also usually easier since you don't have to re-invent the wheel. Aside from that, I don't see a reason for an API to be able to retrieve passwords. If passwords need to be reset then the API could maybe issue a pass reset request that would email a confirmation link. The plain text password is something that's beyond the API design, but a one way hash is generally better with an algorithm that is recognized as being secure (not MD5). Basically, to repeat, simply not designing your own security but using recognized libraries will typically be a better idea.