사용자가 암호를 변경할 때 이전 암호를 사용할 수 없도록해야한다는 과제가 있습니다. 이를 위해 Identity 프레임 워크가 비밀번호를 해쉬 할 때 비밀번호 해시를 저장합니다.암호 해시 ID 체계 및 소금
내 질문은 내가 최근에 선택한 사용자의 해시와 내가 저장 한 이전에 사용한 암호의 해시를 비교하는 방법입니다. 아이덴티티 프레임 워크가 사용하고있는 소금을 고려해야합니다.
업데이트 : 암호를 해시하는 데 appUserManager.PasswordHasher.HashPassword(passwordToHash)을 사용하고 있지만 매번 새로운 해시가 생성됩니다 (ID 프레임 워크에서 내부적으로 소금을 사용하고 있기 때문입니다).
사용자의 현재 암호 해시는 테이블/열 AspNetUsers.PasswordHash에 저장됩니다. 이것은 EF를 통해서도 가능합니다 : ApplicationDbContext.Users.PasswordHash.
그래서 사용자 테이블을 참조하는 고유 한 테이블을 만들어야하며 모든 비밀번호 변경시 이전 해시를 테이블에 복사해야합니다.
다음 단계는 새 암호가 이전 해시와 일치하지 않는지 확인하는 것입니다. 이를 위해 사용해야합니다 Microsoft.AspNet.Identity.PasswordHasher.VerifyHashedPassword(string hashedPassword, string providedPassword)
여기에서 hashedPassword은 역사적인 해시 테이블의 값이고 providedPassword은 새로운 제안 된 암호가됩니다.
그건 의미가 있습니다. 따라서 제안 된 암호를 해시 한 다음 해시가 이전에 해시 된 암호를 보유하고 있는지 확인하십시오. 모든 기존 해시 된 암호를 반복하고 각 암호를 비교해야 할 것 같습니다. – webworm
맞음! 이것은 염분과 해싱의 포인트입니다. 소금은 매번 달라지기 때문에 결과 해시가 매번 다를 수 있습니다. 동일한 암호를 10 번 해시하면 10 가지 해시 값이 부여됩니다. 그래서 예, 이전의 모든 암호를 반복하고'VerifyHashedPassword'를 통해 비교해야합니다. 시간이 지남에 따라 시간이 많이 걸리는 절차가 될 수 있으므로 오래된 해시의 수를 10-20 개로 제한합니다. – trailmax
이 aspnetcore 신원 또는 이전 버전? –
ASP.NET ID v2.2 – webworm
나는'UserManager .UpdateAsync (TUser user)'를 오버라이드하고 백엔드 히스토리 테이블을 사용한다고 말하고 싶다. 사용자가 자신의 암호를 변경하고 기록에있는 N 개의 암호 중 하나 인 경우'IdentityResult.Failed ("암호를 다시 사용할 수 없습니다.")와 함께 암호를 거부하십시오. –