사용자 이름과 암호를 읽고 응용 프로그램에서 나중에 읽을 수 있도록 저장해야하는 응용 프로그램을 작성 중입니다. 일부 변수에 저장하는 것은 어리석은 생각처럼 들립니다.응용 프로그램 내에서 암호 저장
KDE library이 발견되었지만 너무 많은 의존성이 있습니다. 사용법을 이해하기에는 너무 초보 프로그래머입니다.
암호를 저장하는 일반적인 방법은 무엇이며 어떻게 문제를 해결할 수 있습니까?
정보에 따라 수행 할 작업에 따라 다릅니다.
일부 외부 서비스에 액세스하기 위해 이름과 암호를 사용하려는 경우 (다음에 프로그램을 실행할 때 사용자가 정보를 다시 입력해야 함) 일부 변수에 저장하면 OK입니다. 핵심 덤프 또는 동등한 항목에 표시되지 않도록 암호화 된 암호를 저장하는 것이 좋습니다 (최소한 암호화 된 암호 저장). 암호가 필요할 때 암호를 해독하여 사용하고 암호 해독 된 버전이 저장되는 곳 (zapping)에 쓸 수 있습니다. (참고 :이 상황에서는 해싱이 적절하지 않으므로 암호를 볼 수 있어야하며 해시를 실행 취소 할 수 없습니다.) 프로그램 외부에 정보를 저장하도록 결정할 수도 있지만 필요없는 것 같습니다. 바이너리에는 여전히 암호화 키 (및 암호화 알고리즘)가 포함되어 있으며 암호화 된 데이터는 프로그램의 평균 내용보다 무작위 적이기 때문에 실제로 암호화 된 암호를 숨기는 것은 사실상 불가능합니다. 그러나 가장 어려운 공격자를 제외한 모든 공격자를 막을 수있을만큼 힘들 수 있습니다.
사용자 이름과 암호를 영구적 인 레코드로 저장하여 향후 동일한 사용자가 정보에 액세스하고 있음을 확인할 수있는 경우 프로그램 외부에 저장소를 사용해야합니다. 동시성 문제를 해결할 수 있도록 단순한 데이터베이스를 사용합니다.이 데이터베이스는 일반 텍스트 파일처럼 단순 할 수 있습니다. 이 경우 암호를 해시로 해시하고 사용자 이름, 소금 및 해시 암호를 저장하여 사용자 이름이 주어지면 다른 두 값을 쉽게 찾을 수 있습니다.
나이트 워커 코멘트 :
나는 일부 웹 데이터베이스에 액세스하기 위해 해당 암호를 사용하기 때문에 나는 그것이 처음 입력 한 후 내 응용 프로그램에 저장해야합니다. 평범한 텍스트 파일로 그 아이디어가 똑똑하다고 확신합니까?
'내 애플리케이션에 저장'하는 방법에 따라 다릅니다. 실행 파일을 수정할 수 없으며 적어도 그렇게하려고 시도해서는 안됩니다. 따라서 응용 프로그램 실행 파일과는 별도의 파일에 저장된 영구 기록으로보아야합니다. 다른 한편, 당신은 제가 설명했던 것과는 다른 문제에 직면 해 있습니다. 당신은 정보로 사용자를 인증하지 않습니다. 필요시 정보를 해독하여 다른 응용 프로그램으로 보내야합니다.
우선, 소금과 해시는 관련이 없다는 것을 의미합니다. 마스킹 작업을 취소해야하며 해시를 되돌릴 수 없습니다.
다음으로 재현시 응용 프로그램 사용자를 식별하는 방법을 결정해야합니다. 사용자가 자신의 데이터를 가져 오기 위해 암호를 입력해야하는지 아니면 단순히 운영 체제 권한이나 다른 구성표에 의존 할 것인지 결정해야합니다.
사용자가 응용 프로그램에 암호를 입력해야만하는 경우 사용자 이름을 암호화하기 위해 암호 (또는 응용 프로그램의 암호를 인식하는 데 사용되는 암호 해시와 다른 암호 해시)를 사용하는 것이 좋습니다./외부 응용 프로그램의 암호 조합 그런 다음 사용자 이름과 인수를 위해 암호화 된 암호의 Base-64 인코딩 버전을 텍스트 파일에 저장할 수 있습니다. 이것은 원래 소금에 절인 해시 형식으로 저장된 응용 프로그램 암호만큼 안전합니다. 사용자가 반환하면 응용 프로그램 사용자 이름과 암호를 제공해야하며 저장된 값에 대해 해당 조합의 유효성을 검사 한 다음 암호를 사용하여 외부 응용 프로그램에 대한 암호를 해독 할 수 있습니다.
사용자가 암호를 입력하지 않으면 할 수있는 일이 더 제한됩니다. 사용자의 암호화 된 암호를 그룹이나 공개 액세스가없는 홈 디렉토리 아래의 하위 디렉토리와 같은 제한된 위치의 파일에 저장하는 데 사용할 수있는 정보에서 키를 어떻게 든 결정할 수 있어야합니다. 당신은 사용자 이름과 고정 키를 결합하는 경우에도, 말, 기회는 누군가가 그 키가 무엇인지 운동 (및 암호화 기술)과 리버스 엔지니어링 할 수 있기 때문에
mkdir ~/.appname
chmod 700 ~/.appname
cp /dev/null ~/.appname/app.key
...store the encrypted information...
chmod 500 ~/.appname
chmod 400 ~/.appname/app.key
이 덜 만족입니다. (암호화 된 데이터의 비밀은 키에 따라 다르며, 프로그램에서 키를 결정할 수있는 경우 결정된 공격자가 결정할 수도 있습니다. 사용자가 키를 제공하는 것이 가장 좋습니다 (또는 암호 또는 아니, 무엇 MySQL의 또는 SQLite는 대한 다음 응용 프로그램은 공격자가 오프라인으로 사용할 수 있습니다 아무것도 저장하지 않습니다
어떤 응용 프로그램입니까? 많은 방법이 있지만 ASP.Net의 경우 web.config 파일에서 암호화하는 것이 일반적입니다.
크로스 플랫폼 C++ 응용 프로그램 (일부 웹 애플릿이 아님) –
일반적으로 사용자 이름과 해시 된 암호 버전을 저장합니다. 이 위키 피 디아 문서를 참조하십시오 : hash functions 및이 question.
나중에 원격 시스템에 로그인 할 때 실제 암호를 사용해야하는 경우 암호 해시가 도움이되지 않습니다. –
절대적으로 ..... – Peter
을 암호를 해시하고 지속적인 데이터베이스에 저장 일반적인
을;?. 실행시) 문구를 통과? 나중에 사용하기 위해 비밀번호를 저장하는 방법은 일부 암호화 된 캐시에 저장하는 것입니다. 캐시는 일부 마스터 비밀번호를 사용하여 암호화됩니다. 캐시에서 비밀번호가 필요할 때마다 마스터 비밀번호를 입력해야합니다. KeePassX은 마스터 비밀번호를 사용하는 작은 오픈 소스 애플리케이션입니다. 개인 데이터 (사용자 이름, p asswords 등) 그것은 가벼운 인터페이스를 가지고 있으며, 크로스 플랫폼이며 GNU General Public License의 조건에 따라 출판됩니다. 샘플로 확인하고 일부분을 사용할 수 있습니다.
spotep.com에서 우리는 사용자 이름과 암호와 결합 된 사용자 이름의 해시 코드 만 저장합니다. 이것의 이점은 similair (종종 사소한) 암호가 동일한 해시 코드 (쿠키에 저장되므로 매우 안전하지 않음)가 발생하지 않는다는 것입니다.
좋은 웹 사이트지만 거기에 시리즈를 많이 놓친 카프리 카, battlestar galactica, 무정부 상태의 아들 등 ... –
흠, 아니, 우리는 몰라? –
해시 된 암호를 SQLite에 저장하는 것이 좋습니다. 그런 다음 암호를 확인해야 할 때마다 해시 한 다음 저장된 값과 비교하십시오. 이렇게하면 저장된 암호를 안전하게 유지하여 어느 누구도 (심지어 사용자조차도) 자신이 무엇인지 알 수 없게됩니다.
지속적으로 플랫폼 독립적 인 응용 프로그램 설정을 제공하는 QSettings을 시도해 볼 수 있습니다. mysql과 같은 솔루션은 수백 개의 비밀번호를 저장하지 않는 한 과도한 공격이 될 수 있습니다.
나는 그 암호를 사용하여 웹 데이터베이스에 접근하므로, 처음 입력 한 후에는 내 응용 프로그램에 저장해야합니다. 일반 텍스트 파일을 사용하면 스마트 아이디어가 확실합니까? –
그래서 영구적 인 기록은 지금까지 최고의 아이디어입니다. 응용 프로그램이 다른 암호를 가지고 있지 않으며 다른 사용자가 해당 응용 프로그램을 사용할 것이라고 측정하지 않습니다. 유일한 것은 비밀 번호 + 다른 사용자로부터 사용자 이름을 저장하는 시도하는 것입니다. –
예, 일부 영구 파일에 정보를 저장해야합니다. 응용 프로그램의 각 사용자마다 별도의 파일을 사용하십시오. 암호화 된 암호를 Base-64 인코딩으로 저장하십시오 (일반 텍스트 파일을 사용할 수 있습니다). 암호화에 사용 된 키를 사용자의 가장 신뢰할 수있는 특성 (사용자 이름과 사용자 ID 번호 및 고정 텍스트의 연결 일 가능성이 있음)으로 간주하는 암호화 해시에서 파생시켜 안전한 것으로 저장합니다. 당신이 고안 할 수있는 위치. 보안은 완벽하지 못합니다. 공격자가 알아낼 수있는 것을 고안 할 수 있습니다. –