잘못된 비밀번호 시스템 2가지
- 데이터베이스에 그대로 저장한다 (오마이갓)
- 저장한 데이터베이스를 자체 암호화해서 사용자는 키(key)를 가지고 비밀번호를 해제 잠금하여 사용할 수 있다. -> 키를 잃어버리거나 훔치면? 위험
효과적인 비밀번호 시스템을 위한 해시함수의 동작법
- 동일한 입력값에 대해 동일한 출력값을 가진다
- 입력값이 아주 살짝만 바뀌어도 출력값은 엄청나게 바뀐다
- 반대로 입력한다고 해서 원래 값이 나오지 않는다
레인보우 테이블: 해시함수가 변경한 값을 원래 값과 연결한 표. 해시 함수가 완벽하지 않은 이유.
솔트(salt): 무작위 텍스트. 비밀번호 + 솔트로 해시 함수를 통과 시킨다. 레인보우 테이블이 가지는 위험을 상쇄할 수 있다.
프로그래밍 패러다임(programming paradigm): 프로그래머가 프로그래밍을 할 때의 관점, 방식 등을 말한다. 프로그래밍을 하는 사고의 틀.
- 프로그래밍 언어는 이런 프로그래밍 패러다임을 하나 또는 하나 이상을 지원한다. Ex: 자바-객체 지향/함수형 프로그래밍
- 프로그래밍 패러다임의 대표 종류: 절차 지향 프로그래밍(명령형), 객체 지향 프로그래밍(명령형), 함수형 프로그래밍(선언형).
  - 선언형 프로그래밍과 명령형 프로그래밍
    - 선언형: 원하는 결괏값을 선언한다. (ex.css)
    - 명령형: 원하는 결괏값에 어떻게 도달하는지 선언한다.
    - 모든 선언형 프로그래밍은 명령형 프로그래밍 위에 쓴다고 이야기 할 수도 있다.
    - 명령형 프로그래밍은 할 일을 세세하게 지시할 수 있는 대신 개발자가 실수하기 쉽고, 작성한 코드를 다른 동료가 이해하기 어렵다는 특징이 있다.
    - 선언형 프로그래밍은 결과 중심으로 코드를 작성해 실수도 적고 동료가 코드를 이해하기도 쉽다.
  - 객체 지향 프로그래밍
    - 클래스: 같은 작업을 여러번 반복해야할 때 하나의 클래스를 만들어 필요한 속성들을 모두 구성해준다. 클래스 속성은 같지만 데이터는 다르게.
    - 상속: 클래스의 중복 되는 부분을 물려주는 행위. 새로운 속성만 추가하고 같은 속성은 ‘물려받아’ 중복을 피하고 효율적으로 코드할 수 있도록 해주는 부분.
  - 함수형 프로그래밍
    - ‘버그가 발생하기 어려운 구조’라서 개발자에게 매우 유용하다.
    - 자바, 자바스크립트, 파이썬 등이 함수형 프로그램을 지원한다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

