SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 66 of 66
  1. #51
    HAHA!
    Join Date
    Mar 2006
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    so what's the argument here? If you can't keep your salt secret you're toast? I think we all knew that.
    Cheap web hosting directory listing the cheapest web hosting

    Submit articles to an article directory

  2. #52
    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)
    Yep.

    To be honest, if someone gets access to the passwords, you already have pretty bad problems.

    I think more time should be spent on stopping people getting said passwords in the first place. After all, even with the salt - without the actual encrypted password they can't do anything.

    Of course, passwords should be encrypted - my encryption involves various operations on the user's password and email address. To change their email, they enter their password - if it's correct, it generates the new encrypted password.

    But if anyone got access to the administration side, one of the last things I'd worry about is users' passwords. Yeah, it'd be a problem but I think my main focus would be getting the site back into shape (after all, they wouldn't just take passwords and run, they'd probably rip the site apart).
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  3. #53
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    People often use the same weak passwords at many sites. They often have similar usernames as well, so if I get password for site A there is a chance that this password will be used somewhere else as well. If you use strong password then simple methods are sufficient, but in reality people use very weak passwords. The question weather this is their problem or not goes out of the scope of discussion - how to protect passwords.
    The whole point of protecting passwords is that in an event of breach you do not have to worry about bad guys getting them. You are right that you need to stop people getting your password DB, but protecting from breach and ensuring that in event of breach minimum damage is done are two different things that can and must be done both.

  4. #54
    HAHA!
    Join Date
    Mar 2006
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    because of this very problem you can have your system compromised because somebody on another system has crappy security and some of the user accounts on your "highly secure" system are the same.
    Cheap web hosting directory listing the cheapest web hosting

    Submit articles to an article directory

  5. #55
    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)
    somebody on another system has crappy security and some of the user accounts on your "highly secure" system are the same.
    Therefore it doesn't matter what encryption you use - they already have the password from the other server.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  6. #56
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, but in "highly secure system" I do not really care that single password for ordinary account is compromised because user disclosed it to third party. What I need to ensure is that by somehow obtaining password/session the attacker can not compromise other passwords/sesions and that audit trail remains.

  7. #57
    Avid Logophile silver trophy
    ParkinT's Avatar
    Join Date
    May 2006
    Location
    Central Florida
    Posts
    2,287
    Mentioned
    182 Post(s)
    Tagged
    4 Thread(s)
    Since every hacker would assume you used some hashing method to encrypt your passwords why not 'go back to basics'? I simply apply a ROT13 to the password.
    That would surely fool them, don' t you think?

    </sarcasm>
    Don't be yourself. Be someone a little nicer. -Mignon McLaughlin, journalist and author (1913-1983)


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

  8. #58
    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 Hostpitable View Post
    so what's the argument here? If you can't keep your salt secret you're toast? I think we all knew that.
    Not necessarily. If someone gains access to your salt, they still have to generate rainbow tables for that particular salt. One per user if you use user salts.

    Another form of attack that is used is to take a common word that people might have as a password, hash it, and search for the user(s) that match the passwords, rather than trying to find a specific password for a user. Using a salt will prevent this kind of attack as well.

  9. #59
    HAHA!
    Join Date
    Mar 2006
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    Not necessarily. If someone gains access to your salt, they still have to generate rainbow tables for that particular salt. One per user if you use user salts.

    Another form of attack that is used is to take a common word that people might have as a password, hash it, and search for the user(s) that match the passwords, rather than trying to find a specific password for a user. Using a salt will prevent this kind of attack as well.
    that's what I meant. I assumed they would go through the hassle of creating rainbow tables for salt + hashed password.
    Cheap web hosting directory listing the cheapest web hosting

    Submit articles to an article directory

  10. #60
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Using single iteration creating rainbow table for dictionary with a given salt would require say 20 minutes, using 500 iterations for a given salt it would require 500 times longer -> 6 days 22 hours and 40 minutes.

  11. #61
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Proposal to move this thread to "Web Security" subforum.

  12. #62
    SitePoint Member
    Join Date
    Jun 2008
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok, so I am really new to this whole thing
    and read most of your posts and am in the dark for the most part.

    i have a few questions.

    1. I understand encrypting the passwords inside a database protects them from someone who may figure out how to query your db and get your users table, but how does encrypting them protect against brute force on a login page since the end user is entering plain text

    2. wouldn't a more effective way to prevent against brute force be denying a speciffic IP address from loging in after x failed attempts?

  13. #63
    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 bri_php View Post
    Ok, so I am really new to this whole thing
    and read most of your posts and am in the dark for the most part.

    i have a few questions.

    1. I understand encrypting the passwords inside a database protects them from someone who may figure out how to query your db and get your users table, but how does encrypting them protect against brute force on a login page since the end user is entering plain text
    It doesn't. That is a separate issue. You could prevent that by only allowing a certain number of login attempts within a certain time limit, enforcing a minimum length password (although I don't like this generally) etc.

    Quote Originally Posted by bri_php View Post
    2. wouldn't a more effective way to prevent against brute force be denying a speciffic IP address from loging in after x failed attempts?
    Yes, should have read the rest of your post before replying :P

    The point of storing the password decently is to stop brute force attacks on the hash itself. A hacker could do this on his own machine, outside the context of the website, so the site can't enforce limited attempts etc.

  14. #64
    SitePoint Member
    Join Date
    Jun 2008
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    The point of storing the password decently is to stop brute force attacks on the hash itself. A hacker could do this on his own machine, outside the context of the website, so the site can't enforce limited attempts etc.
    Ok, so how would someone do such a thing? that just doesn't make much sense to me.

  15. #65
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi, bri_php:
    I suggest you read wikipedia article:
    http://en.wikipedia.org/wiki/Key_strengthening
    and if you want serious explanation:
    http://www.schneier.com/paper-low-entropy.html

  16. #66
    SitePoint Member
    Join Date
    Jun 2008
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree with alien dev..it will not be secured anyways


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
  •