뭔가 long데이터형이 깔끔하지 않아.



 

 32 bit

64 bit 

char

1 byte

short int 

int 

long  int 

float 

4

double 

8

8

pointer 

4

8


1. 분류 

정수형 : char, int 류

실수형 : float(float-point), double(double float)


2. char 

8bit 를 사용하여 표현가능한 범위에 있는 경우 사용한다. 꼭 문자만을 사용해야하는게 아니다.  다만 문자를 저장하는데 

가장 적합한 크기가 1byte 이므로 이를 좀더 쉽게 사용하도록 유도하기 위함. 

문자를 인코딩하기 위한 표준 규약인 ASCII 코드를 살펴보면 알 수 있다. (0~255 까지임)


3. short int

short int 가 원래 데이터형 이름이다. 

DOS시절 16bit운영체제이기때문에 int 라고 선언하면 short int 인 2byte 크기의 데이터형으로 인식되어, short 는 생략가능했음. 

하지만 현재 32bit운영체제에서는 short 를 생략할 수 없음. 


short라는 용어는 short int 라는 데이터형에서만 사용하기 때문에 편하게 int를 생략하고 short 라고 말해도 됨.  따라서 

short int        =    short

 타입

바이트수

최소/최대 값 

limits.h 상수 

접미사 

 비고

 (signed) short (int)

unsigned short (int)

 2

 -32768 - 32767

0 - 65535

 SHRT_MIN, SHRT_MAX

USHRT_MAX

 

 



4. int

 타입

바이트수

최소/최대 값 

limits.h 상수 

접미사 

 비고

 (signed) int

unsigned (int)

4

-2147483648 - 2147483647
0 - 4294967295

INT_MIN, INT_MAX

UINT_MAX

 

U

 

   


5. long int 

short 와는 달리 long는 32비트 이고 현재 32bit 운영체제 에서는 long 는 생략가능하다.  따라서 아래와같이  쓸수있다.

long int    =    int 


또한 long 이라는 키워드도 int 앞에만 붙여서 사용하기 때문에 long 나오면 int도 나올수밖에 없다. 따라서 int 를 생략 가능하다.  결과적으로 아래와같이쓸수있다.

long int     =     int    =    long

 타입

바이트수

최소/최대 값 

limits.h 상수 

접미사 

 비고

(signed) long (int)
unsigned long (int)

 4

-2147483648 - 2147483647
0 - 4294967295

LONG_MIN, LONG_MAX
ULONG_MAX

L

UL

 



 타입

바이

트수

최소/최대 값 

limits.h 상수 

접미사 

 비고

(signed) long long (int)
unsigned long long (int)

8

-9223372036854775808 - 9223372036854775807
0 - 18446744073709551615

LONG_LONG_MIN, LONG_LONG_MAX
ULONG_LONG_MAX

LL

ULL 

 



6. float 

4바이트 실수형. IEEE 754 규약에 따라 부호개념이 무조건 존재함. 그래서 signed나 unsigned 키워드를 사용할 필요가 없음. 


7. double 

8바이트 실수형 . IEEE 754 규약에 따라 부호 개념이 무조건 존재함. 그래서 signed나 unsigned 키워드를 사용할 필요가 없음. 



'프로그래밍 > C , C ++' 카테고리의 다른 글

확인해야할것1  (0) 2017.03.30
Windows/TCP 예제 프로그래밍 (server/client)  (0) 2013.08.02
#pragma 사용법 2  (0) 2013.04.03
#pragma 사용법 1  (0) 2013.04.03
[c_스터디]3. 형변환, 함수  (0) 2013.03.01
AND

1980 텔레뱅킹 시작

1985 PC뱅킹시작

1995 인터넷뱅킹시작

1996.8 인터넷뱅킹 최초 사고 : 카이스트학생이 분석을 의뢰받아하던도중 발생. 금감원이 모든거래 중지시킴

대응으로 1. 암호화, 2보안카드, 3 본인인증 을 금감원에서 지시해서 만족한걸가져오라함.


2005.9 전자금융정보 보안 종합대책 + 2007년 까지 금보연 설립 및 OTP센터 구축


ps.OTP는 은행별 사용건수/발행건수 에따라 비용을 지불하게되어있음. 

'금융보안' 카테고리의 다른 글

CISO 관련 글  (0) 2014.08.25
iso/iec13888-3  (0) 2013.05.31
mitb2  (0) 2013.05.10
MITB에 관하여  (0) 2013.05.03
표준 SSL server identification  (0) 2013.04.29
AND

보안공학 스터디 - 4장 Identification and Authentication

 

 교재 : computer security 4rd edition (저자 : Dieter Gollmann)

 

