데이터베이스 접속하기
Using functions to obfuscate the hash generation does not increase security. This is security by obscurity. The algorithm used to hash the data needs to be secure by itself.
I would not suggest to use other data as salt. For example if you use the username, you won't be able to change the values without rehashing the password.
I would use a dedicated salt value stored in the same database table.
Why? Because a lot of users use the same login credentials on different web services. And in case another service also uses the username as salt, the resulting hashed password might be the same!
Also an attacker may prepare a rainbow table with prehashed passwords using the username and other known data as salt. Using random data would easily prevent this with little programming effort.
암호화 저장 모델
SSL/SSH는 클라이언트에서 서버로 전송되는 데이터를 보호하지만, SSL/SSH가 데이터베이스에 저장된 지속 데이터를 보호하지는 않습니다. SSL는 연결용 프로토콜입니다.
공격자가 (웹 서버를 건너뛰고) 데이터베이스에 직접 접근할 수 있게 되면, 정보를 데이터베이스 자체에서 보호하지 않는 한 저장된 민감한 데이터가 유출되거나 오용될 수 있습니다. 데이터 암호화로 이런 위험을 줄일 수 있으나, 매우 적은 데이터베이스만 이러한 데이터 암호화를 지원합니다.
이 문제를 해결하기 위한 가장 쉬운 방법은 자체 암호화 패키지를 만들어, PHP 스크립트에서 사용하는 것입니다. PHP는 Mcrypt와 Mhash처럼, 다양한 암호화 알고리즘을 지원하는 확장으로 이 일을 도와줍니다. 스크립트에서 데이터베이스에 삽입하기 전에 데이터를 암호화하고, 꺼내올 때 해독합니다. 아래 에제를 참고해서 어떻게 암호화가 작동하는 지 확인하십시오.
원 표현이 필요하지 않은(즉, 표시되지 않는) 정말로 감춰진 데이터에 대해서는, 해시를 생각할 수 있습니다. 해시의 잘 알려진 예는 패스워드 대신에, 패스워드의 MD5 해시를 데이터베이스에 저장하는 것입니다. crypt()와 md5()를 참고하십시오.
Example #1 해시 패스워드 필드 사용하기
<?php
// 패스워드 해시 저장
$query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
pg_escape_string($username), md5($password));
$result = pg_query($connection, $query);
// 사용자가 올바른 패스워드를 입력했는지 질의
$query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",
pg_escape_string($username), md5($password));
$result = pg_query($connection, $query);
if (pg_num_rows($result) > 0) {
echo 'Welcome, $username!';
} else {
echo 'Authentication failed for $username.';
}
?>
add a note
User Contributed Notes
암호화 저장 모델
Reiner
21-Apr-2011 12:46
zyppora at nosmac yahoo dot com
14-Mar-2007 04:30
In addition to roysimkes at hotmail dot com:
If your passwords are so secret that they're worth a year's hacking/cracking/etc, you might want to consider 'password renewal', much like Windows' option. Tell your users to renew their passwords every x days/weeks/months to make it extra hard on those already-sweating malicious visitors.
somebody
26-Dec-2006 10:07
A better way to hash would be to use a separate salt for each user. Changing the salt upon each password update will ensure the hashes do not become stale.
Fairydave at the location of dodo.com.au
11-Feb-2006 06:58
I think the best way to have a salt is not to randomly generate one or store a fixed one. Often more than just a password is saved, so use the extra data. Use things like the username, signup date, user ID, anything which is saved in the same table. That way you save on space used by not storing the salt for each user.
Although your method can always be broken if the hacker gets access to your database AND your file, you can make it more difficult. Use different user data depending on random things, the code doesn't need to make sense, just produce the same result each time. For example:
if ((asc(username character 5) > asc(username character 2))
{
if (month the account created > 6)
salt = ddmmyyyy of account created date
else
salt = yyyyddmm of account created date
}
else
{
if (day of account created > 15)
salt = user id * asc(username character 3)
else
salt = user id + asc(username character 1) + asc(username character 4)
}
This wont prevent them from reading passwords when they have both database and file access, but it will confuse them and slow them up without much more processing power required to create a random salt