지난 번 자료구조때 알게 된 해시 함수가 또다시 등장했다! 정말 마법같은 매력을 가진 함수다… 물론 비밀번호 생성에 있어 단점도 가지고 있었지만, 해시함수가 가지는 능력이 큰 것 같다. 해시 함수는 내부가 어떻게 생겼는지 어떤식으로 짜여져있는지 좀 더 세세하게 살펴보고 싶다.
생각해보면 예전에 웹에서 ‘비밀번호 찾기’를 하면 기존에 내가 가지고 있던 비밀번호를 찾을 수 있는 경우가 있었다. 지금은 오히려 찾기보다 ‘비밀번호 재설정’이라는 옵션이 더 많지만. 그럼 예전에 비밀번호 찾기 같은 경우에는 데이터베이스 안에 그대로 비밀번호가 저장돼 있었던 걸까 ? ? 그렇다면 굉장히 보안이 굉장히 취약했겠다는 생각이든다….
비밀번호 저장에 대해서 좀 더 찾다보니 해시 함수로 생성하는 암호화된 메시지를 ‘다이제스트’라고 한다. 단방향으로 복호화(암호를 풀어내는 것)할 수 없는 방법이라고. 그래서 비밀번호 찾기보다 비밀번호 재설정이 필요한 거고 운영자들도 유저의 비밀번호를 알 수 없게 된다. 단방향 해시 함수의 대표적인 예가 ‘SHA-256’이라고 하는데 ssk-keygen할때 맨날 보던 애가 이것이였구나!!! 하는 깨달음을 얻었다. (조금만 더 궁금해하고 검색해봤으면 더 빨리 알았을텐데 이걸 이렇게 알게되네)
솔트는 바이트 단위의 랜덤 문자열이라고 한다. 솔트를 추가하여 다이제스트를 하는 것을 솔팅(salting)이라고 부른다.
비밀번호 저장법에 찾다보니, 책에서 어려운 단어를 쓰지 않고 최대한 쉽게 설명하려고 한 노력이 보이는 것 같다. (이것 역시 파인만 설명기법인가!!! ㅎㅎ 니꼴라스 덕분에 파인만을 알게 됐어요. 누가 존경하는 인물이 누구냐고 물으면 대답하기가 좀 어려웠는데 파인만을 알고 영상을 다 보면서 파인만에 대한 존경심에 빠져버렸습니다 ㅎㅎ) velog 글 중에 하나를 검색해 많이 쓰이는 단어들과 함께 한번 더 내용을 새롭게 정리해볼 수 있었다.
왜인지 알 수 없으나 명령형과 선언형을 헷갈리지 않기 위해 무수히 노력을 하고 있다. 개인적으로 명령형이라는 말이 더 ‘원하는 이걸 바로 줘!!!’라고 과정없이 직설적인 느낌이라서 선언형이랑 자꾸 헷갈리는 것 같다.😅
개인적인 생각인데 배우는 단계에서 이 명령형이 코드가 도움이 더 될 수도 있지 않을까? (물론 코드가 클린할때 ^^) 선언형 코드일때는 결과물만 보기 때문에 사용에는 어려움이 없겠지만, 배울때는 속을 들여다볼 수 있고 어떻게 작동하는지를 보는게 초반에 코드를 이해할 때 도움이 많이 될 것 같다. 그리고 나서 선언형을 쓰면 이 선언형이 뒤에서는 어떻게 작동하고 있는지 알 수 있으니까…
프로그래밍 패러다임 종류를 이해하기 위한 도식표
- 절차 지향 프로그래밍(Procedure Oriented Programming;POP)은 여기 설명되지 않아 찾아봤더니 '한줄씩 처리하는 프로그래밍'을 말한다고 한다. 이 velog에서 한 코드를 절차 지향 프로그래밍과 객체 지향 프로그래밍으로 각각 설명해 줘 이해하기 쉬웠다. (관점 지향 프로그래밍이라는 것도 있었다...!) 둘의 차이는 절차 지향은 실행 순서 중심, 객체 지향은 객체들의 속성과 종류가 중심이다. C를 절차 지향, C++을 객체 지향으로 이해하면 될 것 같다.
- 논리형 프로그래밍은 논리 문장을 이용하여 프로그램을 표현하고 계산을 수행하는 개념에 기반을 둔다고 한다.
논리형 프로그래밍을 찾다가 위키페디아에 있는 프로그래밍 패러다임을 보게됐는데 종류가 장난이 아니구나... 한국어로 된 페이지도 있는데 대부분 많이 찾는 것만 번역돼 링크가 달려있고, 그렇지 않은 것들도 많아 클릭하면 편집기로 넘어간다. 이론이니 책에서 설명된 것 보다 더 많을거라 예상은 했지만 이정도일 줄이야...🫣

