카카오페이를 두둔하는 것은 아닌데..jpg
알림
|
페이지 정보
작성일
2024.08.15 15:33
본문
https://www.hankyung.com/article/2024081441215
보안쪽을 손놓고 있어서
제가 틀릴수도 있긴 한데요..
제가 알고 있는 보안기술로..
sha256은 해쉬 암호화 아닌가요?
이걸 복호화 가능하다고요????
와중에 말장난인게, "원본 데이터 유추 가능" .... 유추가 가능하다라;;;
금감원 요즘 하는짓 보면 좀 이상한데요;;;;;;
=======참 고========
SHA256 암호화 방식을 단적인 예로 아래와 같이 설명드릴수 있습니다.
같은 항목으로 입력해도 암호된 값은 똑같이 나오고
순서만 바꿔도 다른 값이 나옵니다.
따라서 salt를 쓰지 않아도 여러 값을 조합해서 암호화하면 사실상 어떤 값인지 알수가 없습니다.
개인정보를 하나의 정보만으로 암호화하는 것은 사실 개인정보도 아닐뿐더러 개인을 특정할 수 없기 때문에
카카오페이는 분명 2개이상의 정보를 조합해서 해쉬값을 만들었을껍니다.
입력 1: "홍길동,010-1234-5678,서울시 강남구"
SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
입력 2: "010-1234-5678,서울시 강남구,홍길동"
SHA-256: f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
- 게시물이 없습니다.
댓글 40
/ 1 페이지
쿠키맨님의 댓글의 댓글
@니파님에게 답글
소금안치고 정해진 루틴(이름, 주소, 전화번호)대로만 암호화했다면 추정은 할 수 있겠는데요.
문제는 어떤 정보를 암호화했는지 알려주지 않는 이상은 불가능하다고 봅니다. (설마 그걸 알려줬을리가..)
문제는 어떤 정보를 암호화했는지 알려주지 않는 이상은 불가능하다고 봅니다. (설마 그걸 알려줬을리가..)
masquerade님의 댓글
이쪽 공부 안해봤지만..
길이가 짧고....그 내용의 패턴이 단순해서 그런거 아닐까요?
길이가 짧고....그 내용의 패턴이 단순해서 그런거 아닐까요?
쿠키맨님의 댓글의 댓글
@masquerade님에게 답글
저도 지식이 짧지만 사실상 불가능하다고 생각합니다.
만약 알리가 카카오페이에서 해쉬된 암호구문이 "이름", "전화번호", "주소" 딱 이렇게 순서를 정해서 암호해서 보내준거라고 얘기했다고 하면 DB에서 구문을 찾는식으로 추정은 할 수 있습니다만..
무엇을 암호화했는지 알려주는 것 자체가 사실 그냥 정보를 알려준것과 다르지 않거든요.
만약 알리가 카카오페이에서 해쉬된 암호구문이 "이름", "전화번호", "주소" 딱 이렇게 순서를 정해서 암호해서 보내준거라고 얘기했다고 하면 DB에서 구문을 찾는식으로 추정은 할 수 있습니다만..
무엇을 암호화했는지 알려주는 것 자체가 사실 그냥 정보를 알려준것과 다르지 않거든요.
Kalhein님의 댓글
문외한이지만, 역함수 같은게 있는건 아니고, 함수에 입력되는 값을 쉽게 알 수 있어서 결과적으로 1:1 매칭되는 테이블 생성이 가능한 케이스 아닐까요?
쿠키맨님의 댓글의 댓글
@Kalhein님에게 답글
단방향 암호화 입니다.
애시당초 복호화가 불가능합니다.
그냥 데이터를 sha256으로 암호화한 값을 비교하는 식으로 bruteforce 방식으로 찾아내는 것 말고는 불가능합니다.
애시당초 복호화가 불가능합니다.
그냥 데이터를 sha256으로 암호화한 값을 비교하는 식으로 bruteforce 방식으로 찾아내는 것 말고는 불가능합니다.
몽몽이님의 댓글
설마 해시함수를 복호화가 가능하다는 말을 금감원에서 할리가요.. 기자가 잘 못 옮긴게 아닐까요.
그리고 sha256이 뚫렸나요..? 거 참.. 알 수가 없네요.
그리고 sha256이 뚫렸나요..? 거 참.. 알 수가 없네요.
DevChoi84님의 댓글
aes256이 아니라 sha256은 단방향 해시 암호화라 복호화가 안됩니다.그게 되면 kisa에서 암호화 모듈을 sha256으로 권고하는건 개뻘짓이죠.
mtrz님의 댓글
뭐.. 저는 그냥 평범한 웹개발자지만요.
길이와 포맷이 완전히 일정한 경우라면 레인보우 테이블이 불가능한 것은 아니겠죠.
이메일은 길이가 제각각이라 애매하지만 전화번호는 충분히 탐색이 가능하다고 봐야죠.
비교 대상이 되는 전문 전체를 해쉬한 경우라면 별 문제 없다고 생각이 되고
필드를 각각 해쉬했는데 그중에 전화번호도 있다 그러면 좀 많이 문제일 것 같습니다.
어느 쪽이어도 어지간하면 솔트는 넣었어야 할 텐데 이건 뭐 혼날만 하다고 보긴 해야지 싶긴 합니다.
때 마침 무슨 이유인지 카카오를 조지려고 하는 것 같은 분위기라 엥간한 것도 봐줄 리 없는 때이기도 하니.. 허허.
길이와 포맷이 완전히 일정한 경우라면 레인보우 테이블이 불가능한 것은 아니겠죠.
이메일은 길이가 제각각이라 애매하지만 전화번호는 충분히 탐색이 가능하다고 봐야죠.
비교 대상이 되는 전문 전체를 해쉬한 경우라면 별 문제 없다고 생각이 되고
필드를 각각 해쉬했는데 그중에 전화번호도 있다 그러면 좀 많이 문제일 것 같습니다.
어느 쪽이어도 어지간하면 솔트는 넣었어야 할 텐데 이건 뭐 혼날만 하다고 보긴 해야지 싶긴 합니다.
때 마침 무슨 이유인지 카카오를 조지려고 하는 것 같은 분위기라 엥간한 것도 봐줄 리 없는 때이기도 하니.. 허허.
쿠키맨님의 댓글의 댓글
@mtrz님에게 답글
만약 어떤 정보를 암호화했는지 공격자에게 알려주면 충분히 찾아낼 수 있긴 합니다. (말씀하신 레인보우 테이블로..)
근데 설마 그랬을라구요;;;;
적어도 2개 이상의 정보를 조합해서 해쉬를 만들었을텐데 말이죠. (와중에 이것도 순서에 따라 해쉬값이 달라지니..)
그리고 한개의 정보(예를 들어 전화번호)는 개인정보라고 볼 수 없죠.
근데 설마 그랬을라구요;;;;
적어도 2개 이상의 정보를 조합해서 해쉬를 만들었을텐데 말이죠. (와중에 이것도 순서에 따라 해쉬값이 달라지니..)
그리고 한개의 정보(예를 들어 전화번호)는 개인정보라고 볼 수 없죠.
DevChoi84님의 댓글의 댓글
@mtrz님에게 답글
그런식으로 접근했을때눈 우리나라에서 개인정보 다루는 곳 대부분이 저렇게 처리하고 kisa에서 하는 isms-p 통과하는 곳은 없을거같은데요?
글렌1님의 댓글
기사 내용처럼 salt 소금이 없으면 뚤리는거죠
문자 길이가 머가 됐던 시간만 있으면 다 복호화 가능인거니
문자 길이가 머가 됐던 시간만 있으면 다 복호화 가능인거니
글렌1님의 댓글의 댓글
@쿠키맨님에게 답글
salt만 쳐도 안 뚫립니다
이건 그것조차 안해서 뚫리는거고요
검색하기 쉬우라고 salt도 안한거 같은데 이건 욕 먹어야 하는겁니다.
이건 그것조차 안해서 뚫리는거고요
검색하기 쉬우라고 salt도 안한거 같은데 이건 욕 먹어야 하는겁니다.
쿠키맨님의 댓글의 댓글
@글렌1님에게 답글
개인정보를 조합해서 쓴것 자체가 salt 한것이나 다름 없다고 생각합니다.
쿠키맨님의 댓글의 댓글
@글렌1님에게 답글
본문에 첨부된 기사 내용중
금감원은 "알리페이가 애초 카카오페이에 개인신용정보(핸드폰, 이메일 등)를 요청한 이유는 해당 정보를 애플ID에 매칭하기 위한 것"
기사내용만 봤을땐
핸드폰과 이메일 정보등을 조합한 해쉬값으로 보이네요.
그리고 1개의 정보만 해쉬했다면..
그건 개인정보가 아닙니다. (진짜 복호화 해도 무의미한 정보일뿐입니다. 왜냐면 그게 누구의 정보인지 모르니깐요)
금감원은 "알리페이가 애초 카카오페이에 개인신용정보(핸드폰, 이메일 등)를 요청한 이유는 해당 정보를 애플ID에 매칭하기 위한 것"
기사내용만 봤을땐
핸드폰과 이메일 정보등을 조합한 해쉬값으로 보이네요.
그리고 1개의 정보만 해쉬했다면..
그건 개인정보가 아닙니다. (진짜 복호화 해도 무의미한 정보일뿐입니다. 왜냐면 그게 누구의 정보인지 모르니깐요)
글렌1님의 댓글의 댓글
@글렌1님에게 답글
조합은 뇌피셜 인거군요?
해시값을 머하러 개인정보를 합쳐서 합니까?
그냥 렌덤 돌리면되죠 아님 키값을 해시 하겠죠
그리고 필드가 나눠져 있다면 필드마다 복호화 해서
합치면 개인정보 입니다.
그리고 알리페이의 의도가 복호화 해서 애플에 매칭 하겠단거 아닌가요?
복호화도 안되는 스트링을 머하러 매칭합니까?
해시값을 머하러 개인정보를 합쳐서 합니까?
그냥 렌덤 돌리면되죠 아님 키값을 해시 하겠죠
그리고 필드가 나눠져 있다면 필드마다 복호화 해서
합치면 개인정보 입니다.
그리고 알리페이의 의도가 복호화 해서 애플에 매칭 하겠단거 아닌가요?
복호화도 안되는 스트링을 머하러 매칭합니까?
쿠키맨님의 댓글의 댓글
@글렌1님에게 답글
제가 뇌피셜이라면..
금감원은 거짓말이 되는 겁니다.
왜냐면 지금 이슈가 되고 있고..
금감원이 주장하는 부분이..
암호화된 데이터로 인해 분명 개인정보가 유출되었다고 했으니깐요.
금감원은 거짓말이 되는 겁니다.
왜냐면 지금 이슈가 되고 있고..
금감원이 주장하는 부분이..
암호화된 데이터로 인해 분명 개인정보가 유출되었다고 했으니깐요.
쿠키맨님의 댓글의 댓글
@글렌1님에게 답글
글렌1님.. 상식적으로 굳이 각 필드를 별도로 해쉬하지 않습니다.
글렌1님의 댓글의 댓글
@글렌1님에게 답글
이 바닥 17년 차지만 필드는 모두 각기 관리됩니다.
그리고 마지막으로 현직자의 감? 은
카카오가 정보를 주기는 해야 하는데
평문으로 주기는 너무 한거 같고
지금 처럼 걸렸을땐 변명꺼리고 없고
aes로 해서 비밀키까지 넘기는 것도 너무 의도가 보이고
샤로 해서 어물쩡 넘기는 방식을 취한게 아닌가 하는 현직자의 뇌피셜 입니다 ㅋㅋ
지금 처럼 일반인이 봤을땐 변명이 되니깐요 ㅋ
그리고 마지막으로 현직자의 감? 은
카카오가 정보를 주기는 해야 하는데
평문으로 주기는 너무 한거 같고
지금 처럼 걸렸을땐 변명꺼리고 없고
aes로 해서 비밀키까지 넘기는 것도 너무 의도가 보이고
샤로 해서 어물쩡 넘기는 방식을 취한게 아닌가 하는 현직자의 뇌피셜 입니다 ㅋㅋ
지금 처럼 일반인이 봤을땐 변명이 되니깐요 ㅋ
글렌1님의 댓글의 댓글
@쿠키맨님에게 답글
님은 뇌피셜로 조합이라 복호화가 안되니 유출아니다고
금감원은 조사를 통해 충분히 복호화가 가능하니 유출이다인데
무슨 말씀이신가요??
금감원은 조사를 통해 충분히 복호화가 가능하니 유출이다인데
무슨 말씀이신가요??
쿠키맨님의 댓글의 댓글
@글렌1님에게 답글
공문에 적혀 있습니다.
해시처리 함수에 랜덤값을 추가하지 않고 해당정보(전화번호, 이메일 등) 위주로만 단순하게 설정..
그리고 말씀하신데로 각 필드를 왜... 별도로 해쉬해서 넘겨주나요? ㅡㅡ;;;
그냥 하나로 합쳐서 넘겨주면 되는데요.
해시처리 함수에 랜덤값을 추가하지 않고 해당정보(전화번호, 이메일 등) 위주로만 단순하게 설정..
그리고 말씀하신데로 각 필드를 왜... 별도로 해쉬해서 넘겨주나요? ㅡㅡ;;;
그냥 하나로 합쳐서 넘겨주면 되는데요.
포니님의 댓글
123@gmail.com
이렇게 메일 주소가 있을 것이고 이것을 sha256을 이용하여 데이터를 암호화(아니 해쉬화?) 했다면
30a79640dfd8293d4f4965ec11821f640ca77979ca0a6b365f06372f81a3f602
그 값은 위의 값이 되는 것이죠
이걸 @apple.com 이나 @naver.com @gmail.com 등 대표 메일에 계정만 무작위대입을 한다면
해당 해쉬 값을 가지는 메일 주소를 역으로 찾을 수 있는 거구요
암튼 개인적인 생각은 저 값이 저렇게 나가는 건 개인정보활용동의가 있었다면 문제 될 것 같지 않습니다.
개인정보활용동의가 없으면 문제가 되겠죠
이렇게 메일 주소가 있을 것이고 이것을 sha256을 이용하여 데이터를 암호화(아니 해쉬화?) 했다면
30a79640dfd8293d4f4965ec11821f640ca77979ca0a6b365f06372f81a3f602
그 값은 위의 값이 되는 것이죠
이걸 @apple.com 이나 @naver.com @gmail.com 등 대표 메일에 계정만 무작위대입을 한다면
해당 해쉬 값을 가지는 메일 주소를 역으로 찾을 수 있는 거구요
암튼 개인적인 생각은 저 값이 저렇게 나가는 건 개인정보활용동의가 있었다면 문제 될 것 같지 않습니다.
개인정보활용동의가 없으면 문제가 되겠죠
쿠키맨님의 댓글의 댓글
@포니님에게 답글
입력 1: "홍길동,010-1234-5678,서울시 강남구"
SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
입력 2: "010-1234-5678,서울시 강남구,홍길동"
SHA-256: f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
순서만 바꿔도 다르게 나옵니다.
문제는 알리에서 카카오페이가 어떤 값으로 암호화했는지 친절하게 아주 상세히 설명했다면 말씀하신데로 찾을 수 있습니다.
하지만 그건 salt를 어떤 값으로 했는지 알려주는 것과 다를바 없기때문에 말이 안됩니다.
SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
입력 2: "010-1234-5678,서울시 강남구,홍길동"
SHA-256: f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
순서만 바꿔도 다르게 나옵니다.
문제는 알리에서 카카오페이가 어떤 값으로 암호화했는지 친절하게 아주 상세히 설명했다면 말씀하신데로 찾을 수 있습니다.
하지만 그건 salt를 어떤 값으로 했는지 알려주는 것과 다를바 없기때문에 말이 안됩니다.
쿠키맨님의 댓글
SHA256 암호화 방식을 단적인 예로 아래와 같이 설명드릴수 있습니다.
같은 항목으로 입력해도 암호된 값은 똑같이 나오고
순서만 바꿔도 다른 값이 나옵니다.
근데 저걸 복호화한다는건 매우 어렵다고 생각합니다.
입력 1: "홍길동,010-1234-5678,서울시 강남구"
SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
입력 2: "010-1234-5678,서울시 강남구,홍길동"
SHA-256: f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
같은 항목으로 입력해도 암호된 값은 똑같이 나오고
순서만 바꿔도 다른 값이 나옵니다.
근데 저걸 복호화한다는건 매우 어렵다고 생각합니다.
입력 1: "홍길동,010-1234-5678,서울시 강남구"
SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
입력 2: "010-1234-5678,서울시 강남구,홍길동"
SHA-256: f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
lastseven님의 댓글
비호감 중국이라 더 뚜드려 맞는 것도 있죠...카카오페이가 안이하게 대처를 했어요...
쿠키맨님의 댓글의 댓글
@lastseven님에게 답글
그럴수도 있지만,,, 요즘 금감원 하는짓이 뭔가 맘에 안들어요 ㅋ
당무님의 댓글
"일반적인 암호화 프로그램으로 복호화가 가능"
그 일반적인 프로그램 좀 구하고 싶네요.
아마 기자가 어디서 줏어들은거 짜집기하다가 내용이 이상해진 것이라고 생각합니다.
그 일반적인 프로그램 좀 구하고 싶네요.
아마 기자가 어디서 줏어들은거 짜집기하다가 내용이 이상해진 것이라고 생각합니다.
쿠키맨님의 댓글의 댓글
@당무님에게 답글
카카오페이가 정말 알리에게 암호화 방식을 자세히 설명했다면 복호화 할 수도 있겠지만..^^;
설마 그런짓은 안했을꺼라 생각하고
사실 그랬다면 어떤 보안방식이든 다 뚫리죠.(결국 사람이 취약점이긴 하죠)
설마 그런짓은 안했을꺼라 생각하고
사실 그랬다면 어떤 보안방식이든 다 뚫리죠.(결국 사람이 취약점이긴 하죠)
당무님의 댓글의 댓글
@쿠키맨님에게 답글
암호화 방식을 알아도 복호화는 불가능하죠.
본문에 두 단어가 나오는데요. 아마 기자가 구분을 제대로 못한 것일 겁니다.
"복호화" - 불가능
"유추" - 제한적으로 가능
챗GPT가 안된다고 했으니 안되는 겁니다. 에헴
SHA-256은 암호화 해시 함수로 설계되어 있으며, "복호화"가 불가능합니다. 해시 함수는 입력 데이터를 고정된 크기의 해시 값으로 변환하지만, 이 과정을 역으로 진행하여 원래 데이터를 복원할 수는 없습니다. SHA-256은 보안성을 위해 일방향으로 설계되었으며, 이는 입력 데이터를 해시 값으로 변환할 수 있지만, 그 해시 값에서 원래 데이터를 찾는 것은 매우 어렵거나 사실상 불가능하다는 것을 의미합니다.
다만, 특정 SHA-256 해시를 통해 원래 데이터를 유추하려면 다음과 같은 방법을 사용할 수 있습니다:
무차별 대입 공격(Brute Force Attack): 가능한 모든 입력을 시도하여 해시 값이 일치하는 입력을 찾는 방식입니다. 하지만 이 방법은 매우 비효율적이며 시간이 많이 소요됩니다.
레인보우 테이블(Rainbow Tables): 미리 계산된 해시 값을 저장한 테이블로, 특정 해시 값이 일치하는 입력을 빠르게 찾을 수 있도록 도와줍니다. 하지만 현대 암호화 시스템에서는 솔트(salt)와 같은 추가적인 보안 기법을 사용하여 레인보우 테이블 공격을 방어합니다.
사전 공격(Dictionary Attack): 일반적으로 사용되는 패스워드나 문자열의 해시 값을 미리 계산해 두고, 이를 바탕으로 해시 값을 비교하는 방법입니다.
이러한 방법들은 주로 암호 해독을 목적으로 하지만, SHA-256과 같은 현대적인 해시 함수는 이러한 공격에 매우 강력하며, 해시 값을 역으로 변환하는 것은 실질적으로 불가능합니다. SHA-256의 주요 목적은 데이터 무결성을 보장하고, 비밀번호 저장 등의 보안 목적으로 사용되는 것입니다.
본문에 두 단어가 나오는데요. 아마 기자가 구분을 제대로 못한 것일 겁니다.
"복호화" - 불가능
"유추" - 제한적으로 가능
챗GPT가 안된다고 했으니 안되는 겁니다. 에헴
SHA-256은 암호화 해시 함수로 설계되어 있으며, "복호화"가 불가능합니다. 해시 함수는 입력 데이터를 고정된 크기의 해시 값으로 변환하지만, 이 과정을 역으로 진행하여 원래 데이터를 복원할 수는 없습니다. SHA-256은 보안성을 위해 일방향으로 설계되었으며, 이는 입력 데이터를 해시 값으로 변환할 수 있지만, 그 해시 값에서 원래 데이터를 찾는 것은 매우 어렵거나 사실상 불가능하다는 것을 의미합니다.
다만, 특정 SHA-256 해시를 통해 원래 데이터를 유추하려면 다음과 같은 방법을 사용할 수 있습니다:
무차별 대입 공격(Brute Force Attack): 가능한 모든 입력을 시도하여 해시 값이 일치하는 입력을 찾는 방식입니다. 하지만 이 방법은 매우 비효율적이며 시간이 많이 소요됩니다.
레인보우 테이블(Rainbow Tables): 미리 계산된 해시 값을 저장한 테이블로, 특정 해시 값이 일치하는 입력을 빠르게 찾을 수 있도록 도와줍니다. 하지만 현대 암호화 시스템에서는 솔트(salt)와 같은 추가적인 보안 기법을 사용하여 레인보우 테이블 공격을 방어합니다.
사전 공격(Dictionary Attack): 일반적으로 사용되는 패스워드나 문자열의 해시 값을 미리 계산해 두고, 이를 바탕으로 해시 값을 비교하는 방법입니다.
이러한 방법들은 주로 암호 해독을 목적으로 하지만, SHA-256과 같은 현대적인 해시 함수는 이러한 공격에 매우 강력하며, 해시 값을 역으로 변환하는 것은 실질적으로 불가능합니다. SHA-256의 주요 목적은 데이터 무결성을 보장하고, 비밀번호 저장 등의 보안 목적으로 사용되는 것입니다.
글렌1님의 댓글의 댓글
@당무님에게 답글
지피티도 알고 있네요. 레인보우 테이블
카카오는 솔트가 없었답니다.
그러니 뚤리죠
카카오는 솔트가 없었답니다.
그러니 뚤리죠
쿠키맨님의 댓글의 댓글
@글렌1님에게 답글
공문을 보시기 바랍니다.
그리고 각 필드를 별도로 암호화해서 보내줄 이유는 없습니다.
그리고 각 필드를 별도로 암호화해서 보내줄 이유는 없습니다.
본질로님의 댓글
지나가는 일반인입니다… 무슨 말씀들이신지…?
소금은 왜 치나요? 계란 후라이도 아니고…
일반인 범주가 뭡니까 대체;ㅁ;
소금은 왜 치나요? 계란 후라이도 아니고…
일반인 범주가 뭡니까 대체;ㅁ;
푸른미르님의 댓글
개인정보를 해쉬(SHA-256) 함수로 인코딩해서 보내면 일반적으로 안전합니다
단, 랜덤 솔트를 친다는 전제하에서요
해쉬에 소금을 안치면 레인보우 어택 처럼 굉장히 많은 연산을 통해 공격을 시도하면 충분히 뚫립니다
요즘같이 빅데이터 처리가 일상화된 상황에서 핸드폰번호 정도는 충분히 뚫리고도 남죠
숫자 10개 디지트의 8개만 유추하면 되는데 대략 10의 8승 정도의 데이터와 비교하면 되니 순식간에 뚫리겠네요
이메일은 좀 더 경우의 수가 많아지겠지만 충분히 뚫을 수 있겠죠
더 큰 문제는 개인(신용)정보를 해쉬처리 해서 전달했다고 근거가 확보되는건 아니라는 거죠
특히 해외구매 이력이 없는 개인신용정보 주체의 개인신용정보가 해외로 전달 된 것이 사실이라면 큰 문제죠
단, 랜덤 솔트를 친다는 전제하에서요
해쉬에 소금을 안치면 레인보우 어택 처럼 굉장히 많은 연산을 통해 공격을 시도하면 충분히 뚫립니다
요즘같이 빅데이터 처리가 일상화된 상황에서 핸드폰번호 정도는 충분히 뚫리고도 남죠
숫자 10개 디지트의 8개만 유추하면 되는데 대략 10의 8승 정도의 데이터와 비교하면 되니 순식간에 뚫리겠네요
이메일은 좀 더 경우의 수가 많아지겠지만 충분히 뚫을 수 있겠죠
더 큰 문제는 개인(신용)정보를 해쉬처리 해서 전달했다고 근거가 확보되는건 아니라는 거죠
특히 해외구매 이력이 없는 개인신용정보 주체의 개인신용정보가 해외로 전달 된 것이 사실이라면 큰 문제죠
니파님의 댓글