SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 54
  1. #1
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Advanced security questions

    I am working on a secure note-taking web application. My goal is to make it the most secure note-taking web app available (I don't see a ton of competition, so I think this is attainable).

    Here is where I'm at thus far: examancer.com/exanotes/ (can't post the link since I'm newly registered here)

    I have developed this without aid, so some of the assumptions I have made regarding security may not be accurate or realistic. I was hoping some of the smart people here at SitePoint can read through the following security concepts I am relying on and tell me if they feel as confident in them as I do.

    I wanted very strong anonymity. To achieve this I hash and salt both the username and password before storing them in the database. A "user" on the site is not defined by a unique username... instead it is defined as a unique username/password combination (thus more than one user named "joe" can exist if they have different passwords). Plain-text usernames and passwords are never stored anywhere, but they are kept in-memory during the session. I use standard php sessions.

    Most importantly I wanted strong encryption, and I wanted it to work in such a way that even someone with direct access to the database and code base would not be able to read the notes stored by site users.

    To encrypt notes I take the plain-text password available in the session, I salt it (using a different salt then the one used for salting usernames and passwords for the 'user' table), hash it, and then use it as the encryption key to encrypt and decrypt notes to and from the database (using MySQL's built-in 256-bit AES_ENCRYPT() & AES_DECRYPT() functions). Once the user session is destroyed the password is no longer available so this encryption key cannot be generated. The encryption/decryption process does add latency compared to normal SQL, especially when doing full text searching, but the performance is still very speedy with a sane number of users.

    To implement the "remember me" feature for users who wish to stay logged in for an arbitrary length of time (currently 90 days) I once again use the plain-text username and password stored in the session, encrypt them using PHP's mycrypt and the RIJNDAEL_256 cipher, and then store them (as hex values) in a cookie on the user's machine. The key for this is site-wide and stored in a constant. Upon re-visiting the site the username and password in the cookie are decrypted, and the plain-text username/password is used to log the user in automatically.

    I know there are some potential issues on the user end since they will be transmitting a plain-text username and password to the site through my login form. I am hoping this issue is mitigated by users who choose to access via SSL (which is available).

    I also recognize that having the plain-text username and password floating around, even if only in a temporary session variable, might be a potential weak point.

    Lastly, I can see that using a single site-wide key for encrypting/decrypting the username and password for "remember me" cookies is another possible weak point. However, this would probably require that an attacker have access to both the server and the client machine to exploit this.

    I am looking for any commentary anyone might care to offer regarding the security for this site. I would welcome any criticism and would welcome it even more if accompanied by suggestions.

    Once the tool is more polished and the security more rigid I plan to release it as an open source project, both to further "vett" the code and because of the resources required to operate the service for a large number of users (my shared hosting account probably wouldn't scale very far). I figured it would be simpler to let the paranoid people who want this kind of security run it on their own server if they wish.

    If anyone would like a look at the code, or, even better, would like to help with the project, please let me know.

    Thank you,
    -Carl

  2. #2
    Use The Cloud
    Join Date
    Jan 2006
    Location
    Boise, ID
    Posts
    556
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by examancer View Post
    I wanted very strong anonymity. To achieve this I hash and salt both the username and password before storing them in the database. A "user" on the site is not defined by a unique username... instead it is defined as a unique username/password combination (thus more than one user named "joe" can exist if they have different passwords). Plain-text usernames and passwords are never stored anywhere, but they are kept in-memory during the session. I use standard php sessions.
    So what error message do you throw when user "joe" tries to change his password to "Iamgod", but it already exists?

    "A user with that password already exists. (But please don't login to their account)"
    Brad Hanson, Web Applications & Scalability Specialist
    ► Is your website outgrowing its current hosting solution?
    ► PM me for a FREE scalability consult!
    ► USA Based: Available by Phone, Skype, AIM, and E-mail.

  3. #3
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,789
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    The first step in making it more secure is to make the user names unique. Combining the uniqueness with the password is significantly reducing the security of the password.

    Hashing the user name doesn't make the user name any more secure than storing it as plain text since someone can easily find out if a given user name exists or not by trying to create it. Where the user name and password together are what you are testing to be unique then anyone trying to break in effectively has one field containing both values to break instead of two separate fields.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  4. #4
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    bhanson, it will be made explicitly clear to the user when I enable the "change password" feature that the "change password" may not work as they expect. Instead of changing your account credentials, the "change password" feature is instead more like a "mass transfer" feature transferring all of the contents of your account into another. I will inform the user that they may want to ensure the account is not already populated with notes if they do not want the notes from their current account mixed with the notes of the receiving account.

    felgall, I respect your knowledge and your post history shows you know what you are talking about. I originally chose to hash the user names to prevent any personally identifiable information from ever being stored in the database. Usernames are often easy to use to identify people, right?

    "Hashing the user name doesn't make the user name any more secure than storing it as plain text since someone can easily find out if a given user name exists or not by trying to create it"
    -- for most sites this would be true, but I actually allow multiple accounts under a single username. If an attacker trying to check if a specific username is registered on the site attempts to register under that username they will be allowed to, even if the person they are looking for really is registered. Unless the attacker is able to guess both the correct username and password they will not be able to access the account. There is never a case when a registration is rejected. In fact, in its current configuration, there is no "registration" to speak of. You just log in. If the account doesn't already exist, one is created for you. If the account does exist, you are shown the contents. Users are informed they have given the wrong password by the fact that their notes are not there. I may make some UI changes for new accounts so it makes this more clear.

    Is there something wrong with this concept of a "find or create" login method?

  5. #5
    Use The Cloud
    Join Date
    Jan 2006
    Location
    Boise, ID
    Posts
    556
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Seems bugged.

    Login to ( joe / asdf ) and try to edit.
    Brad Hanson, Web Applications & Scalability Specialist
    ► Is your website outgrowing its current hosting solution?
    ► PM me for a FREE scalability consult!
    ► USA Based: Available by Phone, Skype, AIM, and E-mail.

  6. #6
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bhanson View Post
    Seems bugged.

    Login to ( joe / asdf ) and try to edit.
    You've been playing with some odd characters, causing the textarea not to render. Must have been something I didn't properly escape before taking the note content and putting it into the textarea. I'll look into it. Thanks for finding the bug :-)

  7. #7
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I see you were really testing out the security there. Well everything is properly escape as far as the database and PHP are concerned... but there isn't a lot of code there keeping the user from breaking the HTML (which is what you did with your attempts to initiate script with <? ). I'm not even sure if there should be much keeping the user from breaking the HTML since they are the only ones who can see it. I should at least do some basics though so users who like to make use of < and > symbols don't see their notes tragically stop being editable.

  8. #8
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just wondering, what do you envision as the use for this "secure note-taking application"? I'm not trying to take away your steam, just trying to understand the motivation behind it (like why would someone want something super super secure like you want to make yours, when standard security measures like SSL and hashing might be OK?).

  9. #9
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,789
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by examancer View Post
    -- for most sites this would be true, but I actually allow multiple accounts under a single username. If an attacker trying to check if a specific username is registered on the site attempts to register under that username they will be allowed to, even if the person they are looking for really is registered.
    Doing that is effectively making the username and password into one field in so far as trying to break into an account is concerned. Instead of needing to first find a username and then a password they effectively just have to find a working password just with the password split between two fields instead of in one field (which doesn't really affect the security by much).

    As already pointed out one of the additional security holes that you have created by doing away with unique usernames is that if two people choose the same username and then choose the same password they end up sharing the same account. That in itself is enough of a problem to start over.


    If you really want to make the usernames more secure you could generate usernames for people rather than allowing them to choose for themselves. It shouldn't matter that much though since the most that anyone should be able to work out by having the usernames able to be selected by the person signing up and stored in plain text is that someone will be able to see that someone is using that username. If someone consistently uses the same username everywhere that allows it then someone might figure out all the places they have signed up to but that should be about as much as they can get from that and besides which not all uses of a given username are necessarily the same person.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  10. #10
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Czaries View Post
    Just wondering, what do you envision as the use for this "secure note-taking application"? I'm not trying to take away your steam, just trying to understand the motivation behind it (like why would someone want something super super secure like you want to make yours, when standard security measures like SSL and hashing might be OK?).
    Well, I started thinking about building a simple note-taking interface for myself. I asked a few friends if they would have any interest in using it, and some of them shied away at the idea that I or someone else could read their notes, especially one friend who wanted to use it to keep a journal but didn't want to risk someone getting into it.

    I thought it would be nice if there was a simple and quick online solution to note-taking or journal-writing where you could actually have some faith that no one can get to your notes.

    I don't know if there is much of an audience, but I figure there is some. Its not a complex app. Just simple and (potentially) very secure.

  11. #11
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    felgall, As you said the non-unique usernames shouldn't affect security that much. I really like the idea, and here's why... (which may partially mitigate the "start over" problem)

    A user is only as secure as they chose to be. I think the audience for a tool like this would likely know that. I know this model doesn't fit the standard user/account/password model. This site is a place for users to hide stuff. If they choose very unique usernames and passwords they can hide things so well that they will never* be found. It can also be a private bulletin board if they chose to leave things for others to find. I wouldn't expect a user to have just one accounts. I wouldn't be surprised if some users had 10. They are disposable. Password changes are just like moving your stuff to a new hiding spot. You would be prompted for a new username and password.

    I am greatly appreciative of the feedback. I do understand what you are saying and the input is useful. I have a lot of thinking to do.

  12. #12
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,789
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    If you are hashing the usernames then you are replacing their hard to guess probably unique usernames with easier to guess more likely to clash versions. It would be a lot more secure if you didn't hash the usernames.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  13. #13
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    The way I see it, examancer, you are over complicating something so simple. If you want to keep data hidden, don't show it to anyone but the desired user. If the message is public don't attach a username to it. There doesn't need to be this complex user management system.

    Second, encrypting the message with a unique key for each users would also be advisable. Simplicity is beauty, complicity is a nightmare.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  14. #14
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    +1 for the 'use a unique username' thing. If you are going the way you suggest, you might as well only have a password and do away with the username part. The whole point of a login system is that the username is for identification (ie, should be unique, but also public) and the password is for authentication (ie, private, hard to guess, encrypted etc). If you are taking away the purpose of the username, you might as well not have it.

    See: http://www.b3tards.com/uploader.php - they operate on a password alone - the more obscure your password, the less likely someone else is to stumble across it, but there is ALWAYS that risk.

  15. #15
    SitePoint Addict
    Join Date
    Jan 2008
    Posts
    203
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    dont run on shared hosting or vps, get your own server

    that would have alot of attack vectors disappera

  16. #16
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ionix5891 View Post
    dont run on shared hosting or vps, get your own server

    that would have alot of attack vectors disappera
    I think a managed VPS would be just fine. There's no need to bust your budget on hardware and specs you won't need for a long time. Just remember to do your own data backups in a secure fashion as well (never rely on the host's backups!).

  17. #17
    Grumpy Minimalist
    Join Date
    Jul 2006
    Location
    Ontario, Canada
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's good to know that someone is actually doing security properly, unlike most of the "secure" sites floating around right now. I'd suggest keeping the multiple usernames for the reasons you have already cited, although I'm pretty sure that you've already rejected most the advice that's been given so far (correctly IMHO).

    For this system site-wide SSL is a MUST for ALL communications, not just the login. I'm guessing that you can get away with using a self-signed cert since your primary audience will either be hosting this themselves or completely understand what a self-signed certificate is.

    Get a dedicated server as was suggested; a shared server exposes you to the unencrypted session variables problem you noticed, as well as all kinds of other issues like code hooks, packet sniffs, or memory scans (the vulnerability magnitude depends on the security of your host, of course).

    When using sessions make sure that you give this manual page, as well as the session fixation attachment multiple reads.

    For the "remember me" feature you need some way to ensure that the cookie does in fact expire after 90 days (you didn't mention any method that you were using), not just the cookie's expire feature (an attacker could steal the cookie and have permanent login capabilities without knowing the username or password). Consider hashing the cookie and encrypting that with an asymmetric private key to generate a "certificate" to ensure the cookie wasn't tampered with. Store the expiry date in the cookie text itself so it cannot be modified due to the certificate. Also, regenerate the cookie on each successful auto-login and invalidate the previous cookie so it cannot be stolen. The use of an asymmetric private key here underscores the need for a dedicated server.

    You didn't mention what hashing mechanism you were using. As long as it isn't MD5 (especially in light of current events with SSL being partially broken) you should be fine, although I'd recommend using SHA-256 at a minimum unless you can spare enough space for SHA-512.

    Also make sure that you post all of the security techniques that you are using on the site so that users can be reassured, in addition to your open-sourcing and a good privacy policy.

  18. #18
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is all fantastic information. I can't tell you how much I appreciate this.

    I am definitely taking to heart the suggestions made. Some of them I will take and some I will leave. I think I am going to keep the username/password scheme I have come up with. People are USED to having a username/password and prefer that over a single password field, even if that is what it amounts to. I would rather jump through all the hoops this scheme makes me jump through than provide people with an easy mechanism for determining whether or not a certain username is being used here (That information alone can be damning. ex: A guy checks a really unique username his girlfriend always uses. It says its taken. He knows she is using the site and that she is hiding something from him. Unacceptable.). Stormrider was right when he said "the username is for identification"... the audience of this site wants anonymity. I want as little identification as possible, just secure authentication.

    logic_earth said "encrypting the message with a unique key for each users would also be advisable". That is exactly what I'm doing. Each user's own password is used to encrypt their notes (after being salted and hashed of course).

    Tarh, I would really like to thank you most of all. Your advice will really help. I will devour all of the session information you linked to and really examine that problem to see if I can make that more secure. I want users to be able to run my app on a shared host if they have to, and I want it to be at least be "difficult" to attack, even if the security is more through obscurity than actual security.

    I am going to change some things about my cookie system, based on your advice, to make sure the server expires them after a set time, not just rely on the client. I will also set up a scheme to mass-expire cookies if need be and also to occasionally update the encryption key (without breaking the outstanding cookies).

    Tarh, I am actually using md5(). It was familiar and I figured that if used with good salts I shouldn't have much to worry about. If an attacker got the user/pass hashes and attempted to create a collision to login, if that collision wasn't the actual username & password, the notes would not be able to be decrypted (since it builds the key from the actual password, not its hash). However, I don't want any weak points and it does appear the problems with MD5() are only going to get worse. SHA-256 it is :-)

    I am already trying to document the processes I am using into some nice flow charts for users, and I do plan to release the source code for vetting when it is more secure.

    This has been a great dialog so far. I am really glad I posted here. Thanks.

  19. #19
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Tarh, do you know of any decent PHP implementations of SHA-256? PHP's sha1() looks like it may use some older algorithm.

  20. #20
    Grumpy Minimalist
    Join Date
    Jul 2006
    Location
    Ontario, Canada
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  21. #21
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    HAHAHA! I feel dumb. Thanks again.

  22. #22
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Wait... you're hashing the notes?

    Then how are you going to get them back again!?

    Encryption/Decryption is fine, but hashing something you want to retreive is just insane.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  23. #23
    Grumpy Minimalist
    Join Date
    Jul 2006
    Location
    Ontario, Canada
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    Wait... you're hashing the notes?
    No, he's not. Read the OP, which explains exactly what is happening and where the hashes are being used.

  24. #24
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Examancer
    That is exactly what I'm doing. Each user's own password is used to encrypt their notes (after being salted and hashed of course).
    Unless he means the salted+hashed password is used as the key.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  25. #25
    Grumpy Minimalist
    Join Date
    Jul 2006
    Location
    Ontario, Canada
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's what he's doing, it says so in the OP.


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •