아타나시오 엉뚱한 인사이트.

2012년 2월 21일 출시되었다.

2005년 12월 1일 2.2버전의 출시 이후 7년(6년 3개월)만에 업데이트.

Apache 2.4의 새로운 기능 - 번역

(RUN-TIME) LOADABLE MPMS

Multi MPMs는 이제 컴파일 타임에 Loadable 모듈로 빌트 인 될수 있습니다. Multi-Processing Modules (MPMs) 네트워크 포트를 바인딩(Binding)하고 클라이언트로부터 요청을 받고 자식 혹은 쓰레드에 핸들링(Handling) 요청을 보냅니다.

Apache 2.2까지는 이것을 정적 컴파일(static compile) 해야만 했습니다. 이는 Apache 를 컴파일 설치할때에 결정되어지는 것으로 이를 사용하지 않거나 사용하기 위해서는 컴파일 시에 결정을 해야 했습니다.

하지만 Apache 2.4 에서는 이를 실행 타임(Run-time)에서 결정할 수 있도록 ‘Loadable Module’ 로 기능을 제공합니다. 컴파일 설치시에 하게되는 Configuration 에서 ‘–enable-mpms-shared’ 를 사용하면 됩니다.

EVENT MPM

Nginx 는 ‘Event Driven’ 방식의 웹 서버로 유명합니다. 하지만 Apache 는 그동안에 ‘Event Driven’ 방식을 지원하지 않았습니다.

대신 한개의 동접 클라이언트당 한개의 쓰레드 (혹은 프로세스) 구조였고 이 때문에 한 클라이언트가 맺은 접속이 완전히 끝나지 않는한 쓰레드 혹은 프로세스가 죽지않는 방법을 사용했습니다. 이는 ‘Keep Alive’ 설정으로 존재합니다. 하지만 이 ‘Keep Alive’ 때문에 대량접속에서는 효율이 급격하게 떨어지는 문제점도 안고 있었습니다.

‘Event MPM’은 이러한 문제를 해결할 수 있습니다. ‘Event MPM’을 사용하기 위해서는 Kqueue 나 Epoll 과 호환되는 시스템이 필요합니다.

ASYNCHRONOUS SUPPORT

비동기 읽고/쓰기에 대한 기능을 지원합니다. (따로 설정하거나 하는건 없고 내부 구조적으로 저런걸 지원한다는 모양입니다.)

NAMEVIRTUALHOST DEPRECATED

Apache 2.4 에서는 NameVirtualHost 가 앞으로 사용되지 않는 옵션으로 변경되었습니다. 가까운 미래에 이 옵션을 사라질 것입니다.

CONFIG FILE VARIABLES

Apache 2.4 에서는 설정 파일 내에서 변수를 사용할 수 있게 되었습니다.

PER-MODULE AND PER-DIRECTORY LOGLEVEL CONFIGURATION

모듈에 대한 LogLevel 과 각 디렉토리별 LogLevel 를 지정할 수 있게 되었습니다.

ACCESS CONTROL

Apache 의 접근 제어는 아이피 기반, 호스트 기반, 클라이언트 요청에 대한 특이한 것들에 대해서 ‘Order’, ‘Allow’, ‘Deny’, ‘Satisfy’ 를 이용해서 했었습니다. 하지만 Apache 2.4 로 넘어오면서 인증관련 메커니즘이 조금 바뀌면서 이를 수행하는 모듈, ‘mod_authz_host’가 새롭게 만들어졌습니다.

출처 : linux.systemv.pe.kr/apache-2-4-new-features/

질문: Nginx vs Apache 2.4 장단점, 성능

1. 커뮤니케이션
   • 글쓰기연습

글쓰기 연습

  주제를 정하고 내 생각을 글로 적고 글을 적으면, 읽은 사람들이 피드백 코멘트를 달아준다.

말하기 연습

  10명 정도 모인 자리에서 청자(화자에게 질문은 던지고 듣는 사람)와 화자(청자가 한 질문에 대한 답을 하는 사람)를 구분한다.

