사용자 정보와 사용자 로그인 및 비밀번호를 가장 잘 저장하는 방법

사용자 정보와 사용자 로그인 및 비밀번호를 가장 잘 저장하는 방법

Mysql을 사용하고 있는데 사용자 개인 정보와 로그인 및 비밀번호를 두 개의 테이블로 분리한 후 둘 중 하나만 참조하는 것이 낫다고 생각했습니다.

참고 : 제 게시물을 명확히 하기 위해 비밀번호 보안 기술(해시, 소금 등)을 이해합니다.저는 제 삶의 다른 부분(투자, 데이터 백업, 심지어 개인 스토리지)의 관행을 따르고 있다면 최악의 경우(표나 화재)에는 표 간에 정보를 분할하는 것이 추가 데이터를 보호할 수 있다는 것을 알고 있습니다.

비밀번호를 저장하지 마십시오.디스크에 저장된 적이 있으면 도난당할 수 있습니다.대신 암호 해시를 저장합니다.bcrypt(소금 포함)와 같이 올바른 해싱 알고리즘을 사용합니다.

편집: OP는 위 문제를 이해한다고 답변했습니다.

로그인과 물리적으로 다른 테이블에 암호를 저장할 필요가 없습니다.하나의 데이터베이스 테이블이 손상된 경우, 동일한 데이터베이스에 있는 다른 테이블에 액세스하는 것은 큰 도약이 아닙니다.

보안 및 보안에 대해 깊이 고민하는 경우 도메인 데이터와 완전히 별개의 데이터 저장소에 사용자 자격 증명을 저장하는 것을 고려해 볼 수 있습니다.일반적으로 수행되는 한 가지 방법은 LDAP 디렉토리 서버에 자격 증명을 저장하는 것입니다.이는 나중에 수행하는 모든 싱글 사인온 작업에도 도움이 될 수 있습니다.

암호는 일반 텍스트를 읽지 못하도록 하는 가역적이지 않은 작업인 암호 해시로 저장되어야 합니다.사용자를 인증할 때 암호 입력은 동일한 해싱 과정을 거치고 해쉬를 비교합니다.

MD5 또는 SHA1과 같은 빠르고 저렴한 해시를 사용하지 마십시오. 목적은 공격자가 (해시 충돌을 기반으로) 레인보우 테이블을 계산하는 데 비용이 많이 드는 것입니다. 빠른 해시는 이에 대응합니다.한 번의 해시 실행에는 영향을 미치지 않으므로 값비싼 해시를 사용하는 것은 인증 시나리오에 문제가 되지 않습니다.

해시 이외에도 임의로 생성된 값으로 해시를 솔트합니다. 논스는 데이터베이스에 저장되고 해시 전에 데이터와 연결됩니다.이는 충돌 계산 시 생성해야 하는 가능한 조합의 수를 증가시켜 무지개 테이블 생성의 전체 시간 복잡도를 증가시킵니다.

암호 해시 열은 고정 길이일 수 있습니다. 암호 해시는 고정 길이로 인코딩할 수 있는 값을 출력해야 하며, 이 값은 모든 해시에서 동일합니다.

을 사용하지 : 하면 하지 을 합니다 과 합니다 하면 )bcrypt.

비밀번호를 다루는 방법과 고민해야 할 사항에 대한 훌륭한 설명은 http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes 에서 확인할 수 있습니다.

마지막으로, 공격자가 데이터베이스에 접근할 수 있는 경우, 공격자가 접근할 수 있는 민감한 정보 또는 개인적으로 식별할 수 있는 정보와 그로 인해 발생할 수 있는 피해에 대해 즉각적인 관심이 필요합니다.

그것들을 같은 테이블에 놓는 것은 문제가 없습니다.사실은 훨씬 빠를 테니까 적극 추천하고 싶어요.나는 당신이 왜 그것을 나누려고 하는지 모르겠습니다.

당신의 원래 질문에 대답해 보겠습니다.수집할 개인 정보가 많지 않다면 한 테이블에 모두 담아두는 것도 좋습니다.그렇다면 그것을 나누는 것이 타당할 수도 있습니다.이 결정은 현재 다루고 있는 개인 정보의 양과 접근해야 하는 빈도에 따라 내려져야 합니다.

대부분의 경우 한 테이블에서 이와 같은 작업을 수행합니다.

UserID, FirstName, LastName, Email, Password, TempPassword

하지만... 그 이상의 것들을 모으고 있다면요.전화, 팩스, 생년월일, 전기 등을 수집하고 있다고 가정합니다.대부분의 정보에 거의 접근할 수 없다면, 저는 아마도 그것을 자신의 테이블에 놓고 일대일 관계로 연결할 것입니다.결국, 테이블에 있는 열의 수가 적을수록 해당 테이블에 대한 쿼리 속도가 빨라집니다.또한 가장 많이 액세스되는 테이블을 단순화하는 것이 합리적인 경우도 있습니다.JOIN에는 성능 히트가 있지만 해당 개인 정보에 액세스해야 할 때마다 이를 고려해야 합니다.

