SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 54
  1. #26
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, hash(password.salt.pepper) is what I'm doing to build the encryption key for each user :-) This is only kept for the session and never stored anywhere, so this should be at least somewhat secure. I have been given a LOT to think about though.

  2. #27
    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)
    I still don't understand what you plan to do if a user 'stumbles' across a valid username/password combination, or tries to change their password to an existing one? Suddenly a user has access to someone elses notes, and bang goes any illusion they had that this was a secure application. You said something about informing them that they would get unexpected behaviour when changing the password - this might confuse people, people are going to wonder why this is the case. Then there goes the illusion of a 'standard' login system as well, which is the effect you are trying to present, and why you aren't using password alone.

    Have you thought about how are you going to prevent this type of thing, which is more likely to happen with the system you have proposed, rather than a standard user/password combination?

  3. #28
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    I still don't understand what you plan to do if a user 'stumbles' across a valid username/password combination, or tries to change their password to an existing one? Suddenly a user has access to someone elses notes, and bang goes any illusion they had that this was a secure application. You said something about informing them that they would get unexpected behaviour when changing the password - this might confuse people, people are going to wonder why this is the case. Then there goes the illusion of a 'standard' login system as well, which is the effect you are trying to present, and why you aren't using password alone.

    Have you thought about how are you going to prevent this type of thing, which is more likely to happen with the system you have proposed, rather than a standard user/password combination?
    If users chooses strong usernames and passwords this shouldn't be an issue. This is already a risk now where someone could stumble into someone else' account on pretty much any site requiring registration. However, it would likely be more deliberate with other sites since they would have to chose "login" instead of "register"... but if they aren't SURE if they regsitered or not and are just trying to login to an account that may or may not be there, they could stumble in on any account with the same ease. The level of security given to a user is contingent completely on the level of uniqueness in their user/pass combo. With many people having to keep track of 8 or more passwords for work/banking/investing/etc, all with different expirations and strong alphanumeric requirements, I think people are getting it in their heads that they play a big role in determining how much security they have. With this site, they are potentially given even more security, privacy, and anonymity with the trade off that they play an even bigger role in determining how much security they really get.

    Is it a trade-off? absolutely! But, I think it is worth it to help guarantee the anonymity and disposable nature of these accounts.

  4. #29
    Grumpy Minimalist
    Join Date
    Jul 2006
    Location
    Ontario, Canada
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You could artificially break the system down into "login" and "register" features. They'd essentially be the same code, but they would error when attempting to implicitly perform the task made explicit by the other button. So, if somebody clicks "login" and enters a non-existent combination, they'll get an error. If somebody clicks "register" and enters an existent combination, they'll get an error.

    In addition, enforce a strong password policy to make sure that people are using the system properly. I'd also suggest providing a link to a secure password generation website on the same page to push people in the right direction.

    As an aside, I currently run a system which allows multiple identical usernames with different passwords, and I've never had any complaints about losing an account to somebody guessing.

  5. #30
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tarh View Post
    As an aside, I currently run a system which allows multiple identical usernames with different passwords, and I've never had any complaints about losing an account to somebody guessing.
    That is encouraging. Thanks.

    I haven't decided whether or not to break it up into login/register. There is nothing in my architecture preventing that. I obviously know when its a new account or an existing one.

    I will definitely try to push my users in the right direction and will most certainly point them to resources like the random password generator you provided. Might even go a step further and have a button to generate a password for them and drop it right into the login box (shown of course). Thanks.

  6. #31
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Tarh View Post
    That's what he's doing, it says so in the OP.
    No it doesn't - it says that the notes are encrypted using the hashed password as the key.

    There is a lot of difference between one way hashing and two way encryption.

    It would be more secure if the plain text password rather than the hashed version were used as the encryption key since then the key to decrypt the notes wouldn't be stored with the notes but presumably once the OP realises that storing the decryption key along with the encrypted content isn't such a good idea they'll fix that part (if they haven't already).
    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="^$">

  7. #32
    Grumpy Minimalist
    Join Date
    Jul 2006
    Location
    Ontario, Canada
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    No it doesn't - it says that the notes are encrypted using the hashed password as the key.
    When I said:

    Quote Originally Posted by Tarh View Post
    That's what he's doing, it says so in the OP.
    that was in response to:

    Quote Originally Posted by arkinstall View Post
    Unless he means the salted+hashed password is used as the key.
    which meant I was verifying that:

    Quote Originally Posted by examancer View Post
    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
    or, in other words:

    Quote Originally Posted by felgall View Post
    it says that the notes are encrypted using the hashed password as the key.

  8. #33
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    It would be more secure if the plain text password rather than the hashed version were used as the encryption key since then the key to decrypt the notes wouldn't be stored with the notes but presumably once the OP realises that storing the decryption key along with the encrypted content isn't such a good idea they'll fix that part (if they haven't already).
    The key to encrypt/decrypt the notes isn't stored anywhere. It can only be generated when the user is successfully logged in and their plain-text password is available. Then the pass is salted and hashed to form the decryption key. When they log out, the session is destroyed, and the key cannot be regenerated until they log back in and the password is available again. The notes database table has nothing more than encrypted notes, timestamps, and the user_id of the user that created it.

  9. #34
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by examancer View Post
    The key to encrypt/decrypt the notes isn't stored anywhere. It can only be generated when the user is successfully logged in and their plain-text password is available. Then the pass is salted and hashed to form the decryption key. When they log out, the session is destroyed, and the key cannot be regenerated until they log back in and the password is available again. The notes database table has nothing more than encrypted notes, timestamps, and the user_id of the user that created it.
    Hashing the password and then not actually keeping the hash isn't really achieving anything except to slightly lower the security since the possible hashes are a small subset of the possible passwords that map to those hashes. You'd still be better off using the password itself as the encryption key rather than hashing it first.
    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. #35
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    Hashing the password and then not actually keeping the hash isn't really achieving anything except to slightly lower the security since the possible hashes are a small subset of the possible passwords that map to those hashes. You'd still be better off using the password itself as the encryption key rather than hashing it first.
    You are correct. However, I don't place any arbitrary limits on the length of passwords and there are limits on the length of encryption keys, so instead of using that as the length limit for passwords I instead just hash them so they are a predictable length. Do you think it would be more secure to truncate the passwords or something? Or limit the size of them to the max allowable key size?

  11. #36
    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)
    Quote Originally Posted by examancer View Post
    If users chooses strong usernames and passwords this shouldn't be an issue. This is already a risk now where someone could stumble into someone else' account on pretty much any site requiring registration.
    It's far less likely though, because a username is only tied to a single password. In this case, the 'popular' usernames (eg 'chris' or 'joe' as you say) are going to have far more registrations, and therefore more passwords attached to each, giving a much higher chance of a clash.

    Also, although people who understand security / know what they are doing will choose a strong username/password combination, quite a lot of people are going to pick simple ones - and these are more likely to be the 'popular' usernames as above. I think you will get a lot of common usernames, with quite a few easy passwords on each.

    I'm not trying to change your mind, just trying to make you aware that it's a possible issue!

  12. #37
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    Also, although people who understand security / know what they are doing will choose a strong username/password combination, quite a lot of people are going to pick simple ones - and these are more likely to be the 'popular' usernames as above. I think you will get a lot of common usernames, with quite a few easy passwords on each.
    This is definitely a fear of mine. User education and clear UI for this app are not going to be trivial. I am going to have to spend a lot of time making sure all users are aware of the strengths and weaknesses of this authentication scheme.

  13. #38
    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)
    Why don't you want the uername to be unique?

    In all honesty that is more secure, much more widely used and much easier to implement.

    The downsides of possible data clashes is more than the benefit you'd get, if any, from using unique usernames and passwords.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  14. #39
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    Why don't you want the uername to be unique?

    In all honesty that is more secure, much more widely used and much easier to implement.

    The downsides of possible data clashes is more than the benefit you'd get, if any, from using unique usernames and passwords.
    The claim that it is "more secure" to use a unique username is somewhat dubious (I would be inclined to argue the opposite). That would be tough to prove. What is easy to prove is that using a unique username can decrease anonymity as it provides an easy mechanism to verify if a given username is registered on the site. I want usernames obscured enough that user anonymity is protected both from attackers and even from me (the site administrator).

    With either approach the level of security is determined by the strength of the username and password the user chooses. Non-unique usernames allow me to skip the registration process (which seems counter-intuitive for an app designed for anonymity... "register here, we won't tell anyone"?) and allow the accounts to appear more disposable from a user perspective, which I feel further encourages users to use strong login credentials. Basically, the login method is SO simple that they SHOULD be scared that someone could accidentally stumble into their account... theoretically compelling them to use good user/pass combos so that has no chance of happening.

    This is not the first service ever to have non-unique usernames. Tarh pointing out that he runs a service with non-unique usernames and has not heard of any problems with it is further encouragement that this will not be the deal-breaker many seem to assume it is. Users interested in this level of security are probably not as dumb as the average user, who might have a problem with this... the average users are probably fine with Google Notes or whatever they are using. If they get paranoid down the road and want try out my app, they will have learned by then the need for a strong user/pass.

    As said, I will augment this will education as much as possible.

    Not trying to be argumentative. I appreciate the criticism. If I couldn't respond with an adequate defense of this scheme then I would need to start re-thinking it.

  15. #40
    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)
    Quote Originally Posted by examancer View Post
    This is definitely a fear of mine. User education and clear UI for this app are not going to be trivial. I am going to have to spend a lot of time making sure all users are aware of the strengths and weaknesses of this authentication scheme.
    There's a sort of contradiction here - you said you wanted usernames and passwords in order to look like a more 'regular' login system, but you are also going to inform your users and educate them on how to use your different authentication scheme? If the users are going to know it works differently, is there any need to try and emulate the regular login system?

    I agree with Jake about the security though - I believe a standard username/password combination will be more secure. That's not to say that you can't make this system secure enough, just that there are some problems to think about - ie, in the event of a clash, what do you do?

  16. #41
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Having a username and password, even when the username is not unique, allows users to continue using the username and password schemes they have been using for years. Most users, especially the audience of such a secure service, have different "systems" they come up with for generating and remembering user/pass combinations they use at various places. I have a system where I choose one of a few different usernames depending upon what type of service it is, and then generate a password based on a couple different patterns and how much security I want for the service. I am sure many of you use similar approaches when picking user/pass combinations. I want users to be able to continue to use their long-time well-trusted login methods. As long as the user HAS a good system for generating username and password combos then they will have equally secure authentication with this app, and additional anonymity. The only users affected by possible user/pass collisions are those with poorly thought-out user/pass combos... those same uninformed users have poor security with every service they use and really aren't the intended audience for this app.

    This discussion is definitely making me think about all the approaches I can take to educate users who need education. In addition to displaying notices on initial account creation I may add additional "annoyances" in the UI to let the user know when they are using an easy to guess user/pass combo. I can compute the strength of the user/pass and let them know it is insecure when below a certain threshold.

  17. #42
    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)
    The claim that it is "more secure" to use a unique username is somewhat dubious (I would be inclined to argue the opposite)
    Ok, so I have the username 'dave' with the password '1asd3g1gsa3oyh3d1', and want to change it to '3he5h15hr35g'. Another guy has that combination, and your system wants to tell me an error occured? Errors are to be avoided in the system, not given to the user - who would now try login to the other dave's profile to check if their password was changed or not.

    And what about the benefits of the username? Say you want to expand and have a forum on the site with users automatically registered - problem there.

    What if someone emails you with their username and forgot their password containing very important notes - and has information to prove who they are. Well, you can't change the password because you don't know which one of the twenty-odd users with identical usernames is them.

    What if you have a comments system - how is anyone going to know who posted what? Guys with rep could be ruined by a 12 year old with the same post. That would look confusing.

    Not to mention what happens if someone spends alot of time putting notes on, and someone logs into their account due to a slip of the key. The user, bewildered about all these notes suddly appearing on their page, deletes them. Damage done.

    Brute forcing would be so much easier. Think about it this way - a username that's very popular (say 100 accounts) will be 100 times easier to bruteforce ONE of the accounts.

    You claim that this is more secure than google notes? I have a feeling that's VERY secure - it's made by people with years of experience with security, and is based on proven authentication techniques.

    I'm not trying to put you or your idea down here, just making valid points. I don't think the idea will work as well as you think.

    This discussion is definitely making me think about all the approaches I can take to educate users who need education
    Users are stupid - and you can't stop that. You will always have people with the password 'a' or 'password' - because they don't see a problem with it.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook.

    You need to make an application that's easy to use, and anyone can use. Trust me, no one will use a system which requires them to learn, without offering any real advantages.

    What I do like, however, is your point about using the username/password combinations they've always used. Not enough of a benefit by far to win me over though
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  18. #43
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    The original poster seems to believe in "security through obscurity" since that is the only real difference between their proposal and an equivalent conventional setup. Since there has been no mention whatsoever of the actual security measures that would prevent someone from attempting to break into an account it is impossible to say whether the system would be more or less secure than a more conventional system since it all depends on the actual security features that are used.

    How secure the obscurity aspect of the system is depends on how many alternative values there are that need testing to find the right one to break in and the process of hashing is one which by its very nature reduces the range of values thus lowering the security.
    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="^$">

  19. #44
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    These are all good points. I have equally good answers to some of them

    Quote Originally Posted by arkinstall View Post
    Ok, so I have the username 'dave' with the password '1asd3g1gsa3oyh3d1', and want to change it to '3he5h15hr35g'. Another guy has that combination, and your system wants to tell me an error occured? Errors are to be avoided in the system, not given to the user - who would now try login to the other dave's profile to check if their password was changed or not.
    That seems incredibly unlikely as those are both very strong passwords. Those users would have a better chance of each being struck by lightning then having a user/pass collision. There would be no error given... it will be made explicitly clear to the user that "change password" is really a mass transfer system. I would have to decrypt all of their notes, and then re-encrypt them using the new credentials. I would encourage them, if they think the user/pass might be in use, to check the receiving account first to ensure it is empty. If it is not empty, notes from the current account will simply be merged with notes in the receiving account.

    Quote Originally Posted by arkinstall View Post
    And what about the benefits of the username? Say you want to expand and have a forum on the site with users automatically registered - problem there.
    Moot point. A core feature of this site, and the entire reason usernames are non-unique, is anonymity. If there ever was a forum I don't think my users would want to post there under their current username anyways. I would probably use a separate login even if the usernames were unique to improve anonymity. However, I do not foresee a forum. It is not really appropriate for this app.

    Quote Originally Posted by arkinstall View Post
    What if someone emails you with their username and forgot their password containing very important notes - and has information to prove who they are. Well, you can't change the password because you don't know which one of the twenty-odd users with identical usernames is them.
    Even if I wanted to, password recovery is not possible when the notes are encrypted using the user's password. I could get them back into their account, but they would no longer have access to any of their content. Even if I changed the design and login scheme I don't see any way I could offer a password recovery system while still giving users some level of confidence that their notes are encrypted in such a way that I can't access them. If I could reset their password without breaking access to their notes then there is no reason I couldn't gain access to their notes. Do you have a different encryption approach that would allow me to honestly tell users I can't see what they are writing and still allow for password recovery? I have thought about this for a long time and haven't come up with anything.

    Quote Originally Posted by arkinstall View Post
    What if you have a comments system - how is anyone going to know who posted what? Guys with rep could be ruined by a 12 year old with the same post. That would look confusing.
    Great feature for a social site. This isn't digg or facebook though. This is a secure and anonymous note taking service. Social features like that are the opposite of anonymity. Horrible feature for THIS site.

    Quote Originally Posted by arkinstall View Post
    Not to mention what happens if someone spends alot of time putting notes on, and someone logs into their account due to a slip of the key. The user, bewildered about all these notes suddly appearing on their page, deletes them. Damage done.
    They should have picked a stronger user/pass like I told them too This is for paranoid people to hide stuff, not grandma to sign up with grannyassword1. I believe the assumptions I am making about the target audience are accurate, which makes this a virtual non-issue.

    Quote Originally Posted by arkinstall View Post
    Brute forcing would be so much easier. Think about it this way - a username that's very popular (say 100 accounts) will be 100 times easier to bruteforce ONE of the accounts.
    ...which presumes you could even identify a popular account. Plus, brute force is pretty easy to detect and thwart. I am already working on account creation throttles (since invalid user/pass combos result in a new account) limiting new accounts to something like 1 every 2 minutes from a specific IP and 1 every 30 minutes for an existing username (or userhash as it were). That should slow things down for an attacker attempting to exhaust an enormous key space, likely made much larger by the fact that my users are paranoid.

    Quote Originally Posted by arkinstall View Post
    You claim that this is more secure than google notes? I have a feeling that's VERY secure - it's made by people with years of experience with security, and is based on proven authentication techniques.
    I am sure google uses the latest and greatest authentication and data protection techniques. However, that is only one aspect of security. Like pretty much every other google service, the notes you store are indexed for keyword ads and I'm quite sure they are stored in plain text in whatever database they reside. No normal person could ever get at them, and maybe not even a determined hacker, but the Google Notes DBA or whomever has database access could obviously look at them if they were interested. The idea with this service is that I intend to have a secure authentication system, as well as a secure method for storage (through encryption). There is a lot to be said for a system secure enough that even its operator cannot eavesdrop. The only thing stopping google from reading your dirty emails or secret notes is policy. What stops me is very strong encryption. That is piece of mind that google can't really offer.

    Quote Originally Posted by arkinstall View Post
    I'm not trying to put you or your idea down here, just making valid points. I don't think the idea will work as well as you think.
    You are making valid points. This scheme would not work for many other services, and many of the points you have made make that clear. However, for this service it still seems like a good fit. Possibly the best fit.

    Quote Originally Posted by arkinstall View Post
    You need to make an application that's easy to use, and anyone can use. Trust me, no one will use a system which requires them to learn, without offering any real advantages.
    There is nothing to learn if you are already the paranoid type I am targeting. Login as you normally would and everything will be OK. It is only the average users, who weren't really the target audience but stumbled in, that will need to be given some not-so-gentle nudges in the right direction when they use insecure credentials.

    Quote Originally Posted by arkinstall View Post
    What I do like, however, is your point about using the username/password combinations they've always used. Not enough of a benefit by far to win me over though
    You're not paranoid enough... yet

  20. #45
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    The original poster seems to believe in "security through obscurity" since that is the only real difference between their proposal and an equivalent conventional setup.
    Strong encryption is more than "security through obscurity". You are right though... the devil is in the details. I can talk all I want about concepts but unless the end result is as secure as I say it is, then it is meaningless. I think the approaches I am taking to authentication and database security are real, tangible, and effective. In its current state, an attacker with direct DB access could do little more than delete data. Some flaws have been pointed out in my session implementation, but are mostly mitigated by SSL. However, I will make improvements there regardless and am aiming for real security there as well. Where I do take the "security through obscurity" road is with some of my approaches for making the app difficult to attack by other users on a shared hosting environment. Without any control over the host environment there is very little I can do with actual security there (besides the aforementioned strong encryption), but I hope to obscure session data and other pieces of the application as best I can to offer as much security AND obscurity as is practical in a very limited environment.

    I'll be back with the code when it is more releasable so my actual implementations can be dissected as much as my concepts have been (which I really have appreciated!!!).

  21. #46
    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)
    If I was a typical user and that paranoid about my notes (which, doesn't really seem that big a deal to keep secure) I'd keep them on a word document and take it with me on a memory stick The internet cannot be trusted!!!! (In the eyes of these users).

    When I have an idea that may seem great, but people bring up issues with it, I usually end up defending it for two reasons. One is because I'm really stuborn, but mainly because I don't want to undo the progress so far.

    That's a big mistake, and usually ends up in a complete rewrite.

    Please, for your sake, make sure you aren't doing the same. If your points are based on trying to find retaliation rather than underlaying key points that have been consistent throughout, make the necessary changes before it's too late.

    If you are still confident that this is the right move, feel free to go ahead
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  22. #47
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by examancer View Post
    Strong encryption is more than "security through obscurity".
    I was referring to the encryption key itself which I think would be the weak point in your setup if you use a hash for the key as that severely limits the possible values that the key can have and you are therefore relying on people's not knowing that you are using a hash as the key in order to keep them from cracking the key a lot more easily than they'd be able to crack it if it were not a hash.

    The overall security of any system is only as good as the measures that you have in place to prevent someone obtaining a user/password to get in. Where a hash is used as the key a brute force attack is always a possibility and so you need security in place to prevent that from happening.
    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="^$">

  23. #48
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    felgall, you may be on to something there. You said that before but I never really got a response to what you thought about the fact that the password can be longer than the maximum key length. Is truncating a long password a better solution? Is limiting the password to the max key length better?

    Is the weakness in using a has based on the fact that hashes are usually hex values? What if I used a raw binary hash? That would potentially allow a wider range of values then a user can possibly input, right? I don't know if that would have other disadvantages.

    I took the easy route of using a hash so I didn't have to deal with the decision of whether to truncate or limit long passwords, but if the hash is a tangible weakness then I'll take another route.

  24. #49
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by examancer View Post
    No normal person could ever get at them, and maybe not even a determined hacker, but the Google Notes DBA or whomever has database access could obviously look at them if they were interested. [...] There is a lot to be said for a system secure enough that even its operator cannot eavesdrop. The only thing stopping google from reading your dirty emails or secret notes is policy. What stops me is very strong encryption. That is piece of mind that google can't really offer.
    That too is a moot point. With a little determination, you could also read the notes. You've got every little peace of information you would need for decrypting, thus you can decrypt it, thus you can read it in plain-text. Although I like the idea of encrypting the notes, stating that you can never read them is just a false notion of security. I think I'd trust Google's policy more than I would trust your encryption, for the reasons stated above.

    On the whole user/pass debate, I'm with the "conventional" people around here. It makes no sense to allow multiple people with the same username and it will ruin your change to extend the software to make it do something besides taking notes. Also: I tend to agree with felgall: security is in more than just user/pass combinations. It's the incorrect login attempts you have to be worried about and things such as session hijacking.

  25. #50
    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)
    Quote Originally Posted by webaddictz View Post
    It's the incorrect login attempts you have to be worried about
    ..but this system has no concept of incorrect logins. You can't have an incorrect login.

    Quote Originally Posted by examancer View Post
    That seems incredibly unlikely as those are both very strong passwords.
    Those passwords were just provided as an example - your users are very likely to use far weaker passwords, even likely dictionary words - no matter much education you give.

    I still think if you are going to do this, having a password on its own would be better - this would at least force them to think about using a secure password, rather than putting in their 'same old information' like they are used to everywhere else.


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
  •