Brute Force Attack

무차별 대입 공격은 사용자가 입력할 수 있는 모든 글자에 대하여 하나하나 대입을 하면서 비밀번호를 풀어 내는 방법이다. 예전에 여자친구가 아이폰 백업 비밀번호를 잃어 버린적이 있어서 풀어주기 위해 툴을 사용한 적이 있는데 대부분의 툴들은 무차별 대입공격을 기반으로 한다. 특수문자와 영어 대소문자, 숫자로 구성된 비밀번호 9자리를 푸는데 요구되는 시간이 1030년이라고 뜬 적이 있다. 이처럼 무차별 대입공격에 강한 비밀번호가 되기 위해서는 비밀번호를 길고 복잡하게 만들어야 할 필요가 있다. 최근에는 빠른 연산이 가능한 GPU와 멀티 쓰레드처럼 병렬처리를 사용하여 시간을 단축하는 기법도 사용한다.

Dictionary Attack

비밀번호 크랙툴 중에 기본적으로 사전 공격이 있는 툴도 있는데. 공격자가 무차별 대입 공격에서 시간이 많이 걸리는 점을 우회하기 위해서 착안한 방법이다. 이 사전 공격은 공격자가 대부분의 사람들은 자연어를 이용하여 비밀번호를 만든다는 점과 사람들이 자주 사용하는 비밀번호 정보를 수집하여 사전으로 만들고 그 사전의 단어를 기반으로 대입을 하여 비밀번호를 푸는 방법을 말한다. 이 방법을 사용하면 무차별 대입공격보다 한참 적은 시도로 비밀번호를 크랙할 수 있는 장점이 있다. 

Rainbow Table Attack

비밀번호는 대부분 암호화 해시 함수를 사용한 결과 값을 데이터베이스에 저장이 된다. 해시 함수는 일방향 함수로 암호화 과정만 있고 복호화 과정이 없는 특징이 있어서 해당 값을 복호화하는 것은 불가능하다. 하지만 공격자가 해시함수에 다양한 값을 입력하여 얻은 해시 값들을 정리해놓은 테이블(Rainbow Table)이 있다면 해당 데이터 베이스에서 비밀번호를 알아 낼 수도 있다. 또한 우연하게 같은 비밀번호를 사용하는 사람들이 있다면 데이터 베이스에 저장된 해시 값이 같으므로 하나의 비밀번호를 크랙하는 동시에 여러 계정이 폭발하는 문제도 발생할 수 있다.

Exploiting multiple password use

워낙 많은 사이트와 SNS가 있다보니 같은 아이디에 같은 패스워드를 사용하는 경우가 많다. 따라서 만약 하나의 사이트의 아이디, 패스워드가 크랙이 되면 연쇄적으로 다른 사이트도 피해를 볼 수 있다. 가급적 비밀번호를 사이트 마다 다른 것을 쓰는 것을 권장하는 이유다.  

Workstation hijacking

PC방에서 컴퓨터를 켜놓고 잠깐 자리를 비운사이 아직 로그인되어 있는 사이트에 공격자가 앉아서 공격을 하는 방법. 

(좀 성격 안 좋은 형님들이 동생들이 자리 비운 사이에 아이템을 다 팔아버리거나 버려버리는...)

자리를 비우는 경우에는 화면보호기나 컴퓨터를 끄고 가는 것이 좋다.

Exploiting User Mistake

간혹 로그인할 때 아이디를 입력하는 곳에 비밀번호를 입력하여 로그인 버튼을 누르는 경우가 있는데, 로그나 암호화 되지 않은 패킷을 캡쳐하여 비밀번호를 획득할 수 있다. 

보안 카드의 번호를 전부 다 입력하라, 주민등록번호를 말해달라, 비밀번호를 말해달라 등 컴퓨터적인 기술을 이용한 것이 아니라 사회 공학적인 요소를 활용하여 상대방을 속여서 비밀번호 등을 획득하는 방법. 때로는 카페이나 도서관 등에서 대화하는 내용을 수집하여 개인정보를 획득하고 비밀번호를 얻는 방법도 있다.  

1. 필요성

사용자 식별의 필요성

회원가입 과정을 생각해보면 ID 중복 체크를 반드시하여 중복되는 ID에 대한 사용을 금지하는 과정을 쉽게 볼 수 있을 것이다. 왜냐하면 멀티 유저 시스템에서는 각각 유저들에 대한 권한이 다르게 설정되어 있기 때문에 사용자간의 식별을 위해서 중복을 피한다. 예전에는 영문과 숫자 조합의 아이디를 사용하였지만 최근에는 이메일이나 휴대전화번호도 중복이 되지 않는 점을 착안하여 아이디로 사용하기도 한다. 

