9 ms·

Username and password are still sent in plain-text. You could use HTTPS to make the communication secure.

by anty 15y ago

SomeOtherGuy2 15y ago
No they aren't sent plain-text: >https://subdomain.sharefile.com/rest/getAuthID.aspx https://subdomain.sharefile.com/rest/getAuthID.aspx Notice the https. The facepalm is just that there's no additional security in using POST vs GET.
- carbocation 15y ago
  POSTed values won't show up in typical server logs, whereas with GET their plaintext password would normally be logged on every request. And POST over HTTPS keeps the POSTed values hidden from those who might listen, whereas with GET over HTTP it would just be out there in the URL.
  - SomeOtherGuy2 15y ago
    You have no way of knowing what they log and don't log. If their server logs are compromised, you should be assuming their username/password database was as well. And HTTPS requests are encrypted. The whole request, including the "GET /someurl&password=s33krit HTTP/1.1" part. As I said, using POST doesn't add any additional security to this.
    - carbocation 15y ago
      I agree with your concerns. But my comment was talking about "typical server logs" and HTTPS-POST vs HTTP-GET, while yours is addressing different issues.
      - SomeOtherGuy2 15y ago
        I addressed why what gets in logs doesn't matter: if their server is compromised you have to assume you are boned anyways. And I don't understand why is your comment would be talking about "HTTP-GET"? The API in question is dealing with HTTPS for both GET and POST requests.
        cristoperb 15y ago
        I don't understand why your comments pointing out details of the http spec and common-sense security considerations are being downvoted. I guess they are coming across as overly 'stident'? Anyway, I've found them helpful. Thanks.
    - tptacek 15y ago
      I don't understand the point you're trying to make here, or the stridency with which you're making it. You in fact do know that the most popular web servers do log the URL, and do not log POST parameters or individual headers. That's why professional security audits will ding you for putting anything sensitive in a URL.
      - SomeOtherGuy2 15y ago
        Actually, we ding you for putting sensitive information in URLs that are used in a browser. The reason is that it will then be sent to other sites in the referrer header. When it is used for an API it doesn't matter. A security audit will check that logs are not logging sensitive information or that they are properly secured and encrypted if they do contain such information. The combination of telling users to put their password into the url and logging the url would be a problem, but not either thing on its own.
        tptacek 15y ago
        No, SomeOtherGuy. This is an HTTPS site. The referer header does not behave the way you're implying it does on HTTPS sites. And having read and written this particular audit line item about 29074894389734897 times in the last 15 years, let me assure you that logging is clearly an issue. The bit about how "if someone can see your logs you're already boned" is also message-board-logic more than reality. Logs are shipped all over the place. On a network pentest, one of the things you do when you pop a box is hunt for logs; even after you get root on the machine, you don't automatically have all the passwords that get stuck in the log files. Same goes for all the random LogLogic-style consoles those logs get fed to. If you have more questions about this stuff, my contact info is in my profile --- just click my username above this comment. I just wanted to chime in to say that 'carbocation was exactly right, but my comments are now repeating themselves, and so I'm done on this thread.
        SomeOtherGuy2 15y ago
        >And having read and written this particular audit line item about 29074894389734897 times in the last 15 years, let me assure you that logging is clearly an issue. Which is what I said. Logging sensitive info is an issue. Not requesting info that could be logged if you were using default settings. You will get dinged for logging sensitive info, you can either not have the info in the query, or not log the query. Either is fine. >The bit about how "if someone can see your logs you're already boned" is also message-board-logic more than reality. No it isn't. If you can read the logs, you are already either the httpd user or root. Hence you don't need application usernames and passwords anymore, you can just go right ahead and do whatever you like. >Logs are shipped all over the place. Wait, I thought we weren't doing things that a security audit will catch? Why did you change your mind now that is convenient? Rather than considering theoretical "what if they are absolutely retarded and send my username and password in the logs in plain text to internet accessible log storage servers?", why not consider the reality that if they are that stupid, they will be compromised anyways. So what is the concern here? As a user of their system, I know they are either doing things right and I am fine, or doing things wrong I and I am boned. So, exactly what we knew before the whole GET vs POST debate. Very helpful. If they are idiots, then there is nothing I can do to secure my account with them, this is why we don't use the same password for multiple services. >If you have more questions about this stuff, my contact info is in my profile --- just click my username above this comment I would suggest that you read the posting guidelines.
  - deleted 15y ago
    [deleted]
    - tptacek 15y ago
      The server log is not encrypted when using TLS, which is one reason you want to keep sensitive information out of your URLs.
  - tptacek 15y ago
    This is exactly right.
