소금 줄은 어디에 보관합니까?

데이터베이스 저장소의 암호를 해시 할 때 항상 적절한 항목 별 솔트 문자열을 사용했습니다. 필자의 필요에 따라 해시 된 암호 옆에 DB에 소금을 저장하는 것이 항상 잘 작동했습니다.

그러나 어떤 사람들은 소금을 데이터베이스와 별도로 저장하는 것이 좋습니다. 데이터베이스가 손상된 경우에도 공격자는 특정 솔트 문자열을 고려하여 레인보우 테이블을 만들어 한 번에 하나의 계정을 크래킹 할 수 있습니다. 이 계정에 관리자 권한이 있으면 다른 사람을 크래킹하지 않아도됩니다.

보안 측면에서 소금을 다른 곳에 보관하는 것이 가치가 있습니까? 동일한 머신에 서버 코드 및 DB가있는 웹 애플리케이션을 고려하십시오. 솔트가 해당 머신의 플랫 파일에 저장되면 데이터베이스가 손상되면 솔트 파일도 손상 될 수 있습니다.

이에 대한 권장 솔루션이 있습니까?

레인보우 테이블의 요점은 사전에 생성되어 다른 사람들의 계산 시간을 절약하기 위해 대량으로 배포된다는 것입니다. 즉, 레인보우 테이블을 생성하는 데 암호 + 소금 조합을 직접 크랙하는 것만 큼 오래 걸립니다. 레인보우 테이블을 생성 할 때 수행되는 작업은 해시를 강제로 수행하는 계산을 사전 실행하는 것입니다.) 따라서 누군가가 "레인보우 테이블을 생성 할 수있는 소금을 알면 허위입니다.

솔트가 사용자별로 존재하는 한 별도의 파일에 솔트를 저장하는 데는 아무런 의미가 없습니다. 솔트의 요점은 단순히 하나의 레인보우 테이블이 DB의 모든 암호를 깰 수 없도록 만드는 것입니다.

나는 이것에 대해 약간 다른 테이크를 제공 할 것이다.

나는 항상 소금에 절인 암호 해시와 섞인 소금을 저장합니다.

예를 들어, 나는 소금의 첫 절반을 암호의 소금에 절인 해시 앞에 놓고 소금의 마지막 절반을 암호의 소금에 절인 해시 뒤에 놓습니다. 응용 프로그램은이 디자인을 알고 있으므로이 데이터를 가져 와서 소금과 소금에 절인 암호 해시를 얻을 수 있습니다.

이 접근법에 대한 나의 근거 :

암호 / 해시 데이터가 손상되어 공격자의 손에 들어가면 공격자는 데이터를 살펴보면 소금이 무엇인지 알 수 없습니다. 이런 식으로 공격자는 해시와 일치하는 암호를 얻기 위해 실제로 무차별 대입 공격을 수행 할 수 없습니다. 해시를 시작할지 모르고 데이터의 어떤 부분이 소금의 일부인지 알 수 없기 때문입니다. 솔트 된 비밀번호 해시의 일부 ( 응용 프로그램의 인증 로직을 모르는 경우 제외) ).

솔트 된 암호 해시가있는 그대로 저장되면, 솔트 및 해시 된 경우 솔트 된 암호 해시와 동일한 데이터를 생성하는 암호를 얻기 위해 무차별 대입 공격을 수행 할 수 있습니다.

그러나 예를 들어, 소금에 절인 암호 해시가있는 그대로 저장되었지만 단일 바이트로 미리 추가 된 경우에도 공격자가 첫 번째 바이트를 폐기해야한다는 사실을 모르면 어려움이 증가합니다. 공격의. 응용 프로그램은 사용자를 인증하는 데 사용될 때 데이터의 첫 바이트를 버리는 것을 알고 있습니다.

이것에 대한 결론 ..

1) 인증 응용 프로그램이 사용하는 데이터를 정확한 형식으로 저장하지 마십시오.

2) 가능하면 보안 강화를 위해 인증 논리를 비밀로 유지하십시오.

한 걸음 더 나아갑니다.

응용 프로그램의 인증 논리를 비밀로 유지할 수없는 경우 많은 사람들이 데이터가 데이터베이스에 저장되는 방식을 알고 있습니다. 그리고 소금과 함께 섞인 소금에 절인 해시를 저장하기로 결정했다고 가정 해 봅시다.

임의 소금을 생성 할 때, 소금에 절인 암호 해시 전후에 소금의 비율을 무작위로 결정할 수도 있습니다.

예를 들어 512 바이트의 임의 소금을 생성합니다. 비밀번호에 솔트를 추가하고 솔트 된 비밀번호의 SHA-512 해시를 얻습니다. 또한 임의의 정수 200을 생성합니다. 그런 다음 처음 200 바이트의 소금을 저장 한 다음 소금에 절인 암호 해시와 나머지 소금을 저장합니다.