사용자 인증의 필요성

이제 아이디를 정상적으로 만들어 회원가입을 한 후 해당 사이트에 로그인을 하고자 한다. 아이디를 입력하고 우리는 비밀번호를 입력한다. 비밀번호로 나 자신이 해당 계정의 주인임을 인증하는 것이다. 식별과 비슷한 이유로 사용자 간의 권한은 서로 다르기 때문에 해당 권한을 사용할 사람이 맞는지 아닌지를 입증을 할 필요가 있다. 

2. 인증 방법의 분류

Something you know

당신만이 알 수 있는 내용으로 사용자를 인증하는 방법이다. 대표적으로 Password나 Pin이 있으며, 간혹 비밀번호나 아이디를 찾고자 할 때 "당신이 가장 소중하게 여기는 것은?"이라는 질문을 하는 경우도 해당한다. 

이 방법의 장점은  주인이 분실하거나 유출이 의심될 때 쉽게 비밀번호를 변경을 할 수 있다는 점이다. 그에 반해 단점은 본인이 아닌 다른 사람이 해당 비밀번호를 알고 있다면 쉽게 접속하여 권한을 남용하여 시스템에 해를 입힐 수 있다. 따라서 비밀번호를 인증으로 사용하는 경우에는 저장할 때 암호화 해시를 사용하는 등 비밀번호의 보관에 신경을 더욱 쓸 필요가 있다.

Something you have

은행에서 공인 인증서를 발급 받으면 보안카드나 OTP를 발급 받을 수 있다. 또는 회사에 입사하면 사원증을 발급 받는데 그것을 이용하면 회사의 입구에 카드를 대어 사원을 인증하는 경우도 본 적이 있을 것이다. 

이처럼 개인이 가지고 있는 것으로 인증을 하는 방법도 있다. 이 방법은 해당 기기를 분실 / 도난 당하지 않는다면 안전하게 개인을 인증할 수 있는 장점이 있다.

Something you are

요즘 최신 스마트폰에 내장된 지문 / 홍채 인식처럼 생채정보를 활용하여 인증을 하는 방식이다. 사용자만이 가질 수 있는 것을 이용하기 때문에 해당 사용자만이 사용할 수 있는 장점이 있어 강력하지만 만약 유출이 되어진다면 변경이 불가능하다. 일반적으로 홍채의 경우가 가장 정확성이 뛰어나지만 비용적으로 아직 비싼 기술이다.

바이오 인증 과정은 우선 사용자는 자신의 신체 특징(지문, 홍채)을 입력하면 컴퓨터에서 특징점을 분석하여 데이터베이스에 저장한다. 사용자는 인증이 필요한 경우 해당 인식기에 자기의 지문, 홍채 등을 입력하면 데이터 베이스에 저장된 특징점과 입력된 특징점을 비교하여 해당사람이 맞는지 아닌지를 인증한다. 수사와 같이 특수한 경우에는 데이터 베이스에 범죄자로 추정되는 지문을 입력하여 특징점과 데이터베이스 내부의 모든 데이터와 특징점과 비교하여 해당 사람이 누구인지를 확인하는 절차를 가진다.

Something you are/not

최근에 나의 페이스북이 내가 사는 곳이 아닌 엉뚱한 곳에서 접속을 한 이력이 있다고 페이스북에서 경고메세지를 보내 주었다. IP나 Mac Address로 평소에 접속하는 곳이 아닌 엉뚱한 곳에서 접속하는 경우 당신이 맞는지 아닌지 확인을 해주는 기능이 페이스북에 있었나보다.. 이처럼 사용자의 Mac 주소나 IP 주소로도 인증이 가능하며 이 경우는 이동이 잦은 경우에는 IP주소가 달라지고 다양한 기기를 사용하면 Mac 주소의 변별력이 떨어지므로 이동을 하지 않거나 해당 디바이스가 고정된 경우에 사용하는 것이 좋다.

3. 스마트 카드

Memory 카드

Memory 카드는 데이터를 저장할 수는 있지만 연산이 불가능한 카드다. 일반적으로 카드의 자기선이나 내부의 메모리 칩에 데이터를 저장되어 있으며 카드를 사용할 때 비밀번호를 입력하는 것으로 보안을 강화한다. 우리가 은행에서 사용하는 신용카드가 이와 같은 형태를 가지고 있으며 비밀번호 4자리를 사용하는 대신 입력의 횟수를 제한하여 무차별 대입 공격을 방지한다.

