Is it okay to store the password in a public class variable?

Asked

Viewed 574 times

1

I am making a small login system in PHP using the new functions of password_hash and password_verify. Is it good practice to store the password in a public class variable? If not, it is recommended to use some other fast encryption such as md5 just to not leave the password stored?

An example:

function User($name,$pass){
    $this->username = $name;
    $this->password = md5($pass); //Armazenar em md5 para nao armazenar a senha sem encriptação.
}

or:

function User($name,$pass){
    $this->username = $name;
    $this->password = $pass; //Não tem problema armazenar assim.
}

If I use encryption, my system will be very slow with many users logging in at the same time?

  • 1

    Thanks for the acceptance, but don’t need to accept an answer so fast! This may reduce the chances of a better.

  • When I read your question, I understood that you would be building an extremely simple system, with only one user, one password, and no database. Is that right? If not, the other answers are much more appropriate than mine.

4 answers

3


I made a related question (in English) on how to treat passwords plastered in the code. The answer I got is that it is recommended to use some kind of hash (with salt) in those passwords.

The reasoning behind this is this: someone can gain access to your source code, in which case the password would not be exposed, only the hash. And the council they gave me was to store the password hash in a separate file, so that the source code does not need to be changed in multiple application installations.

1

The public and private object orientation has to do with the organization and modularization of your code and nay are an important factor in security. A public variable will not be visible outside your program and a private variable doing idiocy will still be a security issue.

As for the hashing, don’t use md5! md5 is a hash that is meant to be very fast to run and that’s a bad thing when you’re dealing with passwords. If a hacker can access a copy of your database with the password hashes, he will be able to "kick" your users' passwords much faster than he could do via the normal web interface. The faster your hash function, the more passwords the hacker can kick per minute and the less time it will take him to figure out the real password.

To store passwords, it is best to use a slow hash, preferably one where you can set the slowness with a parameter to slow the hash as slow as possible without negatively affecting its performance. Some common examples of these passwords special hashes are bcrypt, PBKDF2, and scrypt. I also strongly recommend using some ready-made library that implements these password protocols, as it is very easy to implement something unsafe if you do it by hand. In the case of PHP (p from version 5.5), you can use the functions password_hash and password_verify, implementing a password protocol using bcrypt.

https://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php

  • The reason why the MD5 is bad is not this. The MD5 was in fact created and designed with the intention of being safe. The problem is discovered several vulnerabilities in the algorithm of MD5, until finally it is definitely broken.

  • As for this whole "slow hash" thing, that’s not true. If your hash is safe and the space of possible results is too large for an exhaustive search, then there is no need to impose slowness. And another, I could implement a very slow hash as follows: Use the roughest and easiest encryption to be violated that you have and put a few-day Sleep: Okay, I have a slow but absolutely idiotic hash.

  • 1

    @Victor: The slow hash thing is called Key stretching. The idea is to protect yourself from the case where the hacker has a copy of your BD with hashed passwords. In this case, the hacker will try to guess the passwords in brute force, kicking one at a time and testing if the hash matches the BD hash. In this case, the size of the hash output does not matter (the hacker’s search space is the potential plaintext passwords, such as "password01" or "qwerty) and you do a Sleep no good because the hacker will not make these breaks.

  • 2

    @Victor: And the md5 is not broken (yet) from the point of view of passwords. The problem with md5 is that they found a way for you to build two messages that give the same hash. However, you have no control over the resulting hash in this, you just know it will be the same. In the case of the password, this is not enough since the challenge is to find a message that gives a specific hash. For details see http://security.stackexchange.com/questions/23116/md5-collision-attacks-are-they-relevant-in-password-hashing

  • Okay, but then please review the text because it led me to understand something else. I think you can express yourself better.

0

In a login system, passwords must be persisted (in a database, for example) after they have been hashish (for lack of better word) with a salt randomly generated for that user (as referred to by @bfavaretto). Thus, in the BD, each user must have at least 3 items saved: username, hashed password and the salt.

As soon as the user’s password enters the server, you must follow these steps (in pseudocode):

login(username, password) {
    //obter informacao do user
    User user = bd.getUser(username);

    //obter o salt deste user
    string salt = user.salt;

    //"hashar" a password introduzida pelo utilizador
    //e verificar se corresponde a' password na BD
    if(Hash(password, salt) == user.hashed_password) {
        //login com sucesso
    }
}

Remember that when a new user registers, it is necessary to generate the salt random:

registar_user(username, password) {

    string salt = random(); //gerar salt
    string hashed_password = Hash(password, salt); //"hashar" password com o salt gerado

    db.Insert(username, hashed_password, salt);
}

Note: Attention, do not confuse hashing with encryption. MD5 and' a hash algorithm, not encryption. Moreover, has already been proven in 1995 and 2004 that the MD5 algorithm has serious faults and should not be used. Instead, it uses SHA256 or SHA512.

Encryption algorithms are used in other situations to prevent intercepted messages from being deciphered or altered, for example. There are symmetric (AES) or asymmetric (RSA) algorithms).

If I use encryption, my system will be very slow with many users logging in at the same time?

Hashing algorithms are very fast, especially when the input is small, as in the case of passwords. In addition, safety always comes before performance. Performance can be improved later by climbing vertically or horizontally.

  • 1

    Sorry @bigown, submiti an issue right after' your :x changes have been deleted! Still, thanks for Edit!

  • The method you suggest is the correct one, but I understood that the question would be about simpler cases, where you can’t/can’t use a database. Or did I misunderstand?

    • "that" above = "either".
  • Actually the author did not mention databases.. I assumed that some data persistence system will be used.. An application cannot keep the information of all users in memory permanently...

0

How you process passwords in your code is irrelevant. What matters is how you store them for example in the database.

In your code you are not storing in the database, but only in a class variable. So it makes no sense to use any hash or encryption function as this will not add any security to your script.

What you have to worry about hashes is only when it is storing in the database.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.