편집 -- 있잖아요, 방금 생각난 게 있어요.사용자 이름 또는 전자 메일 필드에 인덱스를 만들면(원하는 대로) 사용자 테이블에 열을 너무 많이 만들 때 발생하는 성능상의 단점을 거의 완전히 제거할 수 있습니다.왜냐하면 로그인할 때마다 WHERE 절은 인덱스가 있으면 사용자 이름을 매우 빨리 찾을 수 있고 해당 테이블에 열이 100개 있어도 문제가 되지 않기 때문입니다.그래서 제 생각을 바꿨습니다. 한 테이블에 다 담았습니다. ;)

어느 경우든 보안은 인기 있는 주제인 것 같기 때문에 암호는 해시 값이어야 합니다.SHA1(또는 SHA256)을 추천합니다.TempPassword도 해시를 사용해야 하며, 암호를 잊어버린 기능에 대해서만 해당됩니다.해시를 사용하면 암호를 해독하여 사용자에게 원래 암호를 보낼 수 없습니다.대신 로그인할 수 있는 임시 비밀번호를 생성한 다음 로그인 후 비밀번호를 다시 변경하도록 강제합니다.

이 모든 데이터가 항상 사용자와 1:1 관계를 유지할 수 있습니까?사용자가 여러 개의 주소, 전화 번호 등을 가질 수 있도록 허용하는 것을 방지할 수 있다면, 개인 정보를 별도의 테이블로 분리하는 것이 좋습니다.

첫째, (바라건대) 명백한 것을 언급하자면, 사용자 이름과 암호를 저장하는 것을 피할 수 있다면, 이는 큰 책임이며, 자격 증명 저장소가 침해될 경우 (암호 공유로 인해) 동일한 사용자에게 다른 많은 장소에 대한 액세스를 제공할 수 있습니다.

자격 증명을 저장해야 하는 경우:

• 가역적 형태를 저장하지 말고 SHA-256과 같은 인식된 알고리즘을 사용하여 해시를 저장합니다.신뢰할 수 있는 신뢰할 수 있는 출처의 암호화 소프트웨어 사용 - 자신의 것을 굴리려고 시도하지 마십시오. 틀릴 가능성이 높습니다.
• 각 자격 증명 집합에 대해 해시된 데이터와 함께 소금을 저장합니다. 두 개의 동일한 암호가 동일한 해시를 생성하지 않도록 해시를 "프라임"하는 데 사용됩니다.
• 보안 랜덤 생성기를 사용합니다.암호 알고리즘이 아닌 암호화 관련 보안 실패의 가장 큰 원인은 약한 무작위성입니다.

가역 인증 정보를 저장해야 하는 경우:

• 양호한 암호화 알고리즘 - AES-256, 3DES(date) 또는 공개 키 암호를 선택합니다.신뢰할 수 있는 신뢰할 수 있는 출처의 암호화 소프트웨어 사용 - 자신의 것을 굴리려고 시도하지 마십시오. 틀릴 가능성이 높습니다.
• 각 자격 증명 집합에 대해 암호화된 데이터와 함께 솔트(암호화되지 않은)를 저장합니다. 이는 암호가 동일한 두 암호가 동일한 암호 텍스트를 생성하지 않도록 암호화 암호를 "프라임"하는 데 사용됩니다.
• 보안 랜덤 생성기를 사용합니다.암호 알고리즘이 아닌 암호화 관련 보안 실패의 가장 큰 원인은 약한 무작위성입니다.
• 암호화/복호화 키를 데이터베이스와 별도로 응용프로그램 런타임 프로파일에만 액세스할 수 있는 O/S 보안 파일에 저장합니다.이렇게 하면 일반적으로 HDD에 액세스해야 하므로 DB에 오류가 발생한 경우(예: SQL 주입을 통해) 키가 자동으로 취약하지 않습니다.O/S에서 프로파일에 연결된 파일 암호화를 지원하는 경우 이를 사용합니다. 일반적으로 NTFS 암호화와 같이 도움이 될 뿐입니다.
• 실제적인 경우 기본 암호로 암호화된 키 자체를 저장합니다.이는 일반적으로 앱을 시작할 때 암호를 입력해야 함을 의미합니다. HDD가 고장난 경우 키 파일과 스크립트를 모두 볼 수 있다고 가정해야 하기 때문에 스크립트의 매개 변수로 암호를 제공하는 것은 도움이 되지 않습니다.
• 사용자 이름이 계정 레코드를 찾을 필요가 없는 경우 사용자 이름과 암호를 모두 암호화합니다.

개인적인 경험으로는 개인정보와 로그인 정보를 개별 데이터베이스에 저장하는 것이 가장 좋은 방법입니다.SQL 주입을 수행해야 하는 이유는 데이터 그룹 전체에 대한 액세스를 제공하는 것이 아니라, 침투자가 데이터와 관련된 데이터베이스의 내부 레이아웃을 알지 못하는 한 제한됩니다.

그러나 이 경우 더 많은 쿼리를 수행해야 하는 비용이 발생하여 성능이 저하될 수 있습니다.

동일한 테이블에 저장하고 단방향 암호화를 사용해야 합니다.MD5는 효과는 있겠지만 약하기 때문에 SHA1이나 다른 방법을 고려해 볼 수 있습니다.두 개의 물건을 따로 테이블에 보관하는 것은 아무런 이득이 없습니다.

언급URL : https://stackoverflow.com/questions/947618/how-to-best-store-user-information-and-user-login-and-password