- tmcneal 15y ago
  If you're using SSL then form data in a POST request will be encrypted. HTTP headers are always encrypted using SSL. What wasn't clear to me from the documentation is whether the 'username' and 'password' are form data, or are actually custom HTTP headers. The latter choice would certainly be a facepalm.
  - SomeOtherGuy2 15y ago
    >If you're using SSL then form data in a POST request will be encrypted So will everything else, including the URI being requested, and thus the query string in it. Which is why it makes no difference using GET or POST.
    - SimHacker 15y ago
      But you can be 99.994% sure they're writing your plan text user name and password into their logs if you're using get, and if somebody breaks in and gets them, then they have your password, even if those passwords are properly hashed in the user database.
      - SomeOtherGuy2 15y ago
        No, I wouldn't be 99.994% sure of that at all. In fact, I would assume that if they are suggesting that people use GET, that they are in fact not logging the query params, as any security audit would catch that. And again, if they are compromised, then they are compromised. It doesn't matter if they have logging disabled, someone who would have access to the logs also has access to either the httpd account or the root account. Either way, they can already read your plaintext usernames and passwords directly when they are being submitted. Of course, they don't need your username and password anyways, as they already have full access to the system.
        freshhawk 15y ago
        Picking a comment at random to thank you for at least trying to explain to people why their assumption of what's being logged relates in no way to security. At least one person appreciates someone taking the time to correct this rather serious misunderstanding.
- Torn 15y ago
  Does HTTPs encrypt headers or just the body? Are both things they're offering secure?
  - emillon 15y ago
    TLS is one layer below HTTP. So yes, both headers and body are encrypted.
  - deleted 15y ago
    [deleted]
  - Ethervoid 15y ago
    "Everything in the HTTPS message is encrypted, including the headers, and the request/response load. With the exception of the possible CCA cryptographic attack described in limitations section below, the attacker can only know the fact that a connection is taking place between the two parties, already known to him, the domain name and IP addresses."

Username and password are still sent in plain-text. You could use HTTPS to make the communication secure.

by anty 15y ago

Username and password are still sent in plain-text. You could use HTTPS to make the communication secure.

No they aren't sent plain-text: >https://subdomain.sharefile.com/rest/getAuthID.aspx https://subdomain.sharefile.com/rest/getAuthID.aspx Notice the https. The facepalm is just that there's no additional security in using POST vs GET.