스마트 토큰(OTP)

데이터의 저장 뿐만 아니라 마이크로프로세서가 내장되어 있어 연산이 가능하다. 일반적으로 키패드와 함께 있어 키패드로 비밀번호를 입력하면 내부 연산으로 One Time Password(OTP)를 생성하여 디스플레이에 보여준다. OTP는 임시적인 비밀번호로 한번 사용하게 되면 Dynamic Password Generator에 의해 새로운 일회용 비밀번호를 생성하는 방법인 Challenge-response를 사용한다. 

스마트 카드

스마트 토큰의 기능과 메모리 카드의 기능을 한 카드에 모은 것이 스마트 카드이다. 메모리가 있어서 데이터를 저장할 수 있으며 프로세서가 있어서 연산에 가능하며 입출력장치도 가지고 있다. 메모리는 카드의 유통기한동안 바뀌지 않는 데이터를 저장하는 ROM, 어플리케이션 데이터와 프로그램을 가지고 있는 EEPROM, 어플리케이션이 수행할때 임시적으로 데이터를 생성하는 RAM을 가지고 있다.

1. Buffer Management

Buffer Management의 역할

사용자가 어떤 쿼리문을 요청하면 DB에서 해당 내용을 메인 메모리의 버퍼 풀에 저장하여 사용한다. 요청한 페이지가 버퍼 풀에 없다면 한 프레임을 대체하여 사용하며 대체되는 프레임이 변경(dirty)되었다면 해당 내용을 디스크 상에도 반영을 하여 준다. 만약 순차적인 스캔 등 다음에 읽을 페이지가 예상이 가능하다면 미리 여러 개의 페이지를 메모리 상에 올려 주는 것이 효과적이다. 

Buffer Replacement Policy

LRU, MRU, Clock 등등 다양한 교체 알고리즘으로 정책을 세우되 접근 패턴을 고려하여 선택을 해야한다. 만약 버퍼 프레임보다 페이지의 수가 많다면 Sequential flooding이 발생한다. LRU를 사용하면 I/O하는 시간이 많이 소비되어 이 경우에는 MRU가 비교적 효과적인 알고리즘이 된다. 

2. InnoDB record format

Variable Length

한 필드의 타입이 int(4)라면 int형 데이터를 무조건 4개를 넣어라는 것이 아니라 4개 이하의 데이터를 넣을 수 있으며 not null 조건이 없다면 null도 허용된다. 이처럼 데이터 필드의 크기가 변화가능한(variable) InnoDB의 데이터 필드를 저장할 때 각각의 필드의 시작지점을 저장하는 Field Start offset을 함께 저장한다.

Record format

우선 가장 앞의 Field start offset은 각각의 칼럼의 시작 위치를 저장하는 곳이며 Extra Byte 구간을 기준으로 좌우 대칭된 모습으로 저장한다. 대게 1Byte를 사용하며 가장 첫 비트는 null여부를 판단하는 비트로 사용한다. 예를 들어 F3가 1000 0001이라면 해당 데이터 필드는 null이다. 따라서 표현가능한 크기는 127이하를 표기 가능하며 만약 127이상의 데이터 필드가 있다면 1 바이트를 추가적으로 사용하여 표기가능하다. 두 바이트를 사용하는 경우에는 첫 비트는 null여부, 두 번째 비트는 같은 페이지에 데이터가 있는지 여부를 표기한다. 왜나햐면 크기를 나타내는 비트의 수가 14개이므로 최대 16,383byte를 표현 가능하므로 같은 필드의 데이터가 다른 페이지 상에 존재할 가능성이 있기 때문이다.

Extra Byte는 Field start offset이 1바이트인지 2바이트인지, 다음 레코드의 포인터값 등등을 저장하는 필드이다. InnoDB에서는 6바이트를 사용하여 정보를 표기한다.

System Column에는 해당 rowID(S1), 트렌젝션ID(S2), Rollback pointer(S3)를 담고 있으며 해당 크기는 각각 6바이트,  6바이트, 7바이트이다. Rollback pointer의 경우 트렌젝션 수행 중에 만일 Rollback을 하게 되면 해당데이터가 원상 복구되어야하는데 변경 전의 데이터를 가지고 있는 필드를 가리키는 포인터로 사용한다.