단일 쿼리와 사용자 별 암호로 사용자 로그인

Question

데이터베이스에 저장된 사용자 별 소금을 사용하여 사용자 로그인을 구현하기로 결정했습니다. salt는 SHA로 해시되고 데이터베이스에 저장되는 암호의 접두어입니다.

이전에는 소금을 사용하지 않았지만 사용자가 입력 한 사용자 이름과 암호를 사용하여 쿼리에서 반환 된 행 수를 계산하는 일반적인 방법을 사용했습니다. 그러나 사용자 당 소금을 사용하면 저장된 암호 해시와 비교하기 전에 소금을 가져와야합니다.

두 개의 쿼리 (소금을 얻기 위해 1 회, 입력 자격 증명의 유효성을 검사하기 위해)를 피하기 위해 입력 된 사용자 이름을 기반으로 한 단일 쿼리에서 소금과 해쉬 된 암호를 가져 오기로 결정했습니다.

SELECT users.salt, users.password 
     FROM users 
     WHERE username = ?' 

와 같은 뭔가가 다음 서버 측 코드 (PHP)에서 내가 입력 된 암호를 사용하여 소금을 연결, 그것을 해시 이미 데이터베이스에서 가져온 암호를 비교합니다.

명확하지 않은 경우, 키 차이점은 데이터베이스에서이 작업을 수행하기 전에 후자의 방법으로 PHP wheras에서 자격 증명을 확인한다는 것입니다.

용어 보안에, 거기에이 방법의 단점 또는 다른

Answer 1

이 같은 한 쿼리에서이 작업을 수행 할 수 있습니다 :

SELECT 
    SHA1(CONCAT(users.salt, "password-input")) = users.passwordhash 
WHERE 
    username = "username-input" 

Answer 2

내가 그것을 어떠한 단점을 볼 수 없습니다. "gahooa"도 훌륭한 대답을했습니다. 처리 비용은 웹 서버에서 데이터베이스 서버로 이동하지만 이는로드에 더 적합한 처리량에 대한 질문 일뿐입니다.

Answer 3

... '서버 측 코드 (PHP)'의 서버입니까? DBMS가 서버이고 다른 모든 것이 클라이언트 인 세계에서 왔습니다. 나는 당신이 웹 서버를 '서버 측'으로보고 DBMS를 별도의 기즈모로보고 있다고 생각합니다. 서버 자체 일 필요는 없습니다. 아하 이런 관점의 상대성 이론입니다. (그리고 X11 서버와 클라이언트를 시작하지 마라.)

그렇습니다. 한 번의 작업으로 사용자 이름에 대한 소금과 해시 된 해쉬 된 암호를 수집 한 다음 SHA 결과를 생성하는 것이 합리적입니다 제공된 비밀번호와 PHP의 salt를 검색된 해시 된 비밀번호 값과 비교합니다. 암호가 PHP에서 데이터베이스 서버로 이동하지 않기 때문에 통신이 암호화되어 있는지 여부는 중요하지 않습니다 (PHP와 DBMS가 같은 컴퓨터에 있지 않은 경우). 또한 계산을 DBMS에서 PHP로 오프로드합니다. 이것이 이익이되는지 여부는 PHP와 DBMS의 상대적인 작업 부하에 달려 있습니다.

또 다른 대답이 지적한대로 사용자가 제공 한 암호를 DBMS로 보내고 DBMS에서 해시 계산을 수행하여 대답을 얻을 수 있습니다. 단순히 사용자의 입력을 인용하는 것에주의하십시오. SQL 주입을 방지하기 위해 그것을 피하십시오. 이것은 잠재적으로 패스워드를 PHP에서 DBMS 로의 이동 중에 스누핑하는 것으로 노출시킵니다. 중요한 것은 인프라에 따라 다릅니다.

Answer 4

나는 당신의 접근 방식이 일반적으로 바람직하다고 생각합니다. 사용하는 쿼리 수보다 중요한 것은 사용자가 잘못된 암호를 입력 한 경우에도 유효한 데이터베이스 암호를 유선으로 검색하는지 여부입니다. 귀하의 쿼리는 이것을 수행하는 반면, db 서버에서 암호화 기능을 사용함으로써 이것을 피하고 일을 더욱 안전하게합니다.

더 안전하게하려면 유선이나 다른 방법을 통해 SQL 쿼리를 스니핑하는 사람이 암호화 유형을 숨기는 저장 프로 시저 또는 함수를 사용하십시오 (예 : SQL 주입 취약점을 사용하거나 쿼리를 오류 메시지에 표시하여 쿼리를 볼 수있게하는 등).