carbocation 15y ago
POSTed values won't show up in typical server logs, whereas with GET their plaintext password would normally be logged on every request. And POST over HTTPS keeps the POSTed values hidden from those who might listen, whereas with GET over HTTP it would just be out there in the URL.
- SomeOtherGuy2 15y ago
  You have no way of knowing what they log and don't log. If their server logs are compromised, you should be assuming their username/password database was as well. And HTTPS requests are encrypted. The whole request, including the "GET /someurl&password=s33krit HTTP/1.1" part. As I said, using POST doesn't add any additional security to this.
  - carbocation 15y ago
    I agree with your concerns. But my comment was talking about "typical server logs" and HTTPS-POST vs HTTP-GET, while yours is addressing different issues.
    - SomeOtherGuy2 15y ago
      I addressed why what gets in logs doesn't matter: if their server is compromised you have to assume you are boned anyways. And I don't understand why is your comment would be talking about "HTTP-GET"? The API in question is dealing with HTTPS for both GET and POST requests.
      - cristoperb 15y ago
        I don't understand why your comments pointing out details of the http spec and common-sense security considerations are being downvoted. I guess they are coming across as overly 'stident'? Anyway, I've found them helpful. Thanks.
  - tptacek 15y ago
    I don't understand the point you're trying to make here, or the stridency with which you're making it. You in fact do know that the most popular web servers do log the URL, and do not log POST parameters or individual headers. That's why professional security audits will ding you for putting anything sensitive in a URL.
    - SomeOtherGuy2 15y ago
      Actually, we ding you for putting sensitive information in URLs that are used in a browser. The reason is that it will then be sent to other sites in the referrer header. When it is used for an API it doesn't matter. A security audit will check that logs are not logging sensitive information or that they are properly secured and encrypted if they do contain such information. The combination of telling users to put their password into the url and logging the url would be a problem, but not either thing on its own.
      - tptacek 15y ago
        No, SomeOtherGuy. This is an HTTPS site. The referer header does not behave the way you're implying it does on HTTPS sites. And having read and written this particular audit line item about 29074894389734897 times in the last 15 years, let me assure you that logging is clearly an issue. The bit about how "if someone can see your logs you're already boned" is also message-board-logic more than reality. Logs are shipped all over the place. On a network pentest, one of the things you do when you pop a box is hunt for logs; even after you get root on the machine, you don't automatically have all the passwords that get stuck in the log files. Same goes for all the random LogLogic-style consoles those logs get fed to. If you have more questions about this stuff, my contact info is in my profile --- just click my username above this comment. I just wanted to chime in to say that 'carbocation was exactly right, but my comments are now repeating themselves, and so I'm done on this thread.
        SomeOtherGuy2 15y ago
        >And having read and written this particular audit line item about 29074894389734897 times in the last 15 years, let me assure you that logging is clearly an issue. Which is what I said. Logging sensitive info is an issue. Not requesting info that could be logged if you were using default settings. You will get dinged for logging sensitive info, you can either not have the info in the query, or not log the query. Either is fine. >The bit about how "if someone can see your logs you're already boned" is also message-board-logic more than reality. No it isn't. If you can read the logs, you are already either the httpd user or root. Hence you don't need application usernames and passwords anymore, you can just go right ahead and do whatever you like. >Logs are shipped all over the place. Wait, I thought we weren't doing things that a security audit will catch? Why did you change your mind now that is convenient? Rather than considering theoretical "what if they are absolutely retarded and send my username and password in the logs in plain text to internet accessible log storage servers?", why not consider the reality that if they are that stupid, they will be compromised anyways. So what is the concern here? As a user of their system, I know they are either doing things right and I am fine, or doing things wrong I and I am boned. So, exactly what we knew before the whole GET vs POST debate. Very helpful. If they are idiots, then there is nothing I can do to secure my account with them, this is why we don't use the same password for multiple services. >If you have more questions about this stuff, my contact info is in my profile --- just click my username above this comment I would suggest that you read the posting guidelines.
- deleted 15y ago
  [deleted]
  - tptacek 15y ago
    The server log is not encrypted when using TLS, which is one reason you want to keep sensitive information out of your URLs.
- tptacek 15y ago
  This is exactly right.
tmcneal 15y ago
If you're using SSL then form data in a POST request will be encrypted. HTTP headers are always encrypted using SSL. What wasn't clear to me from the documentation is whether the 'username' and 'password' are form data, or are actually custom HTTP headers. The latter choice would certainly be a facepalm.
- SomeOtherGuy2 15y ago
  >If you're using SSL then form data in a POST request will be encrypted So will everything else, including the URI being requested, and thus the query string in it. Which is why it makes no difference using GET or POST.
  - SimHacker 15y ago
    But you can be 99.994% sure they're writing your plan text user name and password into their logs if you're using get, and if somebody breaks in and gets them, then they have your password, even if those passwords are properly hashed in the user database.
    - SomeOtherGuy2 15y ago
      No, I wouldn't be 99.994% sure of that at all. In fact, I would assume that if they are suggesting that people use GET, that they are in fact not logging the query params, as any security audit would catch that. And again, if they are compromised, then they are compromised. It doesn't matter if they have logging disabled, someone who would have access to the logs also has access to either the httpd account or the root account. Either way, they can already read your plaintext usernames and passwords directly when they are being submitted. Of course, they don't need your username and password anyways, as they already have full access to the system.
      - freshhawk 15y ago
        Picking a comment at random to thank you for at least trying to explain to people why their assumption of what's being logged relates in no way to security. At least one person appreciates someone taking the time to correct this rather serious misunderstanding.
Torn 15y ago
Does HTTPs encrypt headers or just the body? Are both things they're offering secure?
- emillon 15y ago
  TLS is one layer below HTTP. So yes, both headers and body are encrypted.
- deleted 15y ago
  [deleted]
- Ethervoid 15y ago
  "Everything in the HTTPS message is encrypted, including the headers, and the request/response load. With the exception of the possible CCA cryptographic attack described in limitations section below, the attacker can only know the fact that a connection is taking place between the two parties, already known to him, the domain name and IP addresses."