Is this best way to handle logins?

[dsheroh]

I will be however, doing a simple making sure that no two characters are within eachother,

Keep in mind that this will substantially reduce the search space for brute-force attacks, since an attacker aware of this requirement would know not to try, say, "sdjjhsiuh".  Whether that's more or less significant to the overall difficulty than the elimination of a certain class of weak passwords, I can't say, but a proper dictionary check would be more effective than banning doubled letters, particularly if you use wordlists that include '1ee+5p33|<' spellings as well as proper ones.  (There's a link near the bottom of the page to download free versions of their wordlists near the bottom of the page; you don't have to buy their CDs.)

And i'm also now going to be using teh twofish encryption algorithm with a key that'll be some random sha256 hashed version of some string.

You are aware that Twofish is actual (two-way) encryption, not (one-way) cryptographic hashing, yes?  If you want to be able to decrypt the stored passwords to find their plaintext representation, then that is appropriate, but I've been assuming that you did not want this to be possible.

[AcidicOne]

lol Well you've got the love the NSA for one thing they certainly know how to set some scarily high security standards.

[133794m3r]

I will be however, doing a simple making sure that no two characters are within eachother,

Keep in mind that this will substantially reduce the search space for brute-force attacks, since an attacker aware of this requirement would know not to try, say, "sdjjhsiuh".  Whether that's more or less significant to the overall difficulty than the elimination of a certain class of weak passwords, I can't say, but a proper dictionary check would be more effective than banning doubled letters, particularly if you use wordlists that include '1ee+5p33|<' spellings as well as proper ones.  (There's a link near the bottom of the page to download free versions of their wordlists near the bottom of the page; you don't have to buy their CDs.)

And i'm also now going to be using teh twofish encryption algorithm with a key that'll be some random sha256 hashed version of some string.

You are aware that Twofish is actual (two-way) encryption, not (one-way) cryptographic hashing, yes?  If you want to be able to decrypt the stored passwords to find their plaintext representation, then that is appropriate, but I've been assuming that you did not want this to be possible.

hmm ok about the no double thing. And php doesn't include bcrypt. It only includes blowfish. Which isn't bcrypt as far as i know. It has no option for bcrypt. So honestly, i don't know how using anything besides sha256 would be any better then.

I just looked at the phphash you linked to in that other thread or maybe it was here... either way i'm going to look at it and see how well it'll work out. My only real problem/question about it is if it'll work out properly for checking someone's password. Since it seems as though it's meant to make each iteration completely random so that no two are the same. If that's true, then it'll be impossible for me to use.

And i was planning on using twofish for people's emails if they wished to provide them in teh case that they lost their password.(or well some other two way encryption)

[dsheroh]

And php doesn't include bcrypt. It only includes blowfish. Which isn't bcrypt as far as i know. It has no option for bcrypt. So honestly, i don't know how using anything besides sha256 would be any better then.

Ah, I had assumed when you mentioned finding blowfish earlier that you actually meant you had found bcrypt.  According to the OpenWall site (the source of the dictionary lists I linked above), "To ensure that the fallbacks will never occur, PHP 5.3.0+ or the Suhosin patch may be used. PHP 5.3.0+ and Suhosin integrate crypt_blowfish into the PHP interpreter such that bcrypt is available for use by PHP scripts even if the host system lacks support for it."  (Source)  It looks like you access it by using the crypt() function and specifying CRYPT_BLOWFISH as the method.

If your PHP is older than that, then, yeah, sha256 would likely be your best bet.  It's still a very good option as far as resistance to reverse-engineering passwords or generating hash collisions.  The only problem with it that I'm aware of is that it runs fast enough to allow brute-force attacks, which is the threat that bcrypt was specifically designed to counter.  Note that you can still slow things down without using bcrypt if that's a major concern - just run 100 rounds of sha256 (i.e., create your hash, then hash the result, then hash that result...), or 1000, or however many you feel your hardware is capable of without harming the overall user experience.

[133794m3r]

And php doesn't include bcrypt. It only includes blowfish. Which isn't bcrypt as far as i know. It has no option for bcrypt. So honestly, i don't know how using anything besides sha256 would be any better then.

Ah, I had assumed when you mentioned finding blowfish earlier that you actually meant you had found bcrypt.  According to the OpenWall site (the source of the dictionary lists I linked above), "To ensure that the fallbacks will never occur, PHP 5.3.0+ or the Suhosin patch may be used. PHP 5.3.0+ and Suhosin integrate crypt_blowfish into the PHP interpreter such that bcrypt is available for use by PHP scripts even if the host system lacks support for it."  (Source)  It looks like you access it by using the crypt() function and specifying CRYPT_BLOWFISH as the method.

If your PHP is older than that, then, yeah, sha256 would likely be your best bet.  It's still a very good option as far as resistance to reverse-engineering passwords or generating hash collisions.  The only problem with it that I'm aware of is that it runs fast enough to allow brute-force attacks, which is the threat that bcrypt was specifically designed to counter.  Note that you can still slow things down without using bcrypt if that's a major concern - just run 100 rounds of sha256 (i.e., create your hash, then hash the result, then hash that result...), or 1000, or however many you feel your hardware is capable of without harming the overall user experience.

Well i saw it but it didn't say it was bcrypt() itself and since it said it was a two way encrypter i was worried that it wasn't as strong as bcrypt itself. So then i was worried about it. And since i was using the crypt() function i didn't see an option to slow the down as you said before with the.10 seconds. So since it is like, about how many times should i tell it to reencrypt itself? Like 10 times?

[dsheroh]

Just for the sake of completeness, here's a link to an article I ran across which discusses the reasons behind using bcrypt (although it incorrectly calls it Blowfish), including a code snippet demonstrating how to use it in PHP:

http://www.dereleased.com/2010/02/09/lets-talk-about-your-password-model/

[133794m3r]

Just for the sake of completeness, here's a link to an article I ran across which discusses the reasons behind using bcrypt (although it incorrectly calls it Blowfish), including a code snippet demonstrating how to use it in PHP:

http://www.dereleased.com/2010/02/09/lets-talk-about-your-password-model/

if i know COMPLETELY understand how bcrypt works then that means that my users passwords will not be able to be as safe as i'd like them to be and i can't use the type of password that i like to do. Since it said that it can ONLY take a base64 string for the password, this means that i'm not able to use special characters such as (),{},[],!@#$%^&*_='":;><.,?/ and that doesn't make me feel remotely good about this crypt() function. Hmm.... seems that the base64 encoder might support said characters. I'll have to try it out officially.

edit:Also, one of the other things i gotta say is that thing really helped me to understand the crypt() function. B/c the php documentation wasn't too thorough with said items.

Nvm once again i didn't test before i spoke. Ignore my statements(except it seems given to it's own whims it's for some odd reason using $ as the salt and padding the entire thing for that no idea why).

Gah, i wish i'd just do things w/o questioning before hand. I feel extermely foolish atm. Well now time to go make a good ol' salt generator for this salt's encryption .

[dsheroh]

if i know COMPLETELY understand how bcrypt works then that means that my users passwords will not be able to be as safe as i'd like them to be and i can't use the type of password that i like to do. Since it said that it can ONLY take a base64 string for the password, this means that i'm not able to use special characters such as (),{},[],!@#$%^&*_='":;><.,?/ and that doesn't make me feel remotely good about this crypt() function. Hmm.... seems that the base64 encoder might support said characters. I'll have to try it out officially.

You misread (which is easy, because the article I linked phrased it poorly).  It's the salt that has to be a valid base64 string, not the password.  The password can be anything.

The requirement that the salt has to be passed in base64 encoding isn't actually an issue - 128 bits is 128 bits, regardless of whether it's passed as 22 base64 digits, 32 hexadecimal digits, 16 raw bytes, or any other format.

[Fizzadar]

Store an IP on the session too, to prevent session stealing.

Personally I switch between sessions and cookies a lot. I quite like storing the userid and password in cookies, and using the database to check them. It's only one query, the same as I would for a session (I normally make my sessions database powered), and it means it keeps them logged in on that computer for as long as you want. But I always have a loggedin column on the 'session' table meaning the server can force-logout people if they get hacked/whatever.

[JGadrow]

I know cookies are supposed to be secure, but it's happened before that browsers have had vulnerabilities that allow 3rd party reading of cookie data. So, I consider it poor form to actually store the username password combination in a cookie.

What you should store, instead, in these instances is a single use password. Once the password is used, it gets discarded and a new one is generated and handed to the browser. This still doesn't protect the user from any 3rd party reading the cookie in case of a browser vulnerability. However, it does mean that their actual password (that's likely also on their bank account, and many other critical sites despite the fact that it makes sense to have separate passwords for highly critical accounts like these) will be safe from sniffing (well, there's also SSL to consider for account signup and standard login, but that's a different subject).

Basically, if you're ever doing anything with the plain-text user password that you've received other than passing it directly (with or without salts and nonces though it's obviously better to have them) to a hashing function, you need to have your hand smacked with a wooden ruler.

[dsheroh]

I know cookies are supposed to be secure, but it's happened before that browsers have had vulnerabilities that allow 3rd party reading of cookie data. So, I consider it poor form to actually store the username password combination in a cookie.

Browser vulnerabilities aren't really relevant to this point, IMO.  Even if the user's browser is absolutely 100% secure, the way that cookies work is that the browser sends them back to the server with each and every request, creating the possibility that any information contained in them could be intercepted in transit every time a request is made - page loads, AJAX calls, following redirects, or whatever else.  Unless you're using transport-level encryption (i.e., SSL), any cookie's content is inherently vulnerable to being discovered by eavesdroppers.

So don't put sensitive information into cookies.  The only thing I ever use them for is storing a random session ID which is then associated on the server side with the user's information.

Basically, if you're ever doing anything with the plain-text user password that you've received other than passing it directly (with or without salts and nonces though it's obviously better to have them) to a hashing function, you need to have your hand smacked with a wooden ruler.

A wooden ruler?  You're being too lenient...

[Fizzadar]

I would only ever have a hashed password in the cookie. vB does it, and I'm pretty certain SMF does too.

[gnoh]

I go with email address and a random session id as dsheroh has said.