#16
  1. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    A big problem of passphrases is that many people will be tempted to use common sayings, famous quotes or movie lines (like Frank suggested).

    Sure, theoretically you could choose from hundreds of thousands of words. But the number of words people actually use is much, much lower. And all big passwords leaks in the past (Sony etc.) have proven that many users are lazy and don't come up with very creative ideas. So instead of "123abc", you might get "I love my wife" or something.

    I think the only pratical solution is to use a password manager like KeePass and generate truly random passwords from the full ANSI or even Unicode range. This way you'll get "perfect" passwords and good usability at the same time. For the master password, you could use a good(!) passphrase.



    Originally Posted by Kravvitz
    One thing that really bugs me is sites that cap the length of passwords at 12 or fewer characters.
    Totally agree! I've had that situation so many times when I generated a password and then had to limit the length and character set. It's just stupid.

    Let's hope they're doing it in order to prevent DoS attacks on their really expensive hashing scheme.
    Last edited by Jacques1; February 5th, 2013 at 06:12 PM.
  2. #17
  3. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,316
    Rep Power
    7171
    2-factor authentication is a fairly practical solution for larger sites, and will only become more practical over time.

    However, I'd be pretty confident venturing a guess that most people whose accounts are compromised are compromised as a result of a key logger or trojan and not as a result of the attacker bruce forcing their password. And in the case of a key logger a good password does nothing for you.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  4. #18
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2003
    Location
    Hamburg, DE
    Posts
    71
    Rep Power
    15
    Originally Posted by Jacques1
    Be aware that the CSRF protection will be defeated if your website is vulnerable to cross-site scripting. On your own site, it is in fact possible to read the token using JavaScript.
    This can be mitigated by setting $httponly in your call to setcookie(). Here's more on the subject - http://www.codinghorror.com/blog/200...-httponly.html; http://en.wikipedia.org/wiki/HTTP_co...e_and_HttpOnly

    Great posts by the way
  6. #19
  7. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Originally Posted by PaulGer
    This can be mitigated by setting $httponly in your call to setcookie().
    In case of an XSS vulnerability, the CSRF token can be read from the page with a simple AJAX call. So protecting the cookies won't help.

    And I wouldn't necessarily store the token in a cookie. If you store it in the session, it stays on the server and automatically expires as soon as the session gets deleted (the session cookie should always be set to HttpOnly, of course).
  8. #20
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2007
    Posts
    80
    Rep Power
    8
    I have a lot to learn it seems. I've been guilty of 3,4, and 5 it seems =/. I guess the more ya know. It's actually pretty good that I found this information because I do intend on having a site soon and it'll be nice to properly secure it.
  10. #21
  11. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2013
    Posts
    21
    Rep Power
    0
    Hi,
    Thanks very much for these 6 tips. In the future I will use these when developing applications/projects.
  12. #22
  13. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4124
    Originally Posted by Jacques1
    In case of an XSS vulnerability, the CSRF token can be read from the page with a simple AJAX call. So protecting the cookies won't help.

    And I wouldn't necessarily store the token in a cookie. If you store it in the session, it stays on the server and automatically expires as soon as the session gets deleted (the session cookie should always be set to HttpOnly, of course).
    Surely storing the anti XSRF token in a cookie completely bypasses the system as it ensures the token is sent (because the browser sends the cookie for the domain).

    It was my understanding that the purpose of the token was to ensure that the user was making a request from an authorised source (eg your website or web app) and that the token is used to authenticate the source as other sources (eg spoofing site) will not have the token (or not have the correct token)
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  14. #23
  15. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Originally Posted by Northie
    Surely storing the anti XSRF token in a cookie completely bypasses the system as it ensures the token is sent
    No, the token can generally be stored anywhere as long as it's not accessible to others. Could be the session, the database, a cookie, local storage -- whatever.

    What's important is that other people can neither read nor write the token, so they cannot forge a valid request. They cannot create a form with a valid token in it.

    Storing the token in the session is basically just for convenience, because it will expire together with the session. So no need for extra validations.

    It's also somewhat more foolproof than a cookie. Many users certainly aren't aware of how critical the XSRF token is, so a good social engineer might get them to hand out their token cookie. With sessions, there's no such risk.



    Originally Posted by Northie
    It was my understanding that the purpose of the token was to ensure that the user was making a request from an authorised source (eg your website or web app) and that the token is used to authenticate the source as other sources (eg spoofing site) will not have the token (or not have the correct token)
    That's not really the point. The source doesn't matter at all, so an XSRF token isn't a kind of "reliable referrer" or something.

    The point of the token is that's it's a secret. The only people who know it are you and your user, so only you two can make/prepare valid requests. Where that request comes from isn't important. If the user decides to send the request from his/her own site, that's perfectly fine.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  16. #24
  17. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4124
    I actually disagree with some of that, it reads to me like you're blurring the lines between session cookies (a cookie holding the session ID) and anti XSRF tokens.

    A XSRF relies on a user's trust in a browser so that the user performs an unintended (and usually unwanted) action on a service they are already logged into/have permssion to do

    If you put the token in a cookie then any cross site REQUEST attempt will cause the browser to send the cookies (including the current VALID token) - so the XSRF attempt succeeds. Thus, the token must NEVER be stored in a cookie - that's my point - it doesn't matter is an attacker can't read or write it, the browser has done it for them and all you've really done is added a second session cookie, pointless!

    The token NEEDS to be in two places - one on the server and one on the client; so that the server can identify the client. So at some point the server has to tell the client what the token is and at some point the client must tell the server what the token is. A non-cookie way to send the token back to server is in part of the POST request. A non-cookie way of sending the token to the client is to include it in every response (either as a JS variable or as a hidden input in each form).

    However, this could easily be ready by an attacker, so the token needs to change with every request and kept syncd between client and server. The concept being that an attacker will never have a valid token
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  18. #25
  19. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    You can only defeat an XSRF token if you actually know it. Your victim automatically sending it doesn't get you anywhere.

    OK, let's say I have stored my token in a cookie, and you want to forge the following request:
    Code:
    action=post_comment&article=1&text=...&xsrf_token=...
    How would you do it? Since you don't know the correct value for xsrf_token, you cannot set up your form. Yeah, it's in my cookie, but that doesn't help you at all. You have to know it.

    Your session approach actually suffers from the same "weakness" as cookies: The XSRF token is automatically available to the user as soon as he/she sends the session cookie. In your case it's available through the server sending it to the user, in "my" case the user brings his/her own token. There's no difference in that regard. As long as nobody knows the token, it's all the same.

    I'd still favor storing the token in the session (for the reasons mentioned above), but that's only for increasing security. The token does not have to be stored in the session. If you don't believe that, try an actual attack on a test system.



    Originally Posted by Northie
    However, this could easily be ready by an attacker, so the token needs to change with every request and kept syncd between client and server.
    A per-request token is difficult to implement. You'd have to sync the token accross different tabs/processes to make sure opening the same page in another tab doesn't expire the token of all previously openned tabs.

    I couldn't think of a solution from the back of my head. Do you?

    And I don't see why a per-request token is absolutely necessary. The XSRF token is (should be) as hard to "steal" as the session ID, so why do you think you have to change it more often than the session ID?
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  20. #26
  21. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4124
    I change the session ID and the XSRF token on every request and it works well.

    However, I hadn't considered the tabs/processes/windows issue...primarily because my app runs in just one browser window.

    All requests are by ajax and the response is always in JSON and always has the same structure. One of the object properties is the new token and the primary ajax wrapper method manages the appending of this to new requests.

    invalid tokens do not allow the request to complete and issue a warning to the user prompting them to reload the browser (which then syncs the tokens again)
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  22. #27
  23. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    So are you convinced now that cookies work just as well as storing the token in the session?

    Regarding the syncing: I'm sure this works fine in your special case, but for many standard sites, it's not an option to ask the user to reload the page whenever he/she switches tabs. This would kill the usability completely.

    And I still don't see the reason why I should even do that. It would rather make sense to change the session ID on every request (because when the session gets lost, all CSRF tokens are useless).
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  24. #28
  25. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4124
    So are you convinced now that cookies work just as well as storing the token in the session?
    No, at no point have I suggested that. Always the opposite

    So I think we must be at crossed purposed - I can tell you're a clever guy so I don't think you'd be so stupid as to put the token in the cookie. Maybe This site will explain things better than I can.

    The only need to reload the page is if an attack happens. By not changing the token any malware on a user's computer can fetch the current valid token and present a forged page with a valid token inviting the user to perform an unwanted task. Changing the session id (stored locally in a cookie) does not prevent this as the browser STILL SENDS A VALID SESSION ID

    If a user has the same site open in multiple tabs and is cross posting between tabs then I have to question the site and the user. I don't think that a web app running in one browser window is "special case" but probably the norm.
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  26. #29
  27. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Funny that you link to that page, because they mention a very similar approach on it:

    https://www.owasp.org/index.php/Cros...Submit_Cookies

    This approach consists of embedding the session ID in every form, so it's obviously less secure than using a separate XSRF token. But it still prevents CSRF attacks:

    Originally Posted by OWASP
    When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.
    And like I already said: Try an actual attack on the example request a gave you. You say that cookies don't work, so you should be able to write down a form for forging this request. What do you put into the xsrf_token field?



    Originally Posted by Northie
    The only need to reload the page is if an attack happens. By not changing the token any malware on a user's computer can fetch the current valid token and present a forged page with a valid token inviting the user to perform an unwanted task. Changing the session id (stored locally in a cookie) does not prevent this as the browser STILL SENDS A VALID SESSION ID
    You do realize that knowing the session ID makes all CSRF tokens useless?

    And if you have malware on your computer, it's all over, anyway. Anything you do could be intercepted, changed, redirected, whatever. No security on any website will prevent that.



    Originally Posted by Northie
    If a user has the same site open in multiple tabs and is cross posting between tabs then I have to question the site and the user.
    What? That's exactly how I use this forum and pretty much any other website I regularly visit.

    And even if you think it's weird, that's a bad reason to not allow people to do it. If you think you can tell your users what they can and cannot do with their browser, you're likely to lose them.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  28. #30
  29. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Damn, I can't edit the original posts.

    I was going to suggest the password_compat library instead of PHPass. It "emulates" the new password API that will be avaiable in PHP 5.5. So when PHP 5.5 is out, you can simply remove the library and use the native functions (unless the PHP developers mess them up again).

    Like PHPass, the library is a wrapper for the crypt() function, but it's easier to use (no classes, no objects), it has no stupid MD5 fallback, and the code is cleaner and more up to date (it uses built-in functions instead of fumbling with bits and bytes).

    But it requires PHP >= 5.3.7.

    Comments on this post

    • requinix agrees : added. PM me next time and I'll edit whatever you need
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

IMN logo majestic logo threadwatch logo seochat tools logo