소금(암호촬영)

Salt (cryptography)
기타 용도는 소금(동음이의)을 참조하십시오.

암호학에서 salt는 데이터, 패스워드 또는 패스프레이즈를 [1][full citation needed]해시하는 단방향 함수의 추가 입력으로 사용되는 랜덤 데이터입니다.소금은 저장소에서 암호를 보호하기 위해 사용됩니다.이전에는 패스워드의 암호화 해시함수만 시스템에 저장되었지만 시간이 지남에 따라 중복되거나 일반적인 패스워드가 식별되지 않도록 보호하기 위한 추가 세이프가드가 개발되었습니다(해시가 [2]동일하기 때문에).소금에 절이는 것은 그러한 보호 중 하나이다.

패스워드마다 새로운 솔트가 랜덤하게 생성됩니다.일반적으로 salt와 password(또는 키 확장 후의 버전)는 연결되어 암호화 해시 함수에 공급되며 출력 해시 값(원래 패스워드는 제외)은 salt와 함께 데이터베이스에 저장됩니다.해싱을 사용하면 나중에 인증할 때 보관하지 않고 인증할 수 있으므로 인증 데이터 스토어가 손상되었을 경우 일반 텍스트비밀번호가 노출될 수 있습니다.이로 인해 공격자가 해시 값과 솔트를 사용하여 데이터베이스에 액세스할 수 있더라도 해당 솔트를 올바르게 사용하면 일반적인 [1]공격을 방지할 수 있으므로 솔트는 해시 패스워드 자체와 별도로 암호화하거나 저장할 필요가 없습니다.

소금은 사용자에게 부담을 주지 않고 성공적인 공격에 필요한 테이블의 크기를 엄청나게 크게 만들 수 있기 때문에 미리 계산된 테이블(예: 무지개 테이블)[3]을 사용하는 공격으로부터 보호합니다.소금은 서로 다르기 때문에 동일한 패스워드의 인스턴스마다 다른 소금에 절인 해시가 생성되기 때문에 중복된(일반적으로 사용되는, 재사용되는 등) 패스워드도 보호합니다.

암호화 솔트는 Unix 시스템 인증 정보에서 인터넷 보안에 이르기까지 많은 최신 컴퓨터 시스템에서 널리 사용됩니다.

소금은 암호 난스의 개념과 밀접한 관련이 있다.

사용 예

다음은 비밀번호 저장용 솔트 값의 불완전한 예입니다.이 첫 번째 테이블에는 2개의 사용자 이름과 비밀번호 조합이 있습니다.비밀번호가 저장되지 않았습니다.

사용자 이름 암호
user1 password123
user2 password123

salt 값은 랜덤으로 생성되며 임의의 길이를 지정할 수 있습니다.이 경우 salt 값은 8바이트입니다.salt 값은 일반 텍스트비밀번호에 부가되며 그 결과 해시됩니다.이 값은 해시 값이라고 불립니다.소금값과 해시값이 모두 저장됩니다.

사용자 이름 염가 해시할 문자열 해시 값 = SHA256(암호 + 소금 값)
user1 E1F53135E559C253 password123E1F53135E559C253 72AE25495A7981C40622D49F9A52E4F1565C90F048F59027BD9C8C8900D5C3D8
user2 84B03D034B409D4E password12384B03D034B409D4E B4B6603ABC670967E99C7E7F1389E40CD16E78AD38EB1468EC2AA1E62B8BED3A

위의 표에 나타나 있듯이 salt 값이 다르면 평문 비밀번호가 완전히 동일한 경우에도 완전히 다른 해시 값이 생성됩니다.또한 공격자가 실질적으로 해시를 사전 계산할 수 없기 때문에 사전 공격은 어느 정도 완화됩니다.그러나 소금은 일반적이거나 쉽게 추측되는 비밀번호를 보호할 수 없습니다.

salt를 사용하지 않을 경우 해시 값은 지정된 비밀번호를 가진 모든 사용자에 대해 동일하기 때문에 해커가 해시 값에서 패스워드를 쉽게 추측할 수 있습니다.

