사용자 비밀번호를 해싱하기 전에 정리해야 합니까?

사용자 비밀번호 정리

보안 애플리케이션을 개발할 때 개발자는 사용자가 제공한 비밀번호를 암호화하여 저장하기 전에 정리하는 것을 고려하는 경우가 많습니다. 그러나 해싱 전에 비밀번호 정리 메커니즘을 적용하면 특정 문제가 발생합니다.

해싱 전에 비밀번호 정리를 피하세요

escape_string( ), htmlspecialchars() 또는 addlashes()입니다. 주된 이유는 이러한 전처리가 중복되고 불필요하기 때문입니다.

비밀번호 저장에 일반적으로 사용되는 PHP의 비밀번호_해시() 함수에 의해 생성된 해시는 SQL 주입 위협을 일으키지 않습니다. 해싱 프로세스는 비밀번호를 SQL 주입으로 악용할 수 없는 해시로 변환합니다.

해시는 정리 없이 보안을 제공합니다

해싱 함수는 특정 문자에 특별한 의미를 할당하지 않습니다. ; 따라서 보안을 위해 정리가 필요하지 않습니다. 사용자가 공백 및 특수 문자를 포함하여 원하는 비밀번호를 지정할 수 있도록 함으로써 해싱은 내용에 관계없이 비밀번호의 보안을 보장합니다.

저장 고려 사항

기본값은 해싱 방법(PASSWORD_BCRYPT)은 60자 너비의 해시를 생성하므로 다음과 같이 저장 공간을 더 많이 할당하는 것이 좋습니다. 해싱 알고리즘의 향후 잠재적인 변경 사항을 수용하기 위한 VARCHAR(255) 또는 TEXT.

클렌징 비효율성의 예

"I'm a"디저트 토핑이라는 비밀번호를 고려하세요. " & <바닥 왁스>!". 다양한 삭제 방법을 적용하면 다른 결과가 나옵니다.

• trim()은 후행 공백을 제거합니다
• htmlentities() 및 htmlspecialchars()는 특수 문자와 큰따옴표를 인코딩합니다
• 슬래시( ) 이스케이프 문자 추가
• strip_tags() HTML 제거 태그

그러나 이러한 변환은 해시된 비밀번호의 보안에 영향을 미치지 않습니다. Password_verify()는 제공된 비밀번호와 데이터베이스에서 검색된 해시된 비밀번호에 동일한 정리 방법이 적용된 경우에만 성공합니다.

결론

결론적으로, Password_hash()를 사용하여 해싱하기 전에 비밀번호를 정리합니다. 그렇게 하는 것은 불필요하며 복잡해집니다. 대신 해싱 알고리즘이 제공하는 보안에 의존하고 잠재적인 저장 요구 사항을 고려하세요.

위 내용은 사용자 비밀번호를 해싱하기 전에 정리해야 합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!