MySQL 사용자 이름과 비밀번호가 소집되지 않도록 어떻게 보호 할 수 있습니까?

https://stackoverflow.com/questions/442862

22-07-2019
|

문제

자바 .class 파일은 상당히 쉽게 분리 될 수 있습니다. 코드에서 로그인 데이터를 사용해야하는 경우 데이터베이스를 어떻게 보호 할 수 있습니까?

해결책

코드에 암호를 하드 코딩하지 마십시오. 이것은 최근에 제기되었습니다 상위 25 개가 가장 위험한 프로그래밍 실수:

숙련 된 리버스 엔지니어에게는 비밀 계정과 비밀번호를 소프트웨어에 하드 코딩하는 것이 매우 편리합니다. 비밀번호가 모든 소프트웨어에서 동일하면 암호가 필연적으로 알려지면 모든 고객이 취약 해집니다. 그리고 그것은 딱딱한 코드이기 때문에 고치는 것은 큰 고통입니다.

애플리케이션이 시작될 때 읽는 별도의 파일에 암호를 포함한 구성 정보를 저장해야합니다. 이것이 해석의 결과로 암호가 유출되는 것을 방지하는 유일한 방법입니다 (처음부터 이진으로 컴파일하지 마십시오).

이 일반적인 실수에 대한 자세한 내용은 CWE-259 기사. 이 기사에는보다 철저한 정의, 예제 및 문제에 대한 기타 많은 정보가 포함되어 있습니다.

Java에서 가장 쉬운 방법 중 하나는 환경 설정 클래스를 사용하는 것입니다. 모든 종류의 프로그램 설정을 저장하도록 설계되었으며 일부에는 사용자 이름과 비밀번호가 포함될 수 있습니다.

import java.util.prefs.Preferences;

public class DemoApplication {
  Preferences preferences = 
      Preferences.userNodeForPackage(DemoApplication.class);

  public void setCredentials(String username, String password) {
    preferences.put("db_username", username);
    preferences.put("db_password", password);
  }

  public String getUsername() {
    return preferences.get("db_username", null);
  }

  public String getPassword() {
    return preferences.get("db_password", null);
  }

  // your code here
}

위 코드에서는 호출 할 수 있습니다 setCredentials 메소드 사용자 이름과 비밀번호에 대한 대화 상자 AskIgn. 데이터베이스에 연결 해야하는 경우 getUsername 그리고 getPassword 저장된 값을 검색하는 방법. 로그인 자격 증명은 바이너리로 하드 코딩되지 않으므로 탈퇴에 보안 위험이 없습니다.

중요 사항: 기본 설정 파일은 단지 일반 텍스트 XML 파일입니다. 무단 사용자가 원시 파일 (Unix 권한, Windows 권한 등)을 보지 못하도록 적절한 조치를 취하십시오. Linux에서는 적어도 전화가 발생하지 않습니다. Preferences.userNodeForPackage 현재 사용자의 홈 디렉토리에서 XML 파일을 작성합니다. 어쨌든 다른 사용자는 읽을 수 없습니다. Windows에서는 상황이 다를 수 있습니다.

더 중요한 메모 : 이 답변의 의견과 다른 사람들 이이 상황에 대한 올바른 아키텍처가 무엇인지에 대한 많은 논의가있었습니다. 원래 질문은 실제로 응용 프로그램이 사용되는 맥락을 언급하지 않으므로 내가 생각할 수있는 두 가지 상황에 대해 이야기하겠습니다. 첫 번째는 프로그램을 사용하는 사람이 이미 데이터베이스 자격 증명을 알고 있고 알 수있는 권한이있는 경우입니다. 두 번째는 개발자가 프로그램을 사용하는 사람의 데이터베이스 자격 증명을 비밀로 유지하려고하는 경우입니다.

첫 번째 사례 : 사용자는 데이터베이스 로그인 자격 증명을 알 수있는 권한이 있습니다.

이 경우 위에서 언급 한 솔루션이 작동합니다. 자바 Preference 클래스는 사용자 이름과 비밀번호를 일반 텍스트로 저장하지만 기본 설정 파일은 승인 된 사용자 만 읽을 수 있습니다. 사용자는 기본 설정 XML 파일을 열고 로그인 자격 증명을 읽을 수 있지만 사용자가 자격 증명을 처음 알았 기 때문에 보안 위험이 아닙니다.

두 번째 사례 : 사용자로부터 로그인 자격 증명을 숨기려고

