SitePoint Sponsor

User Tag List

Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 96
  1. #51
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Most people would not do well with 50 character passwords so it really is not practical. Why not use a cypher that can protect passwords of lengths and complexity that they can remember?
    ictus==""

  2. #52
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,862
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    Maybe I didn't write about them above but I din't forget about brute force attacks, that's why I said using long passwords. If a password is long enough then it would take very long to brute force it even with md5. The question is how long the password should be - but if it's around 50 characters of mixed types then I think it would be extremely difficult to use brute force.

    With any hash the length of the password doesn't make any difference - it is the length of the hash that determines the maximum number of values that you'd need to try with a brute force attack. They don't have to find the real password they just need to find one that matches the hash.
    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="^$">

  3. #53
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ServerStorm View Post
    Most people would not do well with 50 character passwords so it really is not practical. Why not use a cypher that can protect passwords of lengths and complexity that they can remember?
    Of course, I'm all for using best cyphers for this purpose, I was just wandering if very strong and long passwords are safe when stored using a simple unsalted hash. This appears to be true, however I don't think it's true for md5 as it can be broken (collisions can be found) but it's a different subject. This fact can be important for me as a user - if a system uses plain password hashing then I can greatly decrease the likelyhood of someone guessing my password by simply using a longer and more unpredictable password.

    Quote Originally Posted by felgall View Post
    With any hash the length of the password doesn't make any difference - it is the length of the hash that determines the maximum number of values that you'd need to try with a brute force attack. They don't have to find the real password they just need to find one that matches the hash.
    That is true but the number of possible hashes is very large even for a modern computer. For md5 it's 340282366920938463463374607431768211456, for sha-1 it's 1461501637330902918203684832716283019655932542976, for sha-256 it's 115792089237316195423570985008687907853269984665640564039457584007913129639936. Maybe md5 can be brute-forced but I doubt it's practically feasible for the longer hashes.

  4. #54
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,311
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    I was just wandering if very strong and long passwords are safe when stored using a simple unsalted hash. This appears to be true.
    Yes, that's true. If the password is sufficiently random that it won't appear in any rainbow tables, then the salt is unnecessary.

    Quote Originally Posted by Lemon Juice View Post
    ...however I don't think it's true for md5 as it can be broken (collisions can be found) but it's a different subject.
    This subject requires lots of nuance. MD5 is most famous for having its collision resistance broken. That means someone can find two messages that compute to the same hash. (That person has to be able to pick both messages). For storing passwords, we're most concerned with preimage attacks -- that is, given a hash, finding a message that computes to that hash. On that front, MD5 has had some minor breaks, but for the time being is still secure.
    "First make it work. Then make it better."

  5. #55
    Avid Logophile silver trophy
    ParkinT's Avatar
    Join Date
    May 2006
    Location
    Central Florida
    Posts
    2,343
    Mentioned
    192 Post(s)
    Tagged
    4 Thread(s)
    This is a fascinating subject that has been treated by a very interesting discussion here.
    Many ideas, opinions and [mis]conceptions to include.

    I have learned a lot from reading the dialog.

    But, as a "Security Newbie", when I take-a-step-back from all this, I see a fundamental problem with security that can NEVER be fixed.
    Quote Originally Posted by ServerStorm View Post
    Most people would not do well with 50 character passwords so it really is not practical. Why not use a cypher that can protect passwords of lengths and complexity that they can remember?
    Generally, the average (non-technical or technically-naive) user will have chosen a simple password. Or one that is easy to remember; meaning it is easy to guess. And that is without even a mention of "Social Engineering" to deduce the user's credentials.
    Don't be yourself. Be someone a little nicer. -Mignon McLaughlin, journalist and author (1913-1983)


    Git is for EVERYONE
    Literally, the best app for readers.
    Make Your P@ssw0rd Secure
    Leveraging SubDomains

  6. #56
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by ParkinT View Post
    This is a fascinating subject that has been treated by a very interesting discussion here.
    Many ideas, opinions and [mis]conceptions to include.

    I have learned a lot from reading the dialog.

    But, as a "Security Newbie", when I take-a-step-back from all this, I see a fundamental problem with security that can NEVER be fixed.

    Generally, the average (non-technical or technically-naive) user will have chosen a simple password. Or one that is easy to remember; meaning it is easy to guess. And that is without even a mention of "Social Engineering" to deduce the user's credentials.
    I guess my hopes were to keep the subject more along those lines. We can't force too extreme of a password without alienating users. So worst case scenario, my data and source code exposed has just happened. Obviously a unique salt per each record is at least the start of our security. Computing power is coming along quickly. Multi threading an attack on a record set with increasing performance and technology seems to be becoming easier and cheaper. Quantum computing is probably 10-15 years out that will bring unprecedented speed. But not being a black hat with lots of nice technology sitting in my closet (or somewhere offsite that I may have 'acquired') at my disposal, I'm not sure how well this protects my common password users, or even that single VIP user who someone might target for a brute force attack. Perhaps I am under thinking (or over?) this too much.

    Setting the password topic aside, I think we might learn a bit more if we look at some data we plan to be able to read again, such as social security numbers / credit card data. Let's talk about the best methods for keeping that data secure in this event.

  7. #57
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by ParkinT View Post
    This is a fascinating subject that has been treated by a very interesting discussion here.
    Many ideas, opinions and [mis]conceptions to include.

    I have learned a lot from reading the dialog.

    But, as a "Security Newbie", when I take-a-step-back from all this, I see a fundamental problem with security that can NEVER be fixed.

    Generally, the average (non-technical or technically-naive) user will have chosen a simple password. Or one that is easy to remember; meaning it is easy to guess. And that is without even a mention of "Social Engineering" to deduce the user's credentials.
    Hi ParkinT,

    The idea is to strike a balance with what makes it too hard for users and protect them from their low security passwords. This is generally done by enforcing an 8-10 string that must meet the following:

    1. A mixture a upper-case, lower-case, numbers and special characters
    2. There can be no combination of two or more in a row of the aforementioned characters, so app13 would not be allowed due to the three lower-case letters followed by the two numbers in a row, but aPpL3 would pass the filter
    3. No password can be one of the top 200 known insecure passwords.
    4. A password must be 8+ (or 10+) characters


    Generally if people think of symbols and numbers as letters they can spell out passwords that meet this criteria but they can still remember.

    There are some obvious poor passwords that can match this criteria like P@s5w0rD but doing creating "Dogs are Hoovers" can be made into "D0g5rH0o^3rs". Yes not super user friendly but also not too hard. It is also not a bad idea to provide a link "Why does my password need to be so complicated?" and give them non-technical info that it is for their own protection.

    Make sure you provide a decent 'forgot my username and forgot my password (create new password, don't send it over email' processes.

    Hope this helps,
    Steve
    ictus==""

  8. #58
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    I guess my hopes were to keep the subject more along those lines. We can't force too extreme of a password without alienating users. So worst case scenario, my data and source code exposed has just happened. Obviously a unique salt per each record is at least the start of our security. Computing power is coming along quickly. Multi threading an attack on a record set with increasing performance and technology seems to be becoming easier and cheaper. Quantum computing is probably 10-15 years out that will bring unprecedented speed. But not being a black hat with lots of nice technology sitting in my closet (or somewhere offsite that I may have 'acquired') at my disposal, I'm not sure how well this protects my common password users, or even that single VIP user who someone might target for a brute force attack. Perhaps I am under thinking (or over?) this too much...
    I don't think your over thinking it. Your comments though do reinforce the idea that hashing security should be designed flexibly into your system so that it limits the work you need to do to swap in different cyphers and Salt/Pepper. This is hard to do, but not impossible.
    ictus==""

  9. #59
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ServerStorm View Post
    Hi ParkinT,

    The idea is to strike a balance with what makes it too hard for users and protect them from their low security passwords. This is generally done by enforcing an 8-10 string that must meet the following:

    1. A mixture a upper-case, lower-case, numbers and special characters
    2. There can be no combination of two or more in a row of the aforementioned characters, so app13 would not be allowed due to the three lower-case letters followed by the two numbers in a row, but aPpL3 would pass the filter
    3. No password can be one of the top 200 known insecure passwords.
    4. A password must be 8+ (or 10+) characters
    I would be genuinely annoyed if a web site imposed such requirements on my password. The last two are perfectly okay, the first one is somewhat acceptable but the second one is unacceptable for me because it forces me to choose passwords which are very difficult to remember. I like using passwords which are easy to remember but still offer acceptable stength - and those are relatively easy passwords composed of common words (or better yet common to me only) and being long. Here the length compensates for lack of randomness of characters. Therefore, I'd be happy with a password like this:
    Code:
    =====IN the zoo alice-the-pretty flew away on an ELEPHANT=====
    Rule #2 would not allow this password. Instead, I'd have to choose some hard to remember gibberish, which would most probably be short (it's a pain having to type long gibberish) and by being hard to remember it would pose other security problems because I'd have to store the password somewhere *securely*. In that case I might as well go for a complete random mixture of characters and store them in a password manager.

    Here is a nice conversation about a comic that illustrates that long passwords have their advantage even if they are easy to remember:

    http://security.stackexchange.com/qu...ary-passphrase

    Of course, using common words in a long password reduces its entropy but still the length compensates well for this.

    Generally, I'm more for educating about password strength instead of enforcing some rules *I* think are the proper ones. For example, implement a password strength meter, issue a warning if a password is too weak and warn about the risks - but ultimately leave the decision to the end user - it's his or her data and it's their choice to have a weak password and it should be respected.

    Quite often I'm annoyed because I use a web host who imposes strict rules about passwords when setting up accounts. Often I need to set up a test or temporary account for some simple web site and I don't need any special security - and they force me to invent all those fancy passwords - one for ftp, one for the database, another one for email, etc. I want to shout to them: let ME choose how much security I want to have!

  10. #60
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,311
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    Generally, I'm more for educating about password strength instead of enforcing some rules *I* think are the proper ones. For example, implement a password strength meter, issue a warning if a password is too weak and warn about the risks - but ultimately leave the decision to the end user
    I agree.
    "First make it work. Then make it better."

  11. #61
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    I would be genuinely annoyed if a web site imposed such requirements on my password. The last two are perfectly okay, the first one is somewhat acceptable but the second one is unacceptable for me because it forces me to choose passwords which are very difficult to remember. I like using passwords which are easy to remember but still offer acceptable stength - and those are relatively easy passwords composed of common words (or better yet common to me only) and being long. Here the length compensates for lack of randomness of characters. Therefore, I'd be happy with a password like this:
    Code:
    =====IN the zoo alice-the-pretty flew away on an ELEPHANT=====
    Rule #2 would not allow this password. Instead, I'd have to choose some hard to remember gibberish, which would most probably be short (it's a pain having to type long gibberish) and by being hard to remember it would pose other security problems because I'd have to store the password somewhere *securely*. In that case I might as well go for a complete random mixture of characters and store them in a password manager.

    Here is a nice conversation about a comic that illustrates that long passwords have their advantage even if they are easy to remember:

    http://security.stackexchange.com/qu...ary-passphrase

    Of course, using common words in a long password reduces its entropy but still the length compensates well for this.

    Generally, I'm more for educating about password strength instead of enforcing some rules *I* think are the proper ones. For example, implement a password strength meter, issue a warning if a password is too weak and warn about the risks - but ultimately leave the decision to the end user - it's his or her data and it's their choice to have a weak password and it should be respected.

    Quite often I'm annoyed because I use a web host who imposes strict rules about passwords when setting up accounts. Often I need to set up a test or temporary account for some simple web site and I don't need any special security - and they force me to invent all those fancy passwords - one for ftp, one for the database, another one for email, etc. I want to shout to them: let ME choose how much security I want to have!
    Are you still ok with it when your system gets hacked and the people that ignore the strength meter are responsible for the security weakness - say an Administrative account where they ignore security warning and set an easy password? It is not the user who sets the simple password who gets into trouble it is the company that runs the site / service. Just think of the damage control that Sony recently had to do when their system was cracked.

    I do understand your point, and also understand about 'free will'; however if you have a system that holds important data how are you supposed to feel about those simple passwords? Most people I know would not want a
    =====IN the zoo alice-the-pretty flew away on an ELEPHANT=====
    password - they like
    12345
    .
    When the culpability is on the companies that you build these system for, the choice of reducing security on the system should not be in the hands of users. If the data is not that sensitive then go ahead and allow
    121212123433434
    . But what happens when in the future you decide to add something worth protecting?

    Recently developers have been getting sued for not securing applications correctly. I want no part of legal issues on choices I make as a developer.

    ictus==""

  12. #62
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,311
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by ServerStorm View Post
    ...say an Administrative account where they ignore security warning and set an easy password?
    I would think that administrative accounts are definitely a different story. I'd be in favor of enforcing strong passwords in that case.
    "First make it work. Then make it better."

  13. #63
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    I would think that administrative accounts are definitely a different story. I'd be in favor of enforcing strong passwords in that case.
    Yes this is one way to do it, have different rules for each role in a system, with emphasis on administrators, roles with access to financial data and credit cards, and root access.

    I'm not too sure how often people link rules mapped to different roles like this, but can simplify it for low-security-requirements users?
    ictus==""

  14. #64
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ServerStorm View Post
    Are you still ok with it when your system gets hacked and the people that ignore the strength meter are responsible for the security weakness - say an Administrative account where they ignore security warning and set an easy password? It is not the user who sets the simple password who gets into trouble it is the company that runs the site / service. Just think of the damage control that Sony recently had to do when their system was cracked.
    If users who have administrative accounts can't be trusted to create a secure password then they shouldn't be able to do so in the first place. Enforce proper passwords and change them periodically.

    Quote Originally Posted by ServerStorm View Post
    I do understand your point, and also understand about 'free will'; however if you have a system that holds important data how are you supposed to feel about those simple passwords? Most people I know would not want a password - they like . [SIZE=2]When the culpability is on the companies that you build these system for, the choice of reducing security on the system should not be in the hands of users.
    I believe free will should be always granted in cases when an individual is not able to screw up other people's stuff via their account.

    When security-uneducated people are using a system there is always a risk of human carelessness or error. If you have people that would rather have "12345" if possible then they are probably willing to stick a difficult password to their desk or leave in some other convenient place for easy access. I was saying that in such cases an easy to remember password - but longer - might be better because it wouldn't have to be written down anywhere and be accessible to everyone in the vicinity.

    Quote Originally Posted by ServerStorm View Post
    But what happens when in the future you decide to add something worth protecting?
    You may request a password change or enforce one.

  15. #65
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    If users who have administrative accounts can't be trusted to create a secure password then they shouldn't be able to do so in the first place. Enforce proper passwords and change them periodically.
    This leads us back to what are the proper things to enforce but if we say 8+ char, mixture of upper/lower - case letters, per-user salts and site pepper then we'll likely get secure enough passwords. Changing them periodically is a good idea.

    Quote Originally Posted by Lemon Juice View Post
    I believe free will should be always granted in cases when an individual is not able to screw up other people's stuff via their account.
    Fair deal.

    Quote Originally Posted by Lemon Juice View Post
    When security-uneducated people are using a system there is always a risk of human carelessness or error. If you have people that would rather have "12345" if possible then they are probably willing to stick a difficult password to their desk or leave in some other convenient place for easy access. I was saying that in such cases an easy to remember password - but longer - might be better because it wouldn't have to be written down anywhere and be accessible to everyone in the vicinity.
    You may be right about this, but I've had to go through this recently for a credit card based site and to get it passed this was not allowed; the tougher, less friendly security is what they required. This however, goes to your and Jeff's point that when security is needed, button down the hatch, but when it's not then ease up on your users.

    Quote Originally Posted by Lemon Juice View Post
    You may request a password change or enforce one.
    Yes this would work, but users may get more unhappy then learning the restrictions from the beginning?

    Steve
    ictus==""

  16. #66
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ServerStorm View Post
    This leads us back to what are the proper things to enforce but if we say 8+ char, mixture of upper/lower - case letters, and salted then well likely get secure enough passwords.
    If the passwords are going to be short then yes, mixing all those character types will help. However, I wouldn't consider an 8-character password to be strong even if it were random.

    Quote Originally Posted by ServerStorm View Post
    You may be right about this, but I've had to go through this recently for a credit card based site and to get it passed this was not allowed; the tougher, less friendly security is what they required.
    Yes, in such cases there's nothing you can do really. But I'm wondering about such requirements really - if someone requires a user-unfriendly security to be implemented then in order to be consistent they should also require users to be able store their passwords securely as it's obvious they won't be able to remember them. If people are given a difficult password they must find a way to make using it fairly easy - how many of them know where to store it and where not to or how to setup and use a password manager in a secure way? Do they pay you for educating them and/or installing password software? (well, I doubt that )

    Quote Originally Posted by ServerStorm View Post
    Yes this would work, but users may get more unhappy then learning the restrictions from the beginning?
    You might implement a password strength meter and store the result in the db with every password. When a user is granted access to some sensitive data then they are required to change their password only if the current one is of low quality. However, if a hacker gets the db he would know which passwords to target!

  17. #67
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    If the passwords are going to be short then yes, mixing all those character types will help. However, I wouldn't consider an 8-character password to be strong even if it were random.
    Yes each user role would have increasing larger character limits depending on their sensitive access.

    Quote Originally Posted by Lemon Juice View Post
    Yes, in such cases there's nothing you can do really. But I'm wondering about such requirements really - if someone requires a user-unfriendly security to be implemented then in order to be consistent they should also require users to be able store their passwords securely as it's obvious they won't be able to remember them. If people are given a difficult password they must find a way to make using it fairly easy - how many of them know where to store it and where not to or how to setup and use a password manager in a secure way? Do they pay you for educating them and/or installing password software? (well, I doubt that )
    Yes there is this problem. Most passwords aren't stolen off of desks, most are hacked remotely; however this does not account for the internal people that dump a whole database for profit later. I guess the banks look at the odds? They don't pay us to educate users and frankly most users don't like this sort of education so this part we can't control. It is in the hands of super computers and remote attacks that I worry most about. Protect the internal network by having secure data in a private network - one that is private even from most employees. Then make sure your system is built to secure passwords and usernames sufficiently for the types of data that can be accessed from the public facing web-sites.

    Quote Originally Posted by Lemon Juice View Post
    You might implement a password strength meter and store the result in the db with every password. When a user is granted access to some sensitive data then they are required to change their password only if the current one is of low quality. However, if a hacker gets the db he would know which passwords to target!
    Or when people's role security access is increased they have to log in again when they try to access the more secure pages. At this point upon calculating the matching hash that the application could determine that the password strenght is not great enough and then re-route the user to 'Create a stronger password page'. Once they create a more secure password it re-directs them into the area they originally tried to access? This would then not require insecure passwords to be logged in the DB.
    ictus==""

  18. #68
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ServerStorm View Post
    Yes there is this problem. Most passwords aren't stolen off of desks, most are hacked remotely; however this does not account for the internal people that dump a whole database for profit later. I guess the banks look at the odds? They don't pay us to educate users and frankly most users don't like this sort of education so this part we can't control. It is in the hands of super computers and remote attacks that I worry most about. Protect the internal network by having secure data in a private network - one that is private even from most employees. Then make sure your system is built to secure passwords and usernames sufficiently for the types of data that can be accessed from the public facing web-sites.
    Okay, I see!

    Quote Originally Posted by ServerStorm View Post
    Or when people's role security access is increased they have to log in again when they try to access the more secure pages. At this point upon calculating the matching hash that the application could determine that the password strenght is not great enough and then re-route the user to 'Create a stronger password page'. Once they create a more secure password it re-directs them into the area they originally tried to access? This would then not require insecure passwords to be logged in the DB.
    To this sounds like a good solution, no need to store the strength in the db. I think password strength could even be calculated on each log on and stored in the session - then you won't have to bug the users who already have strong passwords when they try to access the more secure pages.

  19. #69
    Avid Logophile silver trophy
    ParkinT's Avatar
    Join Date
    May 2006
    Location
    Central Florida
    Posts
    2,343
    Mentioned
    192 Post(s)
    Tagged
    4 Thread(s)
    Then (to further complicate the matter) let's not forget 'Shared key" or [physical] Auth Token as an adjunct to the username/password.
    I work on US Air Force systems and these are the norm; in addition to password restrictions like @ServerStorm mentioned above.

    The fault I see with this, as @Lemon Juice ; described, is that "human nature" causes users to STORE those difficult-to-remember paswords.
    I know of many desk drawers that contian a yellow stickie note just inside the front face containing one of those passwords.

    My recommendation, when you succumb to writing-down a password, is to transpose two of the characters (or replace two completely) in the written form. ONly you know this, so the written password is effectively invalid. It is a weak strategy. But better than none at all.
    Don't be yourself. Be someone a little nicer. -Mignon McLaughlin, journalist and author (1913-1983)


    Git is for EVERYONE
    Literally, the best app for readers.
    Make Your P@ssw0rd Secure
    Leveraging SubDomains

  20. #70
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by ParkinT View Post
    Then (to further complicate the matter) let's not forget 'Shared key" or [physical] Auth Token as an adjunct to the username/password.
    I work on US Air Force systems and these are the norm; in addition to password restrictions like @ServerStorm mentioned above.

    The fault I see with this, as @Lemon Juice ; described, is that "human nature" causes users to STORE those difficult-to-remember paswords.
    I know of many desk drawers that contian a yellow stickie note just inside the front face containing one of those passwords.

    My recommendation, when you succumb to writing-down a password, is to transpose two of the characters (or replace two completely) in the written form. ONly you know this, so the written password is effectively invalid. It is a weak strategy. But better than none at all.
    My place of work is filled with this. I usually stick with my root password and shift down the keyboard of special characters as I need to reset my password. password!@ will then become password@# when its time for a change.

  21. #71
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by ParkinT View Post
    ...

    My recommendation, when you succumb to writing-down a password, is to transpose two of the characters (or replace two completely) in the written form. ONly you know this, so the written password is effectively invalid. It is a weak strategy. But better than none at all.
    This is an great recommendation @ParkinT ;, Thanks
    ictus==""

  22. #72
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    Thank you all for your great input! I tried earlier in this thread but I'd like to steer this toward encoding standards. Let's assume I'm storing credit card information. My web server has been rooted. What are your takes on how this data should have been handled? The encode / decode script?

  23. #73
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    Thank you all for your great input! I tried earlier in this thread but I'd like to steer this toward encoding standards. Let's assume I'm storing credit card information. My web server has been rooted. What are your takes on how this data should have been handled? The encode / decode script?
    If the server has been rooted I don't think there is any cipher that will help here. But I've read about one idea sometime ago and it seems quite good at protecting card data: whenever a user submits card data via form the data is encrypted with a good cipher using a strong random key. Part of the key is stored in the database but another part is sent away to the admin or operator via sms or email and discarded immediately. Of course, this makes access to the card data more troublesome to the legitimate users but if you are willing to live with that then I think it's good protection.

    I think protecting the server should be the most important part here. However, it might be the most difficult one as well. I'm not knowledgeable about server administration but I've heard real stories of programmer friends who have experienced being hacked by guys in ways that are beyond understanding for "ordinary" humans. Those guys can break into systems that seem perfectly safe, well configured and not even set up to serve anything other than static html

  24. #74
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    Well I didn't get this question answered before. But is it possible to encode a c++ executable or equivalent to a decent level. If this were possible, my approach would be to use a slight bit of security by obscurity, and store an encoded version of the card information off site, on a different db. One would have to decode the executable that handles the transfer to and from the offsite db in order to learn the card information location, and have access to the decode salt and method.

  25. #75
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    Well I didn't get this question answered before. But is it possible to encode a c++ executable or equivalent to a decent level. If this were possible, my approach would be to use a slight bit of security by obscurity, and store an encoded version of the card information off site, on a different db. One would have to decode the executable that handles the transfer to and from the offsite db in order to learn the card information location, and have access to the decode salt and method.
    Well, but if your site is written in PHP then PHP will have to run the c++ executable somehow to send and receive card data, right? Then the PHP code will be available to the attacker and he will be able to run it on your server without worrying about decrypting the exe. However, you might implement more security by obscurity and encode the PHP .


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
  •