Pare de armazenar senhas! Freqüentemente, vejo código de pessoas que não sabem o quão perigoso é ou como armazenar corretamente as credenciais do usuário. Os muitos hacks do Anonymous no ano passado que resultaram no vazamento de senhas de usuários também mostram que muitos sites ainda armazenam senhas em texto não criptografado ou criptografado.
Aqui está como é feito da maneira certa para que você nunca armazene uma senha! Depois disso ou eu preciso quebrar você: D.
Os maiores problemas com o armazenamento de senhas são:
É sempre possível que alguém tenha acesso ao seu banco de dados, mesmo que não esteja diretamente exposto ao mundo externo, o que nunca deveria acontecer. Seja qual for o material de segurança que você colocou lá para proteger seu banco de dados, é uma boa ideia presumir que, mais cedo ou mais tarde, alguém será capaz de quebrar seus esforços de segurança e conseguir ler os dados. Você realmente não deseja armazenar senhas em texto simples. Você também não deseja armazenar senhas criptografadas porque os dados criptografados sempre podem ser descriptografados. E se as pessoas obtiverem acesso a essas senhas criptografadas mesmo que não devessem, seria sensato presumir que elas também sabem como descriptografá-las ou que não demorará muito para descobri-lo.
A solução:
Armazene uma versão hash da senha usando um algoritmo criptográfico unilateral forte e um valor salt exclusivo por senha. Se o algoritmo criptográfico for unilateral, isso significa que você não pode aplicar outro algoritmo para obter o valor de origem original novamente. A única maneira de comparar as senhas é aplicar o algoritmo criptográfico em uma determinada senha usando o valor salt usado originalmente e, em seguida, comparar o hash resultante com o que você armazenou. Se forem idênticos, a senha fornecida é a mesma que foi usada originalmente. Se forem diferentes, a senha é inválida.
Os invasores ainda podem empregar tabelas de arco-íris para tentar encontrar valores de senha que gerem os mesmos hashes que aqueles em seu banco de dados. Gerar tabelas de arco-íris leva muito tempo e também leva muitos botnets de máquinas, por isso torna muito mais difícil para os invasores encontrarem as senhas. É por isso que é tão importante usar um valor salt exclusivo por senha. Isso efetivamente significa que uma tabela arco-íris teria que ser gerada para cada valor de sal que você usou, tornando praticamente inviável encontrar os valores de senha originais.
Exemplo de prova de conceito. No Node.js, mas isso pode ser aplicado com qualquer linguagem que você esteja usando PHP. Exemplo também está no meu link .
NODEJS
um exemplo de modelo de usuário do banco de dados mongo seria parecido com o seguinte, mas eu configurei um repositório git com fonte comentada para que você possa aprender melhor! ligação
var mongoose = require('mongoose'),
crypto = require('crypto'),
uuid = require('node-uuid'),
Schema = mongoose.Schema,
ObjectId = Schema.ObjectId;
var userSchema = new Schema({
name: { type: String, required: true, unique: true },
email: { type: String, required: true },
salt: { type: String, required: true, default: uuid.v1 },
passwdHash: { type: String, required: true }
});
var hash = function(passwd, salt) {
return crypto.createHmac('sha256', salt).update(passwd).digest('hex');
};
userSchema.methods.setPassword = function(passwordString) {
this.passwdHash = hash(passwordString, this.salt);
};
userSchema.methods.isValidPassword = function(passwordString) {
return this.passwdHash === hash(passwordString, this.salt);
};
mongoose.model('User', userSchema);
module.exports = mongoose.model('User');Se você estiver interessado, vá para o git, você provavelmente entenderá, pois há 4 arquivos no fluxo completo! criar usuário -> com modelo db -> exemplo de entrada db resultante -> e método de autenticação final