이것은 더 복잡한 경우입니다. 사용자는 로그인 자격 증명을 알지 못하지만 여전히 데이터베이스에 액세스해야합니다. 이 경우 응용 프로그램을 실행하는 사용자는 데이터베이스에 직접 액세스 할 수 있으므로 프로그램이 로그인 자격 증명을 미리 알아야합니다. 위에서 언급 한 솔루션은이 경우에 적합하지 않습니다. 데이터베이스 로그인 자격 증명을 환경 설정 파일에 저장할 수 있지만 사용자는 소유자가되므로 해당 파일을 읽을 수 있습니다. 사실,이 사건을 안전한 방식으로 사용하는 좋은 방법은 없습니다.

올바른 경우 : 다중 계층 아키텍처 사용

이를 수행하는 올바른 방법은 데이터베이스 서버와 클라이언트 애플리케이션간에 중간 계층을 두는 것이 개별 사용자를 인증하고 제한된 작업 세트를 수행 할 수 있도록하는 것입니다. 각 사용자는 자체 로그인 자격 증명이 있지만 데이터베이스 서버에는 적합하지 않습니다. 자격 증명은 중간 계층 (비즈니스 로직 티어)에 대한 액세스를 허용하며 사용자마다 다릅니다.

모든 사용자는 고유 한 사용자 이름과 비밀번호를 가지며 보안 위험이없는 환경 설정 파일에 로컬로 저장할 수 있습니다. 이것을 a라고합니다 3 계층 아키텍처 (계층은 데이터베이스 서버, 비즈니스 로직 서버 및 클라이언트 응용 프로그램입니다). 더 복잡하지만 실제로 이런 종류의 일을하는 가장 안전한 방법입니다.

기본 운영 순서는 다음과 같습니다.

클라이언트는 사용자의 개인 사용자 이름/비밀번호를 사용하여 비즈니스 로직 계층으로 인증합니다. 사용자 이름과 비밀번호는 사용자에게 알려져 있으며 데이터베이스 로그인 자격 증명과 관련이 없습니다.
인증이 성공하면 클라이언트는 데이터베이스의 일부 정보를 요청하는 비즈니스 로직 계층에 요청합니다. 예를 들어, 제품 목록. 클라이언트의 요청은 SQL 쿼리가 아닙니다. 다음과 같은 원격 절차 호출입니다 getInventoryList.
비즈니스 로직 계층은 데이터베이스에 연결하여 요청 된 정보를 검색합니다. 비즈니스 로직 계층은 사용자의 요청에 따라 안전한 SQL 쿼리를 형성하는 것을 담당합니다. SQL 주입 공격을 방지하기 위해 SQL 쿼리의 모든 매개 변수를 소독해야합니다.
비즈니스 로직 티어는 인벤토리 목록을 클라이언트 응용 프로그램으로 다시 보냅니다.
클라이언트는 인벤토리 목록을 사용자에게 표시합니다.

전체 프로세스에서 클라이언트 응용 프로그램은 데이터베이스에 직접 연결되지 않습니다. 비즈니스 로직 티어는 인증 된 사용자로부터 요청을 받고, 클라이언트의 인벤토리 목록에 대한 요청을 처리 한 다음 SQL 쿼리를 실행합니다.

다른 팁

애플리케이션이 읽을 파일에 비밀번호를 넣으십시오. 소스 파일에 암호를 포함하지 마십시오. 기간.

루비에는 호출 된 작은 모듈이 있습니다 DBI :: DBRC 그러한 사용을 위해. Java가 동등한 것을 가지고 있다는 것은 의심의 여지가 없습니다. 어쨌든, 글을 쓰는 것은 어렵지 않습니다.

웹 응용 프로그램을 작성하고 있습니까? 그렇다면 JNDI를 사용하여 응용 프로그램의 외부에서 구성하십시오. 개요를 사용할 수 있습니다 여기:

JNDI는 응용 프로그램이 네트워크를 통해 원격 서비스를 찾고 액세스 할 수있는 균일 한 방법을 제공합니다. 원격 서비스는 메시징 서비스 또는 응용 프로그램 별 서비스를 포함한 엔터프라이즈 서비스 일 수 있지만 물론 JDBC 응용 프로그램은 주로 데이터베이스 서비스에 관심이 있습니다. DataSource 객체가 JNDI 이름 지정 서비스에 생성되어 등록되면 응용 프로그램은 JNDI API를 사용하여 해당 데이터 소스 객체에 액세스 할 수 있으며,이를 나타내는 데이터 소스에 연결하는 데 사용할 수 있습니다.

당신이 무엇을하든, 민감한 정보는 어딘가에 일부 파일에 저장됩니다. 당신의 목표는 가능한 한 얻기가 어렵게 만드는 것입니다. 이를 달성 할 수있는 금액은 회사 지갑의 프로젝트, 요구 및 두께에 따라 다릅니다.

가장 좋은 방법은 어디서나 암호를 저장하지 않는 것입니다. 이것은 해시 함수를 사용하여 암호 해시를 생성하고 저장함으로써 달성됩니다.