사용자의 비밀번호 입력을 인증 할 때 응용 프로그램은 문자열을 통과하고 데이터의 첫 1 바이트는 솔트의 첫 1 바이트이고 솔트 해시가 뒤따른다고 가정합니다. 이 패스는 실패합니다. 응용 프로그램은 처음 2 바이트의 데이터를 솔트의 첫 2 바이트로 계속 사용하고 처음 200 바이트를 솔트의 첫 200 바이트로 사용한 후 긍정적 결과가 나올 때까지 반복합니다. 암호가 틀리면 응용 프로그램은 찾을 수 없을 때까지 모든 순열을 계속 시도합니다.

이 접근법의 장점 :

보안 강화-인증 로직을 알고 있더라도 컴파일시 정확한 로직을 알 수 없습니다. 정확한 논리에 대한 지식이 있어도 무차별 대입 공격을 수행하는 것은 사실상 불가능합니다. 소금의 길이가 길수록 안전성이 더 높아집니다.

이 접근법의 단점 :

정확한 로직은 런타임에 유추되므로이 방법은 CPU를 많이 사용합니다. 솔트의 길이가 길수록이 방법은 CPU를 많이 사용합니다.

잘못된 비밀번호를 인증하면 CPU 비용이 가장 많이 듭니다. 이는 합법적 인 요청에 비생산적 일 수 있지만 공격자에 대한 보안을 강화합니다.

이 방법은 다양한 방식으로 구현 될 수 있으며 가변 너비 솔트 및 / 또는 솔트 비밀번호 해시를 사용하여 더욱 안전하게 만들 수 있습니다.

종종 해시 앞에 붙고 같은 필드에 저장됩니다.

별도로 저장할 필요가 없습니다. 요점은 각 비밀번호에 대해 임의의 솔트를 사용하여 단일 레인보우 테이블을 전체 비밀번호 해시 세트에 사용할 수 없도록하는 것입니다. 무작위 소금을 사용하는 경우 공격자는 각 해시를 개별적으로 무차별 처리해야합니다 (또는 가능한 모든 소금에 대한 레인보우 테이블 계산-훨씬 더 많은 작업).

보다 안전한 저장 위치가 있다면 해시를 저장하는 것이 좋습니다.

William Penberthy의 ASP.NET MVC 4 웹 애플리케이션 개발 책을 기반으로 :

1. 별도의 데이터베이스에 저장된 솔트에 액세스하려면 해커가 두 개의 서로 다른 데이터베이스를 해킹하여 솔트 및 솔트 된 비밀번호에 액세스해야합니다. 비밀번호와 동일한 테이블 또는 동일한 데이터베이스의 다른 테이블에 저장하면 해커가 데이터베이스에 액세스 할 때 솔트 및 비밀번호 해시 모두에 액세스 할 수 있습니다. 보안에는 시스템에 대한 해킹이 너무 비싸거나 시간이 많이 걸리는 프로세스가 포함되기 때문에 해커가 얻는 액세스 수를 두 배로 늘리면 시스템의 보안이 강화됩니다.
2. 사용하기 쉬우므로 염분을 해시 된 비밀번호와 동일한 데이터베이스에 유지해야합니다. 두 개의 데이터베이스가 항상 동시에 사용 가능하고 항상 동기화되어 있는지 확인하지 않아도됩니다. 개인의 암호를 쉽게 발견 할 수 있지만 시스템의 암호를 해독하는 데 필요한 힘의 양이 많기 때문에 각 사용자가 임의의 소금을 사용하는 경우 소금을 사용하는 이점은 최소화됩니다. 이 수준의 논의에서는 암호를 보호하는 것이 실제로 기대되는 것입니다. 해커가 데이터베이스 사본을 확보 한 경우 애플리케이션 데이터가 이미 손상되었습니다. 이 시점에서 문제는 공유 암호의 가능성으로 인한 사용자 위험을 완화하는 것입니다.
3. 두 개의 개별 연결된 데이터베이스를 유지 관리해야하는 요구 사항은 광범위합니다. 물론 보안에 대한 인식이 높아지지만 유일한 이점은 단일 데이터 요소 인 암호를 보호한다는 것입니다. 데이터베이스의 모든 필드가 개별적으로 암호화되고 동일한 소금이 사용 된 경우 시스템의 기본 보안이 향상되므로 데이터와 별도로 저장하는 것이 더 합리적입니다.

소금의 요점은 모든 무지개 테이블을 쓸모 없게 만들고 새로운 세트를 만들어야한다는 것입니다. 무지개 테이블을 만드는 것처럼 문자열을 추측하는 데 시간이 오래 걸립니다. 예를 들어 "password"의 SHA-256 해시는 5e88 4898 da28 0471 51d0 e56f 8dc6 2927 7360 3d0d 6aab bdd6 2a11 ef72 1d15 42d8입니다. "badpassword"와 같은 솔트가 추가 된 후 해시 될 새 문자열은 "passwordbadpassword"이며, 이는 눈사태 효과로 인해 출력을로 크게 변경합니다 457b f8b5 37f1 802e f9c8 2e46 b8d3 f8b5 721b 7cbb d485 f0bb e523 bfbe 73e6 58d6.

일반적으로 소금은 암호와 동일한 데이터베이스에 저장됩니다. 또한 한 데이터베이스가 해킹되면 다른 데이터베이스도 해킹 될 수 있기 때문입니다.