화자는 한명 또는 여러명의 청자를 정할 수 있다.

5분 정도의 대화가 끝나면 청자들과 그 외 팀원들은 화자에 대한 피드백을 할 수 있다.

발성 연습

  준비한 글을 읽으며 발음과 목소리 톤 크기등의 발성연습을 한다. 역시 끝나고 난 후 다른 팀원들의 피드백을 듣는다.

로그인할때 패스워드를 평문(PlainText)으로 서버에 보낼시 보안상 문제가 되지 않을까? 라는 질문에서 부터 시작되었다.

POST... HTTPS...를 생각하더라도 패스워드를 평문으로 다루면 안될것 같다는 막연한 상상(망상인가)... 검증도 안해보고;;

0. 기존에 구현한 로그인 순서

1. 클라이언트로 아이디와 비밀번호를 평문형태로 서버에 보낸다. 

2. 아이디를 기준으로 DB에서 패스워드(Bcrypt암호화)를 가져온다.

3. 가져온 DB패스워드를 클라이언트에서 받은 평문비밀번호와 아래와 같이 비교한다. ( PHP )

    if ( password_verify("클라이언트에서 받은 패스워드", "DB에서 가져온 패스워드") ) {
        echo '패스워드 일치';
    } else {
         echo '패스워드 불일치';
    }

4. 패스워드가 일치하면 DB에서 나머지 정보를 가져온다.

1. 클라이언트에서 API 요청시 평문으로 보내고 있는 점

암호화된 패스워드를 PHP로 보내고 PHP에서 복호화한 패스워드를 앞서 말한 password_verify함수로 비교하면 해결할 수 있지 않을까?

1-1.  Bcrypt 방식으로 데이터 베이스에 저장되어 있는 유저의 패스워드 데이터

sha-256과 같은 암호화 알고리즘으로 구현할때는 서버에 저장된 해시값과 단순 비교만 하면 문제없이 구현할 수 있었다.

그러나 DB에 저장된 패스워드값이 Bcrypt로 저장되어 있기 때문에 단순 비교가 안되었다. 그래서 password_verify 함수로 비교한 것이다.

"Bcrypt는 패스워드를 해싱할 때 내부적으로 랜덤한 솔트를 생성하기 때문에 같은 문자열에 대해서 다른 인코드된 결과를 반환한다"
https://pjh3749.tistory.com/258 [JayTech의 기술 블로그]

2. 그럼 암호화와 복호화가 가능한 알고리즘은 어떤것이 있을까?

주변에 이문제에 대해 도움을 요청했고, RSA알고리즘을 사용해 보는건 어떻겠냐는 의견을 받았다.

RSA에 대해 공부한적이 없어 RSA를 구글링하기 시작했다.

그렇게 습득한 얕은 지식으로 개인키와 공개키를 생성할 수 있었다.

...

( 아직 이해가 부족해서 더 공부해야 된다 )

3. 앞으로 해야할 TODO

이제 적용하는 일이 남았다.

1. 클라이언트는 공개키를 통해 평문으로된 패스워드를 암호화한다.

2. 암호화된 패스워드를 서버(PHP)로 보낸다.

3. PHP에서 가지고 있는 개인키로 암호화된 패스워드를 복호화한다.

4. 이제 복호화된 패스워드를 password_verify 함수를 통해 검증하면 된다.

5. 검증이 완료되면 나머지 유저의 정보를 반환 한다.

4. 마무리

여기 까지가 내가 생각한 패스워드를 안전하게 전달해서 로그인하는 방법이다.

내가 생각한 방법이 문제가 되거나, 현업에서 쓰이는 보편화된 래퍼런스가 있는지 찾아봐야 겠다. 

이 포스팅을 보는 분들중 아시는분이 있다면 댓글을 달아 주시면 참 고마울 것 같다 ^^.

참고

www.crocus.co.kr/1203

https://pjh3749.tistory.com/258