How can I allow a change of password with md5 in mind. When the accounts are being created the passwords are being entered in md5. So now when i display the password field of course they are in md5 (don't worry for testing purposes i am showing the password in the field instead of displaying hashes or dashes).
So how do i go about changing the passwords then? When they are changed they also need to be in md5.
Don't display anything in the password field. Have 3 fields. One for the original password (for security), and 2 for the new password (one for verification).
When submitted, check the old password, if it's right, md5 the new one and save it.
In the database you overwrite the old MD5 hash with the new MD5 hash. Or are you asking a user interface question?
The MD5 hash is a one-way hash that cannot be decrypted, so there's no need to display it. Changing the passwords updates the database with a new MD5 hash.
So how do i go about changing the passwords then?
I think you should read You're Probably Storing Passwords Incorrectly
(Article from author stackoverflow.com):
We learned that in a password hashing
scheme, speed is the enemy. We learned
that MD5 was designed for speed. So,
we learned that MD5 is the enemy.
If you must store your passwords(Please also read below for more tips) use phpass to store your passwords securely. I advice you to read the article on the site explaining How to manage a PHP application's users and passwords. It will teach you how to do it securely using email verification tokens.
Just for the fun of it I also created a library(please also read below) which does this for you using the excellent phpass. It is hosted at github and you can take a look at it if you like. Especially you should have a look at Authentication Class together with AuthenticationTest.
OpenID
Furthermore I would like to point out you should use something like OpenID, Facebook Connect, Google Friend Connect instead. You should not be storing your passwords because it is risky business like The Dirty Truth About Web Passwords explains.
Jeff Atwood:
I'm not here to criticize Gawker. On
the contrary, I'd like to thank them
for illustrating in broad, bold relief
the dirty truth about website
passwords: we're all better off
without them. If you'd like to see a
future web free of Gawker style
password compromises -- stop trusting
every random internet site with a
unique username and password! Demand
that they allow you to use your
internet driver's license -- that is,
your existing Twitter, Facebook,
Google, or OpenID credentials -- to
log into their website.
I also have a nice OpenID library available at github which uses LightOpenID with openid-selector. You can see a demo up and running at my shared hosting provider: http://westerveld.name/php-openid/
Related
I am trying to build a web portal which is using SOAP RBAC (3.3.5a) to communicate between wow server and web portal.
What encryption is AzerothCore using? Is it same as Trinity?
I tried using other CMS existing FusionGen and github and looking at login and registration system. They all base on trinity.
But it seems its not actually same somehow.
Any help is appreciated
AzerothCore uses the same strategy of all MaNGOS-based game servers. So, yes, it's the same as in TrinityCore too.
Passwords are encrypted using the SHA1 hash function with the format: account:password in uppercase.
So if your account is squeeze and your password is azeroth, it will be encrypted in SHA1('SQEEZE:AZEROTH').
The password will be stored in the sha_pass_hash field of the account table inside the acore_auth database.
SQL code
SELECT SHA1(CONCAT(UPPER('your_username'), ':', UPPER('your_password')))
PHP code
sha1(strtoupper($username).':'.strtoupper($password));
Here you are more information about passwords:
http://www.azerothcore.org/wiki/account#sha_pass_hash
In AZerothCore database (and all Mangos derivates) the SHA1 is only used to store password in database but the game client uses an SRP6 protocol that needs v and s keys generated by the server and sent to the client.
#hanshenrik let's slow down. I do agree that it is a HORRIBLE password storage scheme but for slice differents reasons. Salts defend against a pre-computed hash attack, so in case an attacker is able to breach your DB, he will have access to the salt anyway, so the attack described it's not really depending from the use of the account as salt, even though I do agree that must always be a truly unique long enough random sequence of bit, (the account name could be very short and public).
The real problem here are 2:
1) SHA1 is no longer considered secure
2) Make the password insensitive reduce the possible combination.
For a hardened scheme would be nice to encrypt even the salt to make the life harder to an attacker.
As the title says I'm trying to use PHP's password_hash function but I know that it is one way hashing so if I use it the password will be unable to be unhashed.
That being said, I want to be able to have an eye next to a password box (like LastPass) within the system that I'm working with that can display the password for admin users of the site but I'm not sure how to do this. Is there a function within PHP or some library that will allow for secure hashing or encryption so that this is possible? Is there another way to do this securely?
I've been looking around stack overflow for a while now just trying to find an answer to this but have to find anything that is close to what I'm wanting to do.
For a quick frame of reference for this. The users of the site can allow for 3rd party companies to login to retrieve files that are being shared with them. The users create the password and share it with the 3rd party. I want to make sure that when the passwords are secured but still allow the users of the site to go back and lookup the password for the 3rd party companies should they forget their password.
... that will allow for secure hashing or encryption so that [displaying the password for admin users] is possible?
You keep using that word. I do not think it means what you think it means. :-)
Password hashing can either be secure or it can be reversible.
The whole point of password hashing is to be non-reversible. If you want the original password, you're going to have to store it (keeping in mind how insecure this actually is).
At a bare minimum, you'd want the plaintext password somewhere totally separate from, and inaccessible to, the outside world. But the ground is littered from the corpses of password files that companies thought were secure from the general public, so my advice is to steer well clear of this.
No, you cannot get the original plaintext password from a hash. That's the entire point. The plaintext password is a secret that only the user is supposed to know. The secrecy of their password is the only security measure they have. If the password is "publicly" known then the security is out of their hands. And if anyone besides them knows the password, even if it's just your server, it becomes harder and harder to control who knows the password and it's only a matter of time until it leaks entirely.
That is why you don't want even your server to know the actual password, and to only store an irreversible hash of it.
If you want to store the password in a way that is reversible, at the very least you should store it such that even the server itself could not see the plaintext. Meaning, even if you encrypt it, encrypt it in a way that the server itself cannot decrypt it. Because if your server can decrypt it, so can anyone with access to that server. For instance, use entirely client-side encryption within the browser and require the user to enter their password in some way which will decrypt the stored password. Of course, this limits who will be able to see the password, which is the entire point.
If you need concrete encryption schemes to design this, it's best to ask at http://security.stackexchange.com or perhaps https://crypto.stackexchange.com.
As everyone know that Drupal store password using SHA2 method which involves Encryption + Hashing + Salt on it.
I have a list of passwords which are currently used by some of my clients in Drupal. Since we have migrated the whole system to Custom PHP therefore we are unable to use the same passwords. And we really don't want to ask everyone in the database to generate a new passwords.
If there is any way, where we could change all the passwords which are in SHA2 (Drupal - 512 Encryption) to support our new system which is currently having MD5/SHA1 (PHP Mysql database).
Any help would be appreciated.
You really do not want to go to MD5. It's dead as far as a password hashing method goes. You should be moving to password_hash and something like Bcrypt at the absolute minimum.
Remember, when someone logs in and you verify their password is correct that's your chance to update how the password is hashed in the database. If they're using a weak method, switch to a strong one and save their user record. Nobody will know what you've done.
After a year or so you can always force-expire all the old-format passwords if you're concerned about that lingering liability. All of your active users will be unaffected.
I wouldn't suggest changing to another password format and especially not MD5. Since you already have the passwords you can implement the Drupal password hashing in your own application and just continue using the existing passwords.
More information about the password formats can be found for example in this question.
I think you should use a 'transition'. For example use your new system but let the old password in the database.
In your code, on user login you get the password (ex: $_POST['pwd']), and crypt it using a strong algorithm (not MD5). Then, you can insert it in a new field of your database.
So, your new database could have a field 'old_pwd' that contains the old password and a field 'pwd' that contains the new password using your new algorithm. According to me this is the easiest to do this migration.
Password checking code is pretty similar in Drupal 7 and 8 and easy to borrow, it does not have any strong dependency on Drupal component. It should be pretty easy to add support for Drupal's hashes to your password checking code. Allowing use to authenticate using their password by storing Drupal's hashes in your database.
To migrate to your new hashing algorithm, simply re-hash passwords on successful authentication. This way, old hashes will be replaced over time.
Drupal has a similar mechanism to ensure transparent updates or old MD5 hashes. Look at the user_check_password() and user_needs_new_hash() to see how it could be done.
I have a WP website and another website with similar service. I want to duplicate db user password and email fields into new mysql database.
$A$B6NS8Cv837YVS1c/JKLE1 - WP password (example)
83703ccdb3cb2dad97f76f986400b43f87b989ce - Another website MD5 password (example)
And the question is how I can transfer WP user's passwords to a new mysql table so they can work?
Thanks
You will copy the md5 password into your new system.
Then you can have a login screen which does the exact same hashing on the entered password and compares the two.
Encryption is one way so you will never know the password but you certainly will be able to use it in another system.
As someone mentioned in the comments you will need to know exactly how WordPress hashes the password but this should all be in the source code.
However if you have other users already in the system that use a different hashing system you will need to flag them to decide what hashing to do.
When they do decide to change their password or via recommendation, you can migrate them to the other hashing system.
You can't - it's rather the point of hashing passwords that you can't undo it. You could potentially use a rainbow table to try and crack the MD5 hashes and get the original password before re-hashing it the way Wordpress does it, but if your users' passwords are vulnerable to such an attack, you should probably be concerned for their account security!
Personally, I would announce to the users that a big merge is happening, and for safety reasons they must change their password. A lot of people will probably just "change" it to the same thing, and that's fine, because internally you're just rehashing the password and can then delete the old, unsafe MD5 hash.
How do I write/put together a secure login in PHP? The website developer guide said I shouldn't roll my own, so referring to samples available via Google is useless.
How do you pros do it? Lets say you're building a world-class app in rails, would the same libraries / techniques be usable here?
Thanks
In Rails, one would generally use a pre-existing library. Authentication is easy to do wrong, and the problem's been solved so many times that it's rarely worth the effort to solve it again. If you are interested in writing your own implementation, then I'll describe how modern authentication works.
The naive method of authenticating a user is to store their password in a database and compare it to the password the user submits. This is simple but unbelievably insecure. Anyone who can read your database can view anyone's password. Even if you put in database access controls, you (and your users) are vulnerable to anyone who hacks around them.
Proper form is to use a cryptographic hash function to process the password when it is chosen and then every time it is submitted. A good hash function is practically irreversible -- you can't take a hash and turn it back into a password. So when the user logs in, you take the submitted password, hash it, and compare it to the hash in the database. This way, you never store the password itself. On the downside, if the user forgets their password, you have to reset it rather than send it to them.
Even this, however, is vulnerable to certain attacks. If an attacker gets hold of your password hashes, and knows how you hash your passwords, then he can make a dictionary attack: he simply takes every word in the dictionary and hashes that word, keeping it with the original. This data structure is called a rainbow table. Then, if any of the dictionary word hashes match a password hash, the attacker can conclude that the password is the dictionary word that hashes to that password. In short, an attacker who can read your database can still log in to accounts with weak passwords.
The solution is that before a password is hashed, it is combined (usually concatenated or xor'd) with a value called the salt which is unique to each user. It may be randomly generated, or it may be an account creation timestamp or some such. Then, an attacker cannot use a rainbow table because every password is essentially hashed slightly differently; he would have to create a separate rainbow table for every single distinct salt (practically for each account), which would be prohibitively computationally expensive.
I will echo the advice of the other answerers: this is not simple stuff, and you don't need to do it because it's been done before, and if you do it yourself you stand a very good chance of making a mistake and inadvertently compromising your system's security. But if, for whatever reason, you really, really want to write one yourself, I hope that I have provided an (incomplete!) outline of how it's done.
The Zend Framework has an 'Auth' module which would be a good place to start. Or, if your site will be hosting an install of WordPress or PHPBB, there are ways of leveraging those technologies' authentication modules to sign in to other pages of a site.
One thing to look at when you are trying to authenticate is what is your real goal.
For example, on SO I use my google login, and that works, as they just need to know who I am, and they can trust that Google has an idea. So, if that model will work for you, then look at using OpenID, as there are various tools for that.
If you must do your own, then there will be various tests to ensure that it is secure, again, depending on how paranoid you want to be.
Never trust anything from the user, unless you have used some strict verification.
Use https to help protect the password of the user, you owe them that much.
I will end my response here as Thom did a fantastic response.
by Soulmerge:
I think the accepted answer in your other question states it pretty well. Hash the passwords with a salt. Other than that, there are some security ideas on the transport layer:
Use https when sending passwords. This makes sure nobody can catch them on the wire (man-in-the-middle attack or the client uses an evil proxy)
An alternative is to hash the password using javascript when the login form is submitted. This makes sure that the password is never transported in plaintext. You should hash the hashed value again with a salt on the server. (md5($_POST['postedPwHash'] . $salt))
a good method to somewhat secure the client-server transaction (if no ssl is available) is to use a one-time random key to create a unique hash from the credentials, then only send that unique hash to the server. the server then compares this hash to its own generated hash instead of comparing it to the real credentials. this would provide a good defense against the man-in-the-middle attack. the downside is that to do this the user must have JS enabled (at least i dont know of a good method to encrypt client-side data without it). this means that you will need a sufficient fallback when it isn't on. you can even create the form in JS to make sure its enabled.
this library is a simple library i wrote once that does the procedure i described, though it probably needs some improvements.
note that this is in addition to using "salting" methods and other server-side security measures. it is also quite vulnerable to dictionary attacks as the entire hashing process is by definition procedural, predictable and visible to the user (as JS always is).
My answer is "Don't do it"
This is a very complex area, full of potential security gotcha's. If you are not an expert in this field, then you are really just asking for trouble and problems down the road.
I would recommend looking at getting an existing solution to do. Sadly I don't know any that I would be happy to recommend, other than openid. I'm sure you will get some good suggestions here though...