MD5, SHA1 같은 것들은 이미 단어들로부터 이미 구해놓은 hash 값을 저장한 파일도 있습니다.
웹 서버의 경우 MD5, SHA1 같은 것으로 hash 값을 DB에 저장 후,
사용자가 패스워드 넣으면 hash 값을 DB에 있는 것과 비교하는 방법이 있는데...
brute-force 공격 같은 것들은 방화벽에서 막아줄 것이고,(이것도 무슨 distributed brute-force 공격이면 애먹겠군요. ㅎㅎㅎ)
captcha 같은 것을 채용해도 됩니다.
그런데, 문제는 웹 서버, DB 관리자가 프로그램을 돌려서 사용자의 패스워드를 알 수 있습니다.
1. 서버에서 A~Z 와 0~9까지를 랜덤하게 생성한 데이터를 클라이언트로 전송합니다.
-- 랜덤한 값에는 유저의 암호가 랜덤한 순서로 입력됩니다.
-- 물론. 모든 알파벳이 포함되므로 재전송된 암호를 비교하더라도 암호를 알수는 없습니다.
-- 암호가 DAY80 일경우 전송되는 데이터 예. BACDEF2GYH4I86J0K~~~~ [자릿수.는 0부터 시작]
2. 클라이언트는 서버로부터 전송받은 랜덤한 값의 자리를 하나씩 선택해서 서버로 전송합니다.
-- BACDEF2GYH4I86J0K~~~~
-- D A Y 8 0
-- 3/ 1/ 8/ 12/ 15
-- 실제로 전송할때는 3/ 1/ 8/ 12/ 15 이 값을 전송하게 됩니다.
3. 서버는 이 순서값을 비교해서 인증합니다.
-- 3/ 1/ 8/ 12/ 15
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
암호화를 여러번 한다고 해서..
무작위 대입법이 어려워지는 게 아니라 무작위 대입법에 대응하려면 패스워드 자체 길이를 길게 해야 하는 것 아닌가요..?
패스워드가 길어지면 좋긴좋죠
패스워드가 길어지면 좋긴좋죠
하지만 유저수도 많으면 연산 속도도 느려지고,,
저기서 말하는 단어장은
일종의 32비트짜리 쉬프트연산되어 1차 암호들의
무자기대입해서 나온 hashing되어 나오진 db라고 할수 있겠죠.
실질적으로 2차에서 md5연산되어 나온 암호화를 1차에서 멀로
암호화한지 서버 암호화 알고리즘소스 뒤지기전에 알아내긴 힘들죠..
저는 2번을 씁니다. 몇번 암호화하여 저장하던지 간에
저는 2번을 씁니다.
몇번 암호화하여 저장하던지 간에 패스워드 문자열을 애초에 공개되지 않게하는것이 중요하지 않을까요?
http://mr.hanul.co
..
Hashing 하는 방법도 있습니다.
원래 단어 -> Hash 값 추출 -> DB값과 비교
할 수 있겠죠.. 유닉스가 이런 방법 쓰지 않나요?
A rose is a rose is a rose..
MD5와 SHA1과 같은 Hash 알고리즘은 암호
MD5와 SHA1과 같은 Hash 알고리즘은 암호 알고리즘이 아닙니다.
암호화라고 할 수 없습니다.
RET ;My life :P
쉬프트 연산은 엿장수 마음대로고
쉬프트 연산은 엿장수 마음대로고,
복호화가 가능한 XOR연산이 제대로 된 암호화라고 보시는건가요?
머 그럴수도 있겠네요,,
결국은 쉬프트연산이든 , XOR이든 그걸 어떻게 수학적으로
벨벨 꼬아 놓았나의 차이일뿐,,별 의미 없잖아요 사실,,
암호화의 사전적 의미/정의부터 생각해보시기
암호화의 사전적 의미/정의부터 생각해보시기 바랍니다.
https://secure.wikimedia.org/wikipedia/en/wiki/Encryption
http://terms.naver.com/entry.nhn?docId=33674
Hash 알고리즘의 경우 원래 정보가 손실되어 복호화가 불가능하기 때문에 암호화라고 할 수 없습니다.
따라서 암호화라고 표현하시면 안됩니다.
RET ;My life :P
XOR 같은 것도 있지만... AES,
XOR 같은 것도 있지만...
AES, Blowfish, DES, Triple DES, Serpent, Twofish 이런 것들도... 있는데.
소금과 복어
1, 2, 3 모두 잘못된 방법입니다. 두 번 암호화를 하든 세 번 암호화를 하든 비밀번호가 같을 경우 DB에 저장되는 내용이 같아지기 때문에 그렇습니다. 그렇지 않으려면 난수를 써야 합니다.
http://en.wikipedia.org/wiki/Salt_%28cryptography%29
또한 MD5, SHA1은 요즘 CPU가 빨라졌고 GPU에서도 해싱을 할 수 있기 때문에 패스워드를 해싱하기에 좋은 방법이 아닙니다. 컴퓨터가 빨라짐에 따라 계산량을 계속 늘여서 해싱을 느리게 할 수 있는 해시 함수를 사용하는 것이 좋습니다.
http://en.wikipedia.org/wiki/Bcrypt
^^ 재미있는 답들이 많이 올라오네요~
^^ 재미있는 답들이 많이 올라오네요~
XOR연산을 하는데
CPU클럭에서 뽑아낸 난수10000001 ^ 사용자가입력한패스워드(123) = 결과A
CPU클럭에서 뽑아낸 난수00011011 ^ 사용자가입력한패스워드(123)
= 결과B
사용자가 입력한 패스워드는 DB에 저장하지 않고 버린다
결과만 저장한다
동일한 패스워드에 대해서 그 해당 패스워드에 대한 검증은 가능하지만
나온결과는 다르다 이말씀이군요^^
1,2,3은 패스워드 같으면 결과도 같구요~
MD5, SHA1 같은 것들은 이미 단어들로부터 이미
MD5, SHA1 같은 것들은 이미 단어들로부터 이미 구해놓은 hash 값을 저장한 파일도 있습니다.
웹 서버의 경우 MD5, SHA1 같은 것으로 hash 값을 DB에 저장 후,
사용자가 패스워드 넣으면 hash 값을 DB에 있는 것과 비교하는 방법이 있는데...
brute-force 공격 같은 것들은 방화벽에서 막아줄 것이고,(이것도 무슨 distributed brute-force 공격이면 애먹겠군요. ㅎㅎㅎ)
captcha 같은 것을 채용해도 됩니다.
그런데, 문제는 웹 서버, DB 관리자가 프로그램을 돌려서 사용자의 패스워드를 알 수 있습니다.
뭐 어차피... DB에 있는 hash 를 다른
뭐 어차피... DB에 있는 hash 를 다른 hash 로 교체하는 방법도 있으니까... 그닥 별로 와닿지는 않겠지만요.
제가 생각한 암호 인증방식.입니다
http://kldp.org/node/121708
** 알파벳과 숫자.는 항상 전송됩니다. 또는 난수 전송후 같은 랜덤값 생성도 가능합니다.
1. 서버에서 A~Z 와 0~9까지를 랜덤하게 생성한 데이터를 클라이언트로 전송합니다.
-- 랜덤한 값에는 유저의 암호가 랜덤한 순서로 입력됩니다.
-- 물론. 모든 알파벳이 포함되므로 재전송된 암호를 비교하더라도 암호를 알수는 없습니다.
-- 암호가 DAY80 일경우 전송되는 데이터 예. BACDEF2GYH4I86J0K~~~~ [자릿수.는 0부터 시작]
2. 클라이언트는 서버로부터 전송받은 랜덤한 값의 자리를 하나씩 선택해서 서버로 전송합니다.
-- BACDEF2GYH4I86J0K~~~~
-- D A Y 8 0
-- 3/ 1/ 8/ 12/ 15
-- 실제로 전송할때는 3/ 1/ 8/ 12/ 15 이 값을 전송하게 됩니다.
3. 서버는 이 순서값을 비교해서 인증합니다.
-- 3/ 1/ 8/ 12/ 15
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com
기존에 사용중인 ssl방식보다 나은점을 모르겠습니다.
기존에 사용중인 ssl방식
RSA보다 나은점을 모르겠습니다.
그닥 현실 가능성은 없어 보입니다.
아님 OTP(One Time PassWord)용도로만 쓰실건가요?