Intro

안전한 시스템 구축을 위하여, 우리는 사용자에게 서비스를 제공 시 사용자의 Identities(신원)를 추적할 필요가 있다.

authentication(인증)은 사용자의 신원을 verifying(증명)하는 프로세스이다.

사용자의 신원파악을 위한 두가지 이유가 있다.

 

(1) 사용자의 신원은 접근 통제 결정의 parameter(조건)이 된다.

(2) 사용자의 신원은 audit trail(감사 단서) security relevant(보안과 관계 있는) 이벤트를 로그로 남길 때 기록된다.

 

20장에서 이것이 사용자 신원확인을 위한 기본적인 접근 통제를 위하여 항상 필요하거나 요구되지 않는다는 이유를 설명할 것이다.

감사 로그를 가지고 신원확인에 이용하는 많은 좋은 사례가 있다.

본 챕터는 현재 운영 시스템에서 기준처럼 사용되는 사용자의 identification(신분 확인) 과 인증을 다루고 있다.

 

1. Username and Password

 

(글자 뜻 그대로)Literally, 너는 컴퓨터에 username과 password를 넣고 로그인 할 때 컴퓨터 보안을 접하게 된다.

신분확인 으로 불리는 첫번째 스텝은 : 너가 누구 인지 announce(알리는) 것이다.

인증 으로 불리는 두번째 스텝은 : 너가 누구라고 주장하는 것을 증명하는 것이다.

다른 interpretations(해석)으로부터 authentication(인증)이라는 단어의 사용을 구별하기 위해서, 우리는 특별히 refer(참조하다).

 

 * Entity authentication : claimed by system entity (몇몇 시스템 개체가 주장하는) identity(신원)을 증명하는 프로세스

 

네가 사용자 이름과 패스워드를 기입하였을 때, 컴퓨터는 너의 입력값과 패스워드 파일에 저장되어 있는 entries(입력값)을 비교한다.

만약 네가 유효한 사용자 이름과 corresponding(일치하는) 패스워드를 입력한다면 로그인은 성공할 것이다.

만약 사용자 이름과 패스워드가 정확하지 않다면, 로그인은 실패할 것이다.

일반적으로, 로그인 화면은 또다시 보여질 것이다. 또한 너는 다음 시도를 시작할 수 있다.

몇몇 시스템은 실패한 로그인 시도를 카운트 한다. 또한 어떤 threshold(기준점)에 다다랐을 떄, 추가적인 시도를 연기하거나 혹은 제한한다.

또 다른 사용자가 로그인 했을 때, unattended(수반하지 않는) 머신을 사용한 공격자의 기회를 줄이기 위하여 인증은 세션의 시작 뿐만 아니라 세션 사이의 간격까지 요구할 수도 있다. (반복적인 신원파악)

만약 기계가 너무 오래 idle(한가하다)면,  너는 또한 화면을 잠그거나 자동적으로 세션을 잠그기 위하여 선택할 것이다.

 

lesson(교훈)

반복적인 신원파악은 컴퓨터 보안에서 유사한 문제를 addresses(말한다) TOCTTOU (사용시간을 체크하기 위한 시간)이라고 불리우는

운영 시스템은 세션의 시작에 사용자의 신원을 체크한다. 그러나 세션동안 접근 통제 결정을 위한 신원의 사용은 체크하지 않는다.

 

once upon a time (옛날 옛적에) 네가 출입이 권한이 있는 시스템의 정보와 반가운 메시지가 포함된 화면에 사용자 이름과 패스워드를 기입했었다. 

오늘날, cautious(주의를 기울이는) 시스템 매니저는 외부에서 이용 가능하거나 또한 인가되지 않은 사람의 위험한 말에 의해서 반가운 메시지로 바뀔 수 있는 너무 많은 정보를 만들지 않을 것이다.

 

예를 들면, 윈도우는 법적 공지 다이얼로그 박스를 표시하는 옵션을 가지고 있다. 

사용자는 로그인 되기 전에 이러한 위험한 메시지를  have to acknowledge(승인)해야만 한다.

 

오늘날, 대부분 컴퓨터 시스템은 신원확인과 인증을 사용한다. 그들의 제 1 방어선과 같은 사용자 이름과 패스워드 through(에 의하여)

대부분 사용자는 이러한 매커니즘이 그들의 컴퓨터에서 세션이 시작하는 루틴의 integral(없어서는 안되는) 부분이라고 생각한다.

그래서 우리는 widely(널리) 받아들여지고 구현하기가 너무 어렵지 않은 매커니즘을 가진다.