사용자 이름 해시할 문자열 해시 값 = SHA256
user1 password123 57DB1253B68B6802B59A969F750FA32B60CB5CC8A3CB19B87DAC28F541DC4E2A
user2 password123 57DB1253B68B6802B59A969F750FA32B60CB5CC8A3CB19B87DAC28F541DC4E2A

흔한 실수

소금 재사용

모든 패스워드에 같은 소금을 사용하는 것은 위험합니다.소금을 설명하는 미리 계산된 표는 소금을 쓸모없게 하기 때문입니다.

모든 암호에 대해 고유한 솔트를 사용하는 데이터베이스에 대해 사전 계산된 테이블을 생성하는 것은 계산 비용이 들기 때문에 실행할 수 없습니다.단, 모든 엔트리에 공통의 salt가 사용되고 있는 경우 그러한 테이블(salt를 설명하는 것)을 작성하면 실행 가능하고 성공할 가능성이 있는 [4]공격이 됩니다.

salt reuse를 사용하면 동일한 비밀번호를 가진 사용자가 동일한 해시를 가질 수 있으므로 단일 해시를 크래킹하면 다른 비밀번호도 손상될 수 있습니다.

쇼트소금

salt가 너무 짧을 경우 공격자는 가능한 모든 salt에 대한 표를 미리 계산할 수 있습니다.긴 소금을 사용하는 것은 그러한 테이블이 엄청나게 [5]클 것을 보장합니다.

혜택들

