2016-12-16 2 views
0

안녕 보안 인식 명,데이터베이스 연결을 만들 때 하드 코드 된 자격 증명의 위험은 무엇입니까?

나는 최근에 정적 코드 분석 및 심각도가 높은 연구 결과 중 하나에 대한 도구를 사용하여 내 응용 프로그램 연결을 만들기위한 하드 사용자 이름과 암호입니다 스캔 한 :

dm.getConnection(databaseUrl,"server","revres"); 

왜 스캐너가 응용 프로그램의 위험 요소라고 생각합니까? 암호가 손상된 경우 쉽게 암호를 변경할 수없는 등의 단점이 있습니다. 이론적으로 누군가는 자격 증명을 배우기 위해 이진 파일을 리버스 엔지니어링 할 수 있습니다. 그러나 나는 암호화되지 않은 한 설정 파일에 자격 증명을 저장하는 이점을 보지 못합니다. 설정 파일은 쉽게 찾을 수 있고 읽을 수 있습니다. 암호를 암호화하면 암호 키로 같은 문제를 해결할 수 있습니다 ...

더 이상 볼 수없는 위험이 있습니까? 아니면 완전히 다른 접근 방식을 사용해야합니까? 대단히 감사합니다.

답변

-1

나는 소스 코드 나 컴파일 된 코드의 접근성/보안성에 달려 있다고 생각합니다. 개발자는 대개 프로덕션 서버만큼 안전하지는 않지만 일반적으로 해킹 된 코드를 자신의 개발 상자에 보관합니다. 일반적으로 테스트 사용자/pw는 dev 박스에 구성되어 있으며, 실제 "pw"는 훨씬 더 안전한 설정 파일에 저장됩니다. 예, 누군가가 서버에 해킹 당하면 쉽게 자격 증명을 얻을 수 있지만 대부분의 경우 개발자 상자에 들어가는 것보다 훨씬 어렵습니다. 그러나 나는 그것이 달려있다라고 말하는 것처럼. 한 명의 개발자 만 있고 그들이 함께 작업하는 수퍼 보안 시스템이 있고 코드에 대한 레포가 매우 안전하다면 효과적인 차이가 없습니다.

+0

그건 내가 생각했던 것 대부분이지만, 나는 확실히하고 싶었다. 이것은 내가 책임지고있는 작은 응용 프로그램이므로 위험이 너무 높지 않습니다. 물론 정적 코드 분석 도구는 dev 팀의 크기 나 다른 환경의 보안 수준 (DEV, UAT, PROD 사용)과 같은 요인을 고려할 수 없으므로 심각도 분류는 아마도 그것이 가정이라는 가정에 기반 할 것입니다 대규모 엔터프라이즈 애플리케이션 – Pepa

-1

내가하는 일은 최종 사용자에게 자격 증명을 요청한 다음 파일에 암호화하여 저장하는 것입니다. 이 방법으로, 나는 dev에 연결 세부 정보와 암호를 모른다. 키는 해시 된 바이너리이며, 그 사이에 ekstra 바이트를 파싱하여 저장합니다. 이것을 해독하고 싶은 사람은 사용 된 알고리즘, 키와 벡터의 길이, 위치, 값을 유지하는 바이트 시퀀스의 시작 - 끝 위치를 알아 내야한다. 이 모든 정보를 얻으려고 내 코드를 리버스 엔지니어링하는 천재 사용자도 침입 할 수 있습니다 (그러나 최종 사용자의 자격 증명을 직접 크랙하는 것이 더 쉽습니다).

+0

나는 downvoter에게 이유를 묻습니다. SO는 이유없이 하향 투표를 허용하면 안됩니다. 그것은 수비가없는 처형과 같고 일반적으로 이해할 수없는 사람들은 할 수 있기 때문에 그렇게합니다. –

0

코드에 포함 된 고정 암호는 모든 설치마다 동일하며 소스 코드 또는 바이너리 (설치 미디어 포함)에 대한 액세스 권한이있는 모든 사람이 액세스 할 수 있습니다.

파일에서 읽은 암호는 설치마다 다를 수 있으며 암호 파일을 읽을 수있는 사람에게만 알려져 있습니다.

일반적으로 설치 프로그램은 사이트마다 고유 한 암호를 생성하고이를 응용 프로그램에서 읽을 파일에 안전하게 기록합니다. ("안전하게", 나는 symlink 공격을 막기 위해 O_CREAT|O_EXCL을 사용하고 다른 사람이 파일을 열기 전에 파일 위치와 권한을 올바르게 선택해야 함을 의미합니다).

0

이것은 흥미로운 내용입니다. 실행중인 환경/기술을 지정하지 않았으므로 .Net 응용 프로그램에 대한 예제를 제공 할 수 있습니다. 내 추측은 자바일까요? 나는 이것이 여전히 적절하고 도움이되기를 바랍니다.

내 주요 조언이 글을 읽고 거기에서 이동하는 것입니다 : 여기

Protecting Connection information - MSDN 내가이 모두 사용하여 암호화 구성 파일 및 Windows 인증을 해결 본 적이 working with encrypted configuration files here

을 설명하는 페이지입니다.내 생각에 관련 저장 프로 시저 등 (가능한 한 적게, 예를 들어 Principle of Least Privilege) 및 폴더 액세스 등의 액세스 권한을 부여받는 사용자로 애플리케이션을 실행하는 것이 좋은 방법이라고 생각합니다.

IIS 용 풀에 대한 관련 로컬 폴더 액세스를 제공하고 SQL 등에서 사용자 액세스를 분리 할 수 ​​있기 때문에이 두 기술을 모두 사용하는 것이 좋습니다. 이것은 또한 더 나은 감사를위한 것입니다!

이것은 응용 프로그램 요구에 따라 다릅니다. 구성 파일이나 환경 사용자 계정을 통해이를 구성 할 수있게하는 주된 이유는 응용 프로그램을 프로덕션으로 게시 할 때 개발자가 프로덕션 사용자 계정 정보에 액세스 할 필요가 없으며 대신 로컬/시스템 테스트/UAT 자격 증명.

물론 GIT와 같은 사설 분산 네트워크에서 호스트하는 경우 해킹 당할 수 있고 해커가 자격 증명에 액세스 할 수있는 소스 제어 체크 인에 일반 텍스트로 저장되지 않습니다.