아는 사람은 알겠지만,
로그인 비번을 길게 하라는 이유가,
서버에서 암호화 스트링이 유출되었을때, brute force attack으로 뚫릴 수 있으니까 길게 하라는거 아님?
물론 이건 짧게할수록 유추하거나 매칭되는거 바로 찾아서 뚫리기 쉽다는게 명백한 진실이긴 한데,
굳이 사용자가 비번을 길게할 필요는 없는거 아님?
그냥 클라이언트단에서 몇번 crypt해주고 날리면 되지 않나요?
예를들어
0. 비번 '1234'의 해시는 "0xA0B0C0D0"이라고 가정.
1. 비번 1234 입력
2. 해시 "A0B0C0D0" 나옴. 자릿수가 8자리니까 이거 자체를 나머지 연산 돌려서 4~7의 숫자가 나오게 만든후 그 숫자만큼 앞에서부터 자름. 4라고 치면, "A0B0" 나옴.
3. A0B0를 salt키로 삼아서 crypt 연산 수행.
4. 결과가 A0B0$xyZabcdabcdabcdabcd=가 나온다고 치면, 이걸 또 2번과 같은 방식으로 "xyZabcdabcdabcdabcd="를 적당히 자르거나 아니면, 걍 통째로 전송.
이러면 salt키도 모르는 해시의 긴 비번이 완성되는건데,
굳이 사용자가 길게할 필요가 있나요?
키로거 문제는 애초에 사용자 지가 잘못해서 걸린거라, 서버단에서 뭔 지랄을 해도 막을수 없는 문제고,
(그거 때문에 키보드 보안 액티브X 깔아주면 액티브X 깐다고 또 지랄. ㅠㅠ)
비번이 길건 짧건 애초에 답이 없는 문제니까 패스.
패킷 탈취공격은 비번의 길이가 문제가 아니라,
위에서 4번까지 한 이후 전송상의 보안에서 책임질 문제고. https를 쓰건, 다른 추가 암호화 전송을 쓰건...
(솔직히 https 딸랑 믿고 비번을 평문으로 전송하는 곳이 태반인데, 졸라 극혐 ㄷㄷㄷ 심지어 http 면서도 평문 전송하는 곳은 진짜 노답. ㄷㄷㄷ)
암호학에 대해 조예가 깊으신 분의 조언을 구합니다.
위와같이 하면, 사용자가 입력하는 비번이 딸랑 4자리라도 충분하지 않나요?
다른 헛점은 뭐가 있을까요?
client 단에서crypt하게 되면 어차피 그 로직 자체가 공개된 것이나 다름 없고brute force로 쉽게 뚫리잖아요. 서버 단에서 nonce를 만들어서 클라이언트로 전달한담에 냠냠 섞어서 보내는 방법도 괜찮을 것 같긴 한데
1234// 그건 4번 직후에 털렸다고 가정할때 얘기죠. 애초에 그 시점에서 털릴 수준이면 그냥 비번을 평문 전송하는 것과 기본적으로 보안 위험이 다를게 없음. 거의 키로거나 패킷 스니퍼링에서 털린거라 문제가 다를게 없음. 요지는 '긴 비번'을 쉽게 만드는거지, 그 로직이 공개되건 말건 위험도는 달라질게 없다는거임. crypt를 한다니까 약간 오해가 있는거 같은데, 사실상 평문의 긴 비번을 간단하게 만든다고 보면 됨.
nonce 문제는 전송상의 문제인듯하고, 이걸 비번만들때 섞으면 사실상 salt키랑 다를게 없지 않음? 그래서 서버에 반드시 영구저장해야만 하고, 그렇게되면 오히려 salt키를 공개하는 효과가 될거 같음. 어떤가요?
클라이언트에서 해싱을 해버리면 어태커가 그 해싱 알고리즘을 알아버릴텐데 그게 뭔소용
서버단의 encrypted password털렸을 경우라기보다는 처음부터 클라이언트 단에서 brute force로 attack들어오는 경우 때문아닐까요? 서버에서 간단한 salt처리만 하더라도 유출 시 바로 역변환이 되는 병맛 상황은 방지가 되잖아요.
근데 가만생각해보니, 결국 답이 아닌거 같긴함. 상용 brute force 툴은 단지 서버 암호화 스트링에 대해서만 처리하겠지만, 직접 brute force 프로그램을 만든다면, 결국 클라이언트의 공개된 저 방식을 앞서서 추가시키면 끝나네요. ㅠㅠ 초딩해커는 막을수 있겠지만, 해킹툴 제작하는 수준의 해커는 답이 없겠네요. ㅠㅠ
보안편의주의. 개발편의주의. ㅇㅇ
물론 그래도 사용자가 비번을 1234 이따구로 쓰는건 보안개념이 없는거긴하다.. ㅇㅇ
ㅇㅇㅇ / 네... 그러니까 클라이언트(인 척 하고) 암호를 보내게 되면 문제가 생기는거죠. abcd 로 만들면 어떤 좋은 암호화 알고리즘을 쓰더라도 그 abcd라는 암호자체가 병맛이니까 금방 뚫릴 거에요. 1) 서버에서 brute force를 막는 attempts 제한이 필요하고... 2) 앞서 말한 nonce같은거를 전송하는 방법은 별로 효과가 없겠네요...
쁘잉쁘잉// 해싱 알고리즘은 애초에 공개된거 아닌가요? 보통 암호스트링 저장할때 해싱알고리즘 규격까지 붙여서 저장하고, 그걸 통해 brute force 하는 걸텐데.. 변형알고리즘 쓴다면 그것만 유출안되면 클라이언트에서 뭘하든지 상관없을거 같고...
1234// 클라이언트단에서는 사실상 ddos밖에 할게 없지 않을까요? 클라이언트단에서 brute force 하는건 님이 말했다시피 횟수제한만 하면 될거같고...
그런데 그 횟수 제한도 안 되어 있는 곳이... 허다하죠 x(
중딩3// 이건 잘만되면 오히려 유저가 편한건데요. ㅠㅠ 게다가 저건 없으면 그냥 기존과 다를게 없어요.
1234// 맞음. 조금만 손보면 횟수제한 거는데, 왜 안하는지. ㅋㅋ
해쉬를 잘라쓴다는거부터 이미 검증된 방식이 아님.
전체 논지에 나는 동의한다. 왜 즤들의 떨어지는 보안 능력을 사용자탓으로돌리나 귀찮기만하다 나도..숫자넣어라느니 특문넣어라느니.. 어휴
중딩3// 그게 다 brute force 때문이고, 사람일이기에 분명 어쩌다 털릴수는 있으니까 안할수도 없음. 그래서 좀 쉽고 보안강화되는 방식을 고민했건만, 초딩만 막을뿐, 역시 진짜 고수는 막을 방법이 아님. ㅠㅠ 요새 초등학생 해커니 뭐니 하는게 죄다 그냥 상용 해킹툴 돌리는 놈들인데, 딱 걔들까지만 막을거 같음. ㅠㅠ 아니면 걔들도 못 막나?
클라이언트단에서 암호화하는건 연산 시간을 늘리는 거고 brute force 관점에서는 연산 시간이 선형적으로 증가할 뿐임 (key를 따로 클라이언트에 저장하지 않는 이상) 그에 비해 평문의 문자 길이는 하나 늘어날 때마다 경우의 수가 지수적으로 증가해서 탐색 공간을 폭발적으로 키우는 효과가 있음
Kerckhoffs' Principle에 대해서 검색해 보고 오도록. 알고리즘을 비밀로 한다고 해서 더 안전하다는 보장이 없고, 또 비밀이 보장된다는 것도 어디에도 없음. 프로그램 리버싱해 보면 쉽게 알 수 있음.