반면에, 패스워드 보안을 관리하는 것은 꽤 비쌀 수 있다. 또한 유효한 패스워드를 얻는 것은 컴퓨터 시스템으로 인증되지 않은 접근(권한)을 gaining(얻는 것)의 일반적인 방법이다.

그러므로 패스워드에 의한 인증의 실제적 보안(상태)을 시험해 보자.

먼저, 패스워드는 사용자 account(계좌)를 위한 요소가 되야만 한다.

otherwise(그렇지 않으면), 공격자는 unchecked(검사되지 않은) 것을 입력할 수 있다.

 

공격자는

 - 새로운 사용자가 계좌를 만들 때, 패스워드를 가로챌 수 있다.

 - 패스워드를 추측하기 위해 시도한다.

 - 피싱이나 스푸핑, 키로거를 통해서 유저로부터 패스워드를 얻는다.

 - 사회공학이나 패스워드 파일을 compromising(더럽히는) 방법을 통해서 시스템으로부터 패스워드를 얻는다.

  

방어를 when looking for(예상했을 때), 패스워드 보호를 위한 사용자 역할을 잊지 마라.

 

2. Bootstrapping password protection

 

패스워드는 유저와 시스템에 의해 인증된 사용자 사이에 비밀이 공유된 다는 것을 의미한다.

그래서, 패스워드가 옳은 장소에서 ends up(끝나)기 위하여 어떻게 시스템은 bootstrap(스스로) 할 수 있을까?

enterprise(기업에서), 사용자는 개인적으로 패스워드를 모으고, 회사에 출근하도록 요구 받는다.

만약 이것이 feasible(실현 가능한) 것이 아니라면, 패스워드는 메일, 이메일, 전화, 웹페이지에 사용자의 입력에 의해 conveyed(운반될 수 있다)