번아웃 이야기가 나왔는데, 정말 공감한다. 그리고 이 균형을 찾는게 정말 쉽지 않은 것 같다. 일은 아니었지만 학교 과제 때문에 정말 힘들었다. 중간에 쉴 틈도 없이.. 그래서 결국 과정을 다 마쳤을때는 코드를 보기도 싫은 지경이 돼서 몇달간 다른 책만 주구장창 읽고 코드는 손에도 안잡혔다. 지금은 지난 이야기지만 균형이라는 게 정말 쉽지 않은 것 같다. 그리고 그 균형을 맞춘다 하더라도 조금씩 다른게 변형하는 것도 나한테는 필요한 것 같았다. 사람들마다 정해진 루틴안에서 업무와 사적인 일을 하는 것에 안정감을 가지지만, 나 같은 경우에는 주기적으로 그 루틴을 바꿔주는 것도 필요한 타입이다. 계속 반복되면 오히려 반복되는 루틴 속 일들이 지루하게 느껴지기 때문에.. 크진 않더라도 균형을 잡는 루틴을 일정 주기마다 바꿔주는게 좋다고 생각이 들었다. 그리고 프로그래밍 하는 게 엉덩이로 하는 작업인만큼 몸을 움직여주는 활동도 꼭 필요한 것 같다. 안그러면 체력 떨어지는 걸 느끼는 건 기본이고 몸이 자꾸 경고를 한다 ㅠㅠ

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

솔트는 왜 솔트라고 부르는 것일까… 왜 하필 소금인가… 라고 하면서 찾아보다가 솔트 위키페디아 에서 솔팅을 했을때와 아닐때를 비교해놓은 테이블 덕분에 더 이해가 잘 갔다. 하지만 왜 여전히 ‘솔트’인지는 못찾아서 좀 더 찾아보니 한가지가 아닌 썰이 있는 것 같다ㅎㅎ 스택오버플로우 에서 찾은 건데 스레드에 보면 1)고대에 우물이나 농지가 덜 적합하게 소금을 뿌리던 전쟁에서 (비밀번호를 쉽게 찾지 못하게?) 비롯됐다 2) 식사에 소금을 추가하는 것과 마찬가지로 비밀번호에 무언가를 추가하기 위함이다. 3) “광산에 소금을 뿌리는 것”(salting a mine)과 연관돼 처음으로 책에 등장했다. 를 이은 다양한 썰들이 있는데 어떤것도 오피셜하진 않은 것 같다. 3번은 저기서 더 설명이 없어서 이해를 잘 못하겠지만, 1번 2번으로도 충분히 비밀번호 해독을 어렵게 하기 위한 의미로 ‘소금’을 썼다는 것이 귀엽다…
읽다보니 궁금한게.. 함수형 프로그래밍이 버그가 발생하기 어려운 구조라고 했는데, 결국 함수형으로 코드를 작성하기 위해서는 선언형으로 만들어진 함수를 사용하는 것이지 않나? 빌트인 함수를 사용하는 것이 아니라면 결국 그 함수를 만드는 것도 프로그래머 개인일텐데 이런걸 생각하니 버그가 발생하기 어려운 구조라고 하는 부분이 조금 이해가 잘 되지 않는다. 여러 함수를 명령형으로 만드는 것에 비해 버그가 발생하기 어려운 구조라고 비교적으로 이야기 해 놓으신 걸까?
책 내용과 관련 없지만... 글을 쓰고 나서 글쓰기 버튼을 누르고 글이 생성되면 생성 되자마자 바로 눈표시 👁️‍🗨️에 이미 카운팅이 올라가 있다(!) 왜그런걸까?? 그때그때 다르긴 한데 어떨땐 5, 이번에는 7이었다!! 글이 생성되자마자 7명 (내가 본것도 카운팅 되는 것 같은데 그럼 6명?)이 본것인가!!

오늘 읽은 다른사람의 TIL

Jihyun.an123님의 TIL
- jihyun.an님의 틸 요약 무슨일… ㅋㅋ 틸요약을 저렇게 밈으로 해놓으니 정말 참신했습니다! 저것은 정성이 없으면 할 수 없는 틸입니다…ㅋㅋ 특히 상속을 저렇게 색상 혼합으로 표현하니 이해가 더 쉽네요. 나중에 저도 설명할 때 써먹어봐야겠습니다 ㅎㅎ 머리를 깨웠으니 코딩하러 가야겠다는 마지막 말에 코딩하러 가지 않고 집안일 하러 가기로 예정된 저에게 조금 양심을 가책까지 느끼게 하는 틸입니다…(ㅋㅋ)

2 comments

글쓰기

노마드코더 이벤트노마드 코더, 강의 1:1 상담 해드려요~️⭐️📚 노마드코더 신간 안내 📚 IT 5분 잡학사전

# interview