hash("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
hash("hbllo") = 58756879c05c68dfac9866712fad6a93f8146f337a69afe7dd238f3364946366

해시 알고리즘은 한 가지 방법입니다. 그들은 모든 양의 데이터를 반전 할 수없는 고정 길이의 "지문"으로 바꿉니다. 또한 입력이 작은 비트조차도 변경되면 결과 해시가 완전히 다르다는 속성이 있습니다 (위의 예 참조). 비밀번호 파일 자체가 손상된 경우에도 암호를 보호하는 양식으로 비밀번호를 저장하려면 비밀번호를 보호하는 데 좋습니다. 동시에 사용자의 암호가 올바른지 확인할 수 있어야합니다.

관련없는 메모 : 인터넷의 예전에는 '내 비밀번호 잊어 버렸다'링크를 클릭하면 웹 사이트가 일반 텍스트 비밀번호를 이메일로 보냅니다. 그들은 아마도 데이터베이스에 어딘가에 저장하고 있었을 것입니다. 해커가 데이터베이스에 액세스 할 때 모든 암호에 액세스 할 수 있습니다. 많은 사용자가 여러 웹 사이트에서 동일한 비밀번호를 사용하므로 이는 큰 보안 문제였습니다. 운 좋게도 요즘 이것은 일반적인 관행이 아닙니다.

이제 질문이 온다 : 비밀번호를 저장하는 가장 좋은 방법은 무엇입니까? 나는 고려할 것이다 이 (인증 및 사용자 관리 서비스 StormPath 's) 솔루션 꽤 이상적인 이상 :

사용자가 자격 증명을 입력하면 암호 해시에 대해 검증됩니다.
비밀번호 해시는 비밀번호가 아닌 생성 및 저장됩니다
해시는 여러 번 수행됩니다
무작위로 생성 된 소금을 사용하여 해시가 생성됩니다
해시는 개인 키로 암호화됩니다
개인 키는 해시와 물리적으로 다른 장소에 저장됩니다.
개인 키는 시간 기반 방식으로 업데이트되었습니다
암호화 된 해시는 청크로 나뉩니다
이 덩어리는 물리적으로 별도의 위치에 저장됩니다

분명히 당신은 구글이나 은행이 아니므로 이것은 당신을위한 과잉 솔루션입니다. 그러나 프로젝트가 얼마나 많은 보안이 필요한지, 얼마나 많은 시간과 돈을 가지고 있습니까?

많은 응용 프로그램의 경우 권장되지는 않지만 코드에 하드 코딩 된 비밀번호를 저장하는 것이 충분한 솔루션 일 수 있습니다. 그러나 위 목록에서 몇 가지 추가 단계의 보안 단계를 쉽게 추가하면 응용 프로그램을 훨씬 더 안전하게 만들 수 있습니다.

예를 들어, 1 단계가 프로젝트에 수용 가능한 솔루션이 아니라고 가정 해 봅시다. 사용자가 매번 비밀번호를 입력하기를 원하지 않거나 사용자가 비밀번호를 알고 싶지도 않습니다. 여전히 당신은 어딘가에 민감한 정보를 가지고 있으며 이것을 보호하고 싶습니다. 간단한 응용 프로그램이 있거나 파일을 저장할 서버가 없거나 프로젝트에 너무 번거 롭습니다. 응용 프로그램은 파일을 안전하게 저장할 수없는 환경에서 실행됩니다. 이것은 최악의 경우 중 하나이지만 여전히 추가 보안 조치를 통해 훨씬 안전한 솔루션을 가질 수 있습니다. 예를 들어, 민감한 정보를 파일에 저장할 수 있으며 파일을 암호화 할 수 있습니다. 코드에 암호화 개인 키를 하드 코딩 할 수 있습니다. 코드를 난독 화 할 수 있으므로 코드가 크래킹하기가 조금 더 어려워집니다. 이 목적을 위해 많은 라이브러리가 있습니다. 이 링크. (이것은 100% 안전하지 않다는 것을 한 번 더 경고하고 싶습니다. 올바른 지식과 도구를 가진 스마트 해커가이를 해킹 할 수 있습니다. 그러나 귀하의 요구 사항과 요구에 따라 이것은 충분한 솔루션이 될 수 있습니다).

이 질문은 암호 및 기타 데이터를 암호화 된 파일에 저장하는 방법을 보여줍니다. Java 256 비트 AES 비밀번호 기반 암호화

MD5는 암호화 알고리즘이 아닌 해시 알고리즘이며, 짧은 U는 wat u 해시를 되 찾을 수 없습니다. DB 사용자 이름 및 비밀번호가 아닌 사용자 인증 정보를 저장할 때 이상적으로 사용해야합니다. DB 사용자 이름과 PWD는 암호화하고 구성 파일로 유지해야합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow