2012-07-09 3 views
5

나는 자동으로 양식을 제출하거나 웹 사이트에서 데이터를 가져 오는 것을 포함하는 많은 프로젝트를 수행합니다. 일부 사이트는 사용자 이름/비밀번호 인증을 필요로합니다. (이 사이트는 API를 가지고 있지 않기 때문에 나는 스크린 스크래핑에 의존하고있다.)암호를 일반 텍스트로 저장하지 않고 프로그래밍 방식으로 웹 사이트에 로그인 할 수 있습니까?

내가 다른 POST 데이터와 같은 소스 코드에서 사용자 이름과 암호를 저장 본 적이 튜토리얼, 예를 들어, 대부분의 :

string username = "someUserName"; 
string password = "somePassword"; 
// submit POST data... 

그러나 일반 텍스트로 비밀번호를 저장하는 것은 일반적으로 싫은 일입니다. 사용해야하는 대체 방법이 있습니까?

답변

3

암호를 저장하는 일반적인 방법은 해싱을 사용하는 것입니다. 패스워드를 해싱하기위한 대부분의 알고리즘은 파괴적이므로 되돌릴 수는 없지만 이것이 효과가 없을 것입니다.

옵션은 암호를 base64로 인코딩 할 수있는 가역 해시를 사용하는 것이지만 일반 텍스트로 저장하는 것보다 훨씬 안전합니다.

내가보기에 가장 좋은 해결책은 데이터베이스에 암호를 저장하는 것입니다. 누군가 사용자 이름과 암호를 얻는 것을 정말로 염려한다면 encryption functions을 사용하여 DB에서 암호화하거나 디스크에서 직접 암호화하는 SQLite 데이터베이스를 사용할 수 있습니다.

이렇게하면 코드와 로그인 자격 증명이 분리되어 보안 걱정없이 코드를 다른 사람과 안전하게 공유 할 수 있습니다.

+0

그래도 암호화는 아닙니다. 스크립트가 평문 암호를 얻을 수 있다면 권한을 가진 사람이 암호를 실행할 수 있습니다. – pguardiario

+0

당신은 정말로 암호화로 논쟁 할 수 없습니다. 암호화 된 경우 암호화됩니다. 내 요점은 코드에서 암호를 분리 할 수 ​​있으며 데이터베이스에 암호를 저장하여 마스터 암호를 통해서만 사용할 수 있다는 것입니다. OP가 마스터 비밀번호를 처리하는 방법은 전적으로 그에게 달려 있습니다. 예 : 시작할 때 마스터 암호를 입력하라는 메시지가 나타나면 암호에 대한 무단 액세스가 중지됩니다. 물론 "실행 권한이있는 사용자"는 할 수 있지만 암호에 대한 액세스를 의미하지는 않습니다. – jurgemaister

+0

흠, 비밀번호를 묻는 메시지는 괜찮지 만 비밀번호를 저장하는 방법이 문제입니다. "마스터 비밀번호"를 사용하면 실제로는 불필요한 복잡성이 추가되고 암호화가 적용되는 한 ... 당신은 rot13에서 얻고 자하는 보호가 무엇인지 또는 사용하고있는 가역 스킴에 따라 어떤 보호가 필요한지 알지 못합니다. 스크립트를 실행할 수 있다면 암호를 볼 수 있습니다. – pguardiario

0

매우 간단한 암호화 및 암호 해독 방법은 extended tiny encription algorithm (XTEA)입니다. 위키 피 디아에서 C++ 코드를 붙여 넣겠습니다.하지만 누군가가이 코드를 바꿀 수 있음을 명심하십시오. 바로 그것을받은 후 로그인 페이지
1. HTTPS (필요한 경우)
2. 비밀번호 암호화 :

#include <stdint.h> 

/* take 64 bits of data in v[0] and v[1] and 128 bits of key[0] - key[3] */ 

void encipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) { 
    unsigned int i; 
    uint32_t v0=v[0], v1=v[1], sum=0, delta=0x9E3779B9; 
    for (i=0; i < num_rounds; i++) { 
     v0 += (((v1 << 4)^(v1 >> 5)) + v1)^(sum + key[sum & 3]); 
     sum += delta; 
     v1 += (((v0 << 4)^(v0 >> 5)) + v0)^(sum + key[(sum>>11) & 3]); 
    } 
    v[0]=v0; v[1]=v1; 
} 

void decipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) { 
    unsigned int i; 
    uint32_t v0=v[0], v1=v[1], delta=0x9E3779B9, sum=delta*num_rounds; 
    for (i=0; i < num_rounds; i++) { 
     v1 -= (((v0 << 4)^(v0 >> 5)) + v0)^(sum + key[(sum>>11) & 3]); 
     sum -= delta; 
     v0 -= (((v1 << 4)^(v1 >> 5)) + v1)^(sum + key[sum & 3]); 
    } 
    v[0]=v0; v[1]=v1; 
} 
+0

어떤 의미입니까? 알고리즘이 쉽게 손상 될 수 있습니까? – sashoalm

+1

관심 : http://security.stackexchange.com/questions/3241/thoughts-on-tiny-encryption-algorithm-tea-anyone – Jacco

+0

감사합니다. 링크를 읽었습니다. 나는 TEA가 매우 안전하지 않다는 것을 알았지 만, XTEA가 그것을 수정했다고 생각했습니다. 나는 대답 중 하나를 읽을 때까지 XXTEA에 대해 알지 못했습니다. 어쨌든 이것은 다소 의문의 여지가 있습니다. OP는 암호를 자신의 컴퓨터에 저장하여 암호가 작동하도록해야하므로 알고리즘이 무엇이든간에 본질적으로 불안정합니다. – sashoalm

0

는 두 가지 작업을 수행해야합니다.

private static String passwordEncryption(String oldPass){ 
    String newPass = ""; 
    try { 
     MessageDigest messageDigest = MessageDigest.getInstance("MD5"); 
     messageDigest.update(oldPass.getBytes(), 0, oldPass.length()); 
     newPass = new BigInteger(1,messageDigest.digest()).toString(16); 
     if (newPass.length() < 32) { 
      newPass = "0" + newPass; 
     } 
     return newPass; 
    } catch (NoSuchAlgorithmException e) { 
     e.printStackTrace(); 
    } 
    return newPass; 

} 


그리고 사용 MD5()에 저장된 하나와 수신 된 암호를 비교하는 MySQL을 기능 : 인코더는이 같은 것입니다.

+0

MySQL 측에서'MD5()'를 사용하면 나쁜 조언이됩니다. 일반 텍스트 비밀번호는 로그 파일에 남을 수 있습니다. – Jacco

0

우리가 사용하는 패턴은 다음과 같습니다.

데이터베이스 테이블에 암호화 된 열이 있습니다. 이 열은 시스템 전체의 긴 (128 비트) 임의 암호 키 (일반적으로 구성 파일에 저장 됨)로 암호화 된 데이터를 포함합니다. 이 암호화 된 열의 데이터에는 각 타사 서비스에 사용되는 별도의 (임의의) 비밀 키가 들어 있습니다. 이 암호를 사용하여이 thirdparty 서비스와 관련된 인증 세부 정보를 암호화합니다.

이 이중 암호화가 필요한 이유는 무엇입니까?

일반 텍스트의 암호 양을 단일 시스템 암호 (시스템 전체 암호)로 줄입니다. 이 때문에 키 관리가 더 쉽습니다. 각 thirdparty 서비스에 대해 긴 임의의 비밀 키를 생성하여 각 thirdparty 서비스의 자격 증명을 선택적으로 해독하고 필요할 경우 시스템간에 전송할 수 있도록합니다.우리의 비밀 키 중 하나를 데이터베이스 외부에 저장하면 SQL 인젝션 공격 (데이터베이스 데이터 만 가져 오기)과 백업 (구성 파일은 일반 백업 데이터에 포함되지 않음)과 관련된 위험이 줄어 듭니다.

약점은 분명 시스템 전체의 암호입니다. 그것은 어딘가에있는 기억에 있어야합니다.

저는 암호 작성자가 아니며 위의 내용이 차선책이라고 확신합니다. 그러나, 그것은 일하고, 제 3 자 서비스 자격 증명을 일반 텍스트로 저장하는 것보다 관리하기 쉽고 훨씬 안전합니다.

0

할 방법이 없습니다. 스크립트에서 일반 텍스트 (또는 "되돌릴 수있는 암호화")로 사용할 수 있어야합니다.

많은 Apis (예 : Amazon Web Services 포함)는 환경 변수에 자격 증명을 설정하는 것이 좋습니다. 이는 아마도 당신이 바라는만큼 안전 할 것입니다.

.bash_profile에 넣고 perrmissions를 두 번 확인하십시오. 적어도 공개 Repo에서 github으로 끝나지 않을 것입니다.

1

나는이 문제를 해결해야하는 근근이게하는 프로젝트를 가지고 있습니다. 내 설정에는 두 개의 별도 서버가 포함됩니다. 첫 번째는 사용자 프런트 엔드 웹 앱입니다. 두 번째는 스크래핑을 처리하는 nodejs 서버입니다.

나는 openssl 키 쌍 암호화를 사용하여 암호화를 처리합니다. nodejs 머신의 키 쌍을 생성하고 프론트 엔드 웹 앱에 공개 키를 제공합니다. 사용자가 타사 자격 증명을 등록하면 해당 자격 증명이 공개 키로 암호화되어 데이터베이스에 저장됩니다.

웹 응용 프로그램은 정기적으로 사용자의 암호화 된 자격 증명을 선택하여 노드 서버로 전송합니다. 노드 서버는 개인 키를 사용하여 암호를 해독하고 제 3 자와 함께 스크래핑에 사용합니다.

빠른 검색 후 openssl 및 문자열 암호화에 관한 this 문서를 발견했습니다.

나는 이것이 매우 오래된 게시물이라는 것을 알고 있지만 잘하면이 문제에 걸리는 다음 사람을 돕는다.

+0

안녕하세요! 참으로 저것은 저를 도왔다! 하지만 아무도 자신의 개인 키에 액세스하지 못하게하려면 어떻게해야합니까? – nicolasdaudin

관련 문제