너는 누가 메시지를 가로채거나 실제로 pick up(더할지도 모른다는 것을 아주 중요하게 고려해야만 한다 

예를 들면, 또 다른 사용자의 패스워드를 위한 물음에 대답했을 지 모르는 impersonator(분장가)에 의해 훔쳐질지도 모른다.

사용자가 아직 패스워드를 갖지 않았다면, 너는 어떻게 원거리의 사용자를 인증할 수 있는가?

 

이러한 이슈를 해결하기 위하여 : 

 

 - 너의 파일로부터 인증된 전화번호에서 전화가 오는 것 말고, caller(전화 거는 사람)에게 패스워드를 주지 않는다.

 - 누군가에게 다시 전화를 되건다. (예를 들면, 전화 매니저 또는 지역 보안 관리자)

 - 사용자가  새로운 패스워드로 즉시 바꿀 수 있도록 하기 위해서 단 한번만 로그인이 가능한 요청이 포함된 패스워드를 보낸다. (첫번째 패스워드의 훔침은 가치를 제한한다.)

 - 개인적 배달을 하는 courier(운반인)에 의해 메일을 보내라.

 - 사용자의 계좌를 activate(가동시키기) 위하여 다른 채널의 확인을 요청하라. (예를 들면, 웹페이지에서 패스워드를 입력하면, SMS에 의한 확인이 전송된다.)

 

새로운 사용자의 계좌가 생성되었을 때, 너는 너의 패스워드를 받기까지 약간 연기가 되는 것을 감내해야 할지 모른다.

너가 중요한 임무의 중심에 있거나, 너가 패스워드를 잊어버렸는데 패스워드를 바로 파악해야 할 때, 너는 즉시 remedy(구제)가 필요하다.

패스워드를 재설정하기 위한 절차는 꽤 위에 언급한 것들과 같이 꽤 여러가지가 있다.

그러나 지금 조직은 들어오는 요청에 대해 매시간 응대가 가능한 직원을 가지고 있다.

hot desk와 같은 세계적인 조직은 round the clock(24시간 계속) 이용이 가능해야만 한다.

personnel at the hot desk(핫 데스크의 직원들)에게는 적절한 보안 교육이 이뤄진다.

그래서, 패스워드 지원은 non-negligible cost factor(사소하지 않은 비용적인 요소)가 될 수 있었다.

 

lesson

보안 매커니즘은 legitimate(합법적인) 사용자의 접근을 실패시킬 수도 있다. 너의 overall(종합적인) 보안 솔루션은 이러한 상황을 효과적으로 핸들링할 수 있어야만 한다.

 

3. Guessing password

패스워드 선택은 중요한 보안 이슈이다.

너가 공격자의 유효한 패스워드 추측의 위험을 평가하지 못할 때, 너는 이러한 사고의 probability(가능성)을 낮게 책정할 것이다.

공격자는 두가지 기본적인 추측 전략에 따를 것이다.

 

 - Exhaustive search(철저한 검색) (brute force) : 어떤 길이를 넘는 유효한 심벌의 가능한 조합을 모두 시도한다. 

 

 - intelligent search(현명한 검색) : 제한적인 이름의 공백을 통하여 검색. 예를 들면 somehow(어쨌든) 이름, 친구이름, 관계된 이름, 차 브랜드, 차 등록번호, 폰번호,와 같은 사용자가 associated(연관된) 비밀번호를 시도한다.

 또한, 일반적으로 인기있는 패스워드를 시도한다. 

 

두번째 접근방법의 형식적인 예제는 사전으로 부터 모든 패스워드를 시도하는 dictionary attack(사전 공격) 이 있다.

 

그럼, 너희 방어 방법에는 뭐가 있나?

 

 - Change default password : 시스템이 배달 되었을 때, 그것들은 종종 'system' 'manager'와 같은 디폴트 비밀번호를 설정한 채 온다.

 이것은 현장의 기술자들의 시스템에 인스톨할 때 도움을 준다. 그러나 만약 패스워드가 바뀌지 않는다면 공격자는 시스템에 접근하기가 쉬워진다.

 particular(특별한) 예로는, 공격자는 privileged account(특정한 계좌)에 접근할 수조차 있다.

 

 - Password length : 철저한 검색을 to thwart(훼방놓기 위해) 최소의 패스워드 길이는 prescribed(규정되었다).

그러나, 유닉스 시스템 기준은 오직 8자리의 최대 패스워드 길이가 지정되어 있다. 

 

 - Password format : 너의 패스워드에 numerical(수)와 영어 같지 않은 심볼을 포함하고, 상위나 하위의 케이스 심볼을 섞는다.

 패스워드 공간의 크기는 적어도 |A|의 n 제곱이다 (n은 가장 작은 패스워드 길이이다.)

|A|는 패스워드를 constructing(구성하기) 위해 사용되는 글자의 길이이다. 

 

 - Avoid obvious passwords : 공격자는 인기있는 패스워드의 리스트를 equipped(갖췄거나) substantially(대체로)  사전공격이 obvious(명백하게) 확장된 범위를 가지고 있다는 것을 인식하고 있다.는 것을 알고 놀래지 마라.

오늘날, 거의 모든 언어를 위한 온라인 사전을 찾을 수 있다. 

 

시스템에서 패스워드 보안을 높이기 위한 추가적인 방법이 어떤 것이 있을까?

 

 - Password checkers : 시스템 관리자로써 너는 어떤 패스워드가 약한 패스워드 사전에 포함되어 있거나, 이러한 패스워드를 선택하려는 사용자의 선택을 막기 위하여 이러한 패스워드를 체크하는 도구를 사용할 수 있다.

이것은  사전공격을 imitates(모방하다) 또한 pre-empts(먼저 점유하다)

 

 - Password generation : 몇몇 운영 시스템은 패스워드를 랜덤으로 발생시키는 generator(발생기)를 포함한다.

 pronounceable(발음할 수 있는) 패스워드 이다.

 사용자는 그들의 패스워드를 수집하게 허락하지 않는다 그러나 시스템에서 제공하는 패스워드를 적용해야만 한다. 

 

 - Password ageing : 

일정한 간격에 패스워드를 바꾸도록 강제하기 위하여 패스워드의 expiry(만료) 기한이 설정되어 있다.

그것들은 previous(이전의) 패스워드 선택으로부터 사용자를 막기 위한  추가적인 매커니즘이다.

예를 들면, 최근에 사용된 열개의 패스워드 리스트.

still(여전히), determined(결심한) 사용자는 바뀐 효율적인 숫자의 조합으로 그들이 가장 좋아하는 패스워드로 revert(돌아갈) 수 있을 것이다.

그들의 오래된 패스워드가 다시 받아들여질 때까지 

 

 - Limit login attempts : 시스템은 성공하지 않은 로그인 시도를 모니터링 한다. 또한 사용자의 계좌를 완전히 잠금으로써 대응하거나 적어도 어떤 기간 동안 추가적인 시도를 하지 못하게 막거나 discourage(제한한다).

 계좌가 잠기는 시간은 실패한 시도가 숫자가 많아질 수록 증가한다. 

--------------------------------------------------------------------------------------------------------- 2013.09.17

 

 

 

4. Phishing, Spoofing, and Social Engineering

 

 

--------------------------------------------------------------------------------------------------------------

 

5. Protecting the password file

 

6. Single sign-on

 

7. Alternative approaches


'보안공학' 카테고리의 다른 글

3. Foundations of Computer Security  (0) 2013.09.26
2. Managing Security  (0) 2013.09.26
1. History of Computer Security  (0) 2013.09.16
AND