1개의 패스워드와 그 세트의 크래킹의 차이를 이해하려면 , 유저와 해시 패스워드가 있는 파일에 대해 검토해 주세요.파일이 무염이라고 합니다.그런 다음 공격자는 문자열을 선택하고 시도[0]라고 한 다음 해시(attempt[0])를 계산할 수 있습니다.파일에 저장된 해시가 해시(attempt[0])인 사용자는 암호 시도[0]가 있을 수도 있고 없을 수도 있습니다.단, attempt[0]가 사용자의 실제 비밀번호가 아니더라도 시스템은 입력한 비밀번호의 해시를 계산하여 파일에 저장된 해시와의 비교를 통해서만 비밀번호를 확인할 수 있기 때문에 실제 비밀번호와 동일하게 받아들여집니다.따라서 일치할 때마다 사용자 패스워드가 크래킹되고 파일 내의 패스워드 수에 따라 일치 가능성이 높아집니다.반면 솔트를 사용할 경우 공격자는 해시(attempt[0] salt[a])를 계산하고 엔트리 A와 비교한 다음 해시(attempt[0] salt[b]를 비교하고 엔트리 B와 비교해야 합니다.이렇게 하면 솔트 재사용을 [6]피할 수 있기 때문에 한 번의 시도가 여러 개의 비밀번호를 깨는 것을 방지할 수 있습니다.

소금은 [7]또한 암호를 해독하기 위해 미리 계산된 표를 사용하는 것과도 싸웁니다.이러한 테이블은 일반적인 패스워드를 단순히 해시에 매핑하거나 미리 계산된 해시 체인 세트의 시작점과 끝점을 저장하는 등 더 복잡한 작업을 수행할 수 있습니다.어느 경우든 염분은 해시를 길게 하고 큰 문자 집합에서 끌어냄으로써 미리 계산된 표의 사용을 방지할 수 있으므로 테이블이 결과 해시를 덮을 가능성이 낮아집니다.특히 미리 계산된 테이블은 단순히 [해시]가 아니라 [솔트+해시] 문자열을 커버해야 합니다.

패스워드 해시 및 기타 보안 데이터가 비공개 파일에 저장되는 최신 섀도 패스워드 시스템은 이러한 우려를 어느 정도 덜어줍니다.단, 패스워드 또는 패스워드 해시를 여러 시스템에 푸시하기 위해 일원화된 패스워드 관리 시스템을 사용하는 멀티 서버 설치에서는 여전히 유효합니다.이러한 설치에서는 각 개별 시스템의 루트 계정은 집중형 패스워드 시스템의 관리자보다 신뢰도가 낮은 것으로 취급될 수 있으므로 고유한 salt 값의 생성을 포함한 패스워드 해시 알고리즘의 보안이 [citation needed]충분한지 확인하는 것이 중요합니다.

솔트의 또 다른 (낮은) 장점은 다음과 같습니다.두 사용자가 비밀번호와 같은 문자열을 선택하거나 같은 사용자가 두 대의 머신에서 동일한 비밀번호를 사용할 수 있습니다.솔트가 없으면 이 비밀번호는 비밀번호 파일에 동일한 해시 문자열로 저장됩니다.이렇게 하면 두 계정이 동일한 암호를 가지고 있다는 사실을 알 수 있으므로 계정 중 하나의 암호를 아는 사람은 다른 계정에 액세스할 수 있습니다.두 개의 랜덤한 문자로 비밀번호를 솔트함으로써 두 개의 계정이 동일한 비밀번호를 사용하더라도 해시 읽기만으로는 아무도 이를 발견할 수 없습니다.

UNIX의 실장

1970~1980년대

이전 버전의 Unix에서는 패스워드 파일이 사용되었습니다. /etc/passwdsaluted password(2글자 랜덤솔트 프리픽스)의 해시를 저장합니다.이러한 이전 버전의 Unix에서는 salt는 passwd 파일(클리어 텍스트)에도 salt와 salt의 해시와 함께 저장되었습니다.패스워드 파일은 시스템의 모든 사용자가 공개적으로 읽을 수 있었습니다.이는 사용자 특권 소프트웨어 도구가 사용자 이름 및 기타 정보를 검색할 수 있도록 하기 위해 필요했습니다.따라서 패스워드의 보안은 목적으로 사용되는 단방향 함수(암호화 또는 해시)에 의해서만 보호됩니다.초기 Unix 구현에서는 패스워드를 8자로 제한하고 12비트솔트를 사용했습니다.이것에 의해, 4,096개의 [8]salt치를 사용할 수 있습니다.이는 1970년대 컴퓨팅 비용과 스토리지 [9]비용에 대한 적절한 균형이었습니다.

1980년대-

참고 항목: Passwd » Shadow file

섀도 패스워드 시스템은 해시 및 솔트에 대한 접근을 제한하기 위해 사용됩니다.salt는 8자, 해시는 86자, 비밀번호 길이는 무제한입니다.

웹 응용 프로그램 구현

일반적으로 웹 응용 프로그램은 사용자의 암호 해시 값을 데이터베이스에 저장합니다.salt가 없으면 SQL 주입 공격이 성공하면 쉽게 깨질 수 있는 암호가 생성될 수 있습니다.많은 사용자가 여러 사이트의 비밀번호를 재사용하기 때문에 salt 사용은 전체 웹 애플리케이션 [10]보안의 중요한 구성요소입니다.특정 언어 또는 라이브러리(PHP, )에서 salt를 사용하여 패스워드 해시를 보호하기 위한 추가 참고 자료입니다.NET 라이브러리 등)는, 다음의 외부 링크의 항에 기재되어 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b "Download Limit Exceeded". citeseerx.ist.psu.edu. Retrieved 2021-05-14.
  2. ^ Anderson, Ross (2020). Security engineering : a guide to building dependable distributed systems (Third ed.). Indianapolis, Indiana. ISBN 978-1-119-64281-7. OCLC 1224516855.
  3. ^ Godwin, Anthony (10 September 2021). "Passwords Matter". Retrieved 2016-12-09.{{cite web}}: CS1 maint :url-status (링크)
  4. ^ "Secure Salted Password Hashing - How to do it Properly". crackstation.net. Retrieved 2021-03-19.
  5. ^ "Secure Salted Password Hashing - How to do it Properly".
  6. ^ "Password Storage - OWASP Cheat Sheet Series". cheatsheetseries.owasp.org. Retrieved 2021-03-19.
  7. ^ "How Rainbow Tables work". kestas.kuliukas.com.
  8. ^ Morris, Robert; Thompson, Ken (1978-04-03). "Password Security: A Case History". Murray Hill, NJ, USA: Bell Laboratories. Archived from the original on 2013-08-21. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  9. ^ "How Unix Implements Passwords [Book]".
  10. ^ "ISC Diary – Hashing Passwords". Dshield.org. Retrieved 2011-10-15.

외부 링크