웹 사이트의 아이디와 비밀번호

songgun의 이미지

다른 글타래를 읽어보다가 문득 생각이 났습니다. 사실 이전에는 혼자 생각만 하고 있었지 이렇게 글을 올려서 여러분들에게 의견을 여쭤볼 생각은 전혀 못하고 있었네요. 자 그럼 본론으로 들어갑니다. :wink:

저만 그런 것인지는 모르겠으나 제가 사용하는 모든 웹 사이트들의 아이디와 비밀번호는 크게 두 부류로 나누어집니다. 아마 읽어보시면 그 취지는 이해가 가실 것이라고 생각합니다.

1. 인터넷 뱅킹과 같이 돈의 흐름이 직접적으로 관여되는 웹 사이트에서 사용하는 아이디와 비밀번호.

2. 1. 번에 해당하지 않는 대부분의 모든 웹 사이트에서 사용하는 아이디와 비밀번호.

물론 1. 번의 경우가 더 비밀번호가 복잡하고 어렵죠. 그리고 이런 조건에 해당하는 사이트들은 몇 개 되지 않습니다. 그런데 문제는 2. 번의 경우입니다. 외우기가 어렵다는 이유로 보통 2. 번에 해당하는 아이디와 비밀번호를 가급적 통일하게 되는데, 조건에 해당하는 모든 사이트에 동일하다는 것이 바로 문제가 되죠. 예를 들어서 제가 2. 번 조건의 사이트에서 사용하는 아이디가 ABC 이고 비밀번호가 1234 라고 가정해 보겠습니다. 그러면 대부분 다음과 같은 결과가 발생합니다.

- KLDP 의 아이디와 비밀번호 : ABC / 1234
- 웹 메일의 아이디와 비밀번호 : ABC / 1234
- 경매 사이트의 아이디와 비밀번호 : ABC / 1234
- 개발자 사이트의 아이디와 비밀번호 : ABC / 1234
- 개인 홈페이지의 아이디와 비밀번호 : ABC / 1234
- 대형 쇼핑몰 사이트 A 의 아이디와 비밀번호 : ABC / 1234
- 소규모 쇼핑몰 사이트 B 의 아이디와 비밀번호 : ABC / 1234
- 유머 사이트의 아이디와 비밀번호 : ABC / 1234
- 기타 등등등...

그런데 어떤 조그마한 사이트의 프로그래머가 있는데 아주 도덕적으로 못된 사람이라고 가정을 해보겠습니다. 그리고 어느날 저와 같은 생각을 하게 된거죠. 그래서 자기가 관리하는 사이트의 데이터베이스에 들어가서 만만한 제 이름을 보고 아이디와 비밀번호를 알아냅니다.

그리고 그 아이디와 비밀번호로 국내의 유명한 대형 사이트 몇 곳을 로그인 시도해본다면.... 아마 10 곳 중 최소한 한 두 군데는 로그인이 되는 상황이 발생하는 거죠. 이 경우 웹 메일이나 싸이월드 또는 개인 홈페이지가 그 대상이 된 경우라면 피해가 엄청날 것입니다.

따라서 저는 반드시 모든 비밀번호는 비가역적인 방법으로 암호화가 이루어져야 한다고 생각합니다.

기술적으로 로그인 처리시에도 전혀 문제가 없는 것이 사용자가 입력한 비밀번호를 동일한 로직으로 암호화해서 데이터베이스의 값과 비교하면 되기 때문에 문제 될 것이 전혀 없습니다.

어떻게 생각하십니까? 어쩌면 저희들은 이미 엄청난 위험에 노출되어 있는 것인지도 모릅니다.

neogeo의 이미지

=ㅅ= 제가 회사 제일처음 입사해서 한일이 이겁니다.

mysql db 에 있던 plain text 를 crypto 한번 돌려줬죠.

이래저래 귀찮았지만 db dump 뜰때마다 passwd 가 보이는건

마치 회사에서 여자 알몸구경하는거랑 같이 낯이 뜨거운 일이더군요.

정말 양심적인 개발자라면 주민번호도 이렇게 해줘야하고

무엇보다 db 유출을 막는데 최선을 다해야 겠지요 ㅠ_ㅠ

Neogeo - Future is Now.

sio4의 이미지

songgun wrote:

따라서 저는 반드시 모든 비밀번호는 비가역적인 방법으로 암호화가 이루어져야 한다고 생각합니다.

기술적으로 로그인 처리시에도 전혀 문제가 없는 것이 사용자가 입력한 비밀번호를 동일한 로직으로 암호화해서 데이터베이스의 값과 비교하면 되기 때문에 문제 될 것이 전혀 없습니다.

어떻게 생각하십니까? 어쩌면 저희들은 이미 엄청난 위험에 노출되어 있는 것인지도 모릅니다.

이미 말씀하시는 방법을 사용하는 사이트들이 꽤 있습니다. 간접적인, 그리고 신빙성은 떨어지는 확인 방법 중 하나는, "암호 찾기" 나 그와 유사한 서비스를 이용할 때 "당신의 암호는 xxx 입니다."라고 친절하게 안내해주는 서비스와 "당신의 암호를 yyy 로 (내 맘때로)초기화하였으니 수정하십시오" 하는 버릇없는 경우입니다.

친절한 사이트를 만나면... 뭐, 그 사이트가 밉지는 않습니다. 사업하는 사람이 암호화 기술에 대하여 알 필요는 없으니까요.(은행장들도 그런 의미에서 밉지 않습니다.) 다만, 사명을 다하지 않은, 장인정신이 부족한 그 사이트의 개발자들이 밉습니다.

사용자의 입장에서 "차별화된 암호"를 사용하는 것이 필요할 것이고 개발자/전산관련자의 입장에서 "쉬운 길보다 바른 길"을 가기 위한 노력, "바른 길"을 찾기 위한 노력, "바르게 정해놓은 길"을 귀찮아도 따르려는 노력이 필요하겠습니다.

--
"The love you take is equal to the love you make." The End, by Beatles

mudori의 이미지

이것이 문제일지도.

hyperhidrosis의 이미지

국내의 상당수 많은 유명 사이트들이 암호를 암호화 하지 않고 저장합니다.

암호를 암호화 해서 저장하는것이 전혀 어렵지 않음에도 불구하고

그냥 무시합니다..

이 글을 보시는 분중 자신이 관리하는 사이트가 암호를 암호화 해서 처리하지 않는다면 반성하시고 빨리 수정해 주셨으면 합니다.

tinywolf의 이미지

sio4 wrote:
간접적인, 그리고 신빙성은 떨어지는 확인 방법 중 하나는, "암호 찾기" 나 그와 유사한 서비스를 이용할 때 "당신의 암호는 xxx 입니다."라고 친절하게 안내해주는 서비스와 "당신의 암호를 yyy 로 (내 맘때로)초기화하였으니 수정하십시오" 하는 버릇없는 경우입니다.

친절한 사이트를 만나면... 뭐, 그 사이트가 밉지는 않습니다. 사업하는 사람이 암호화 기술에 대하여 알 필요는 없으니까요.(은행장들도 그런 의미에서 밉지 않습니다.) 다만, 사명을 다하지 않은, 장인정신이 부족한 그 사이트의 개발자들이 밉습니다.

앗.. 암호를 알려주는 것이 맞는다는 말인가요?
음.. 전 암호가 암호화되어 있어서 찾기를 하더라도 역으로 찾을 수 없으니 임의로 생성된 암호로 변경하고 다시 고치라고 시키는 것인줄 알았는데..
그래서 암호를 알려주는 사이트보단 암호를 변경해주는 사이트가 올바른 거라고 생각하고 있었습니다..
왠지 헷갈리는군요..

ㅡ_ㅡ;

sio4의 이미지

tinywolf wrote:
sio4 wrote:
간접적인, 그리고 신빙성은 떨어지는 확인 방법 중 하나는, "암호 찾기" 나 그와 유사한 서비스를 이용할 때 "당신의 암호는 xxx 입니다."라고 친절하게 안내해주는 서비스와 "당신의 암호를 yyy 로 (내 맘때로)초기화하였으니 수정하십시오" 하는 버릇없는 경우입니다.

친절한 사이트를 만나면... 뭐, 그 사이트가 밉지는 않습니다. 사업하는 사람이 암호화 기술에 대하여 알 필요는 없으니까요.(은행장들도 그런 의미에서 밉지 않습니다.) 다만, 사명을 다하지 않은, 장인정신이 부족한 그 사이트의 개발자들이 밉습니다.

앗.. 암호를 알려주는 것이 맞는다는 말인가요?
음.. 전 암호가 암호화되어 있어서 찾기를 하더라도 역으로 찾을 수 없으니 임의로 생성된 암호로 변경하고 다시 고치라고 시키는 것인줄 알았는데..
그래서 암호를 알려주는 사이트보단 암호를 변경해주는 사이트가 올바른 거라고 생각하고 있었습니다..
왠지 헷갈리는군요..

헉! 재 글쓰는 태도가 좀 바람직하지 못한가 봅니다. :-)

친절히 잊어버린 암호를 기억해뒀다가 알려주는 사이트를 보면,
1) 뭐가 뭔지 모르는 사이트 주인은 안밉다.
2) 그딴식으로 일하고 월급받아간 개발자/개발사는 밉다.
이런 말입니다. (적어도 보안/암호화에 대한 의식이 상대적으로 부족한 일반인에게는) 친절해 보이겠지만... 아주 얍삽하고 일의 도를 모르는 양의 탈을 쓴 늑대라는 말이죠 :-(

(늑대님, 혹시 이 글을 읽더라도 저를 너무 미워하지 마세요~ 늑대 맞잖아요~ ;-)

--
"The love you take is equal to the love you make." The End, by Beatles

whitelazy의 이미지

파이어 폭스 확장기능중에는....
password composer라는것이 있더군요
익스가 대세인 국내에서는 안전해 질지도 모르겠습니다 -_-;;
마스터키 하나만 있으면 각 사이트URL이랑 조합을 하던가 어쨌던 지가알아서 암호를 조합해서 입력해 줍니다 나름 좋을수도 있습니다...
물론 대신에 파폭없으면 어디도 로그인 못하리라고 추측됩니다... -_-;;
따라서 저는 귀찮아서 안쓰지요...

kkb110의 이미지

저도 songgun님이 말씀하신 문제로 이용자 입장에서 패스워드 관리에 대해 생각해봤었는데
whitelazy님이 말씀하신 파이어폭스의 password composer식의 것이 괜찮은 것 같습니다.

그러니까 일단 자기 패스워드격에 해당되는 string 이랑 사이트의 string이랑 혼합해서 패스워드를 계산해내는거지요

예를들어 자신의 패스워드격에 해당되는 string이 "loveme" 라면
kldp사이트의 비밀번호는
비가역암호화알고리즘("loveme"+"kldp")
daum사이트 비밀번호는
비가역암호화알고리즘("loveme"+"daum")
이런식으로요..

비가역암호화알고리즘을 머리에서 계산해낼 수 있을 정도로 간단한거라면 더 좋겠지요.. 프로그램 없이도 어디서든 그사이트의 비밀번호를 떠올릴 수 있을테니까요.
아니면.. 자신의 사이트에다가 비가역암호화알고리즘루틴을 올려놓고 자신만 아는 다른곳에서 사용하지 않는 패스워드를 입력하면 사용할수있게 해서 웹에서 사용하던가..

나는오리의 이미지

그냥...
개인정보 물어보는 사이트는 가입 안합니다. -_-;
재수없어서...

단 이런 부작용이 있습니다.

미팅시...
여 : 저기 사이 주소가 뭐예요?
나 : 저 사이 안하는데요. -_-;
여 : 요즘 사이 안하는 사람이 어딨어요.
나 : 저 그거 어떻게 하는지도 모르는데요.
여 : (-_-;)그럼 네이트온 아이디는 어떻게 되세요? 친구추가할게요
나 : 저 네이트온 가입만했지 MSN씁니다.
여 : (-_-;)네이트온 안쓰세요?
나 : 네...무료문자보낼때만 1년에 한두번정도 씁니다.
왠만하면 그것도 탈퇴할려고 합니다.
여 : (-_-;)아~그러세요...근데 왜 탈퇴할려고 하세요?
나 : 그회사가 여차저차한 이유로 재수없어서요 (-_-;;;)

처음엔 몰랐는데 이게 여자와 만나는데는 상당한 마이너스더군요.
OTL (가라~ 세~상 모든 커플들은 가라 곧 솔로들의 세상이 올지어니
혼자 외롭게 사는 사람들은 축복받을지어다.)

songgun의 이미지

그렇군요. whitelazy 님과 kkb110 님의 말씀을 듣고 password composer라는 것이 있다는 것을 처음 알았습니다. 이것도 훌륭한 대안이 되겠네요.

다만 whitelazy 님 말씀대로 FF 가 없는 장소에서는 약간 문제가 될 수도 있겠습니다. 그러나 kkb110 님 말씀대로 역변환이 가능한 알고리증이라면 결국 소용없을 것 같네요. 알고리즘이 너무 간단하면 악의적인 사용자도 쉽게 암호를 풀수 있을 테니 소용없고, 반대로 너무 어렵다면 PC 방 같은데서 종이꺼내놓고 계산하고 있어야 할테니 무용지물이잖아요? 하하하, 웬지 그 모습은 상상만해도 재미있을 것 같습니다. :oops:

제일 좋은건 password composer 가 대부분의 브라우저에서 지원되면 좋을 텐데 말이죠.

아무튼 개인적인 여담으로 웹 개발자로서 제일 난감할 때가 이런 경우인것 같습니다. 개인적으로 상당히 마음에 드는 어떤 기능이 있을 때, 그리고 그 기능을 사용하기만하면 걱정이 눈녹듯이 사라지는데 특정 브라우저에서만 그 기능을 지원하는 상황인거죠. 이런 사례로는 최근에 가장 마음에 드는 기능으로 FF 의 확장 기능이 있고, 예전에는 IE 의 HTC 나 HTA 가 있었는데 말입니다.

결국 개발자들이 자발적으로 구현에 신경을 쓰는 방법이 가장 근본적인 방법이 되겠네요. :wink:

nskystars의 이미지

whitelazy wrote:
파이어 폭스 확장기능중에는....
password composer라는것이 있더군요
익스가 대세인 국내에서는 안전해 질지도 모르겠습니다 -_-;;
마스터키 하나만 있으면 각 사이트URL이랑 조합을 하던가 어쨌던 지가알아서 암호를 조합해서 입력해 줍니다 나름 좋을수도 있습니다...
물론 대신에 파폭없으면 어디도 로그인 못하리라고 추측됩니다... -_-;;
따라서 저는 귀찮아서 안쓰지요...

굳이 파폭에 붙어있을 필요는 없지 않나요? 간단하게 다운받을 수 있는 프로그램도 있을 것 같은데요...

검색해보니 관련된 웹사이트도 있네요.
http://www.xs4all.nl/~jlpoutre/BoT/Javascript/PasswordComposer/

addnull의 이미지

nskystars wrote:

굳이 파폭에 붙어있을 필요는 없지 않나요? 간단하게 다운받을 수 있는 프로그램도 있을 것 같은데요...

검색해보니 관련된 웹사이트도 있네요.
http://www.xs4all.nl/~jlpoutre/BoT/Javascript/PasswordComposer/

오.. 유용한 정보 얻어갑니다 ^^

2005년 8월 1일.

topeng의 이미지

sio4 wrote:

친절히 잊어버린 암호를 기억해뒀다가 알려주는 사이트를 보면,
1) 뭐가 뭔지 모르는 사이트 주인은 안밉다.
2) 그딴식으로 일하고 월급받아간 개발자/개발사는 밉다.
이런 말입니다. (적어도 보안/암호화에 대한 의식이 상대적으로 부족한 일반인에게는) 친절해 보이겠지만... 아주 얍삽하고 일의 도를 모르는 양의 탈을 쓴 늑대라는 말이죠 :-(

글쎄요... 패스워드를 암호화해서 저장하지 않는건 개발자만의 문제가 아닙니다. 지금은 어떤지 모르지만, 전에 근무했던 회사에서 사장 지시로 일부러 암호화하지 않았습니다. 이유는, 패스워드를 잊어버린 이용자가 불편해 한다는 거였죠. 그래서 패스워드를 잊어버린 사용자가 간단한 개인 정보를 입력하면 패스워드 일부만 보여주는 형태였습니다. 개발자가 무식해서 암호화를 안 한게 아니라 무식한 사장 때문에 그런거였죠.

단순히 패스워드를 암호화해서 저장하느냐 아니냐의 문제가 아니라고 생각합니다. 암호화해서 저장하더라도 패스워드 파일을 빼내서 dictionary attack을 할 수도 있는 것이고 아니면 스니핑 툴을 설치해서 암호화해서 저장되기 전에 plaintext를 뽑아낼 수 있다는 것입니다.

sio4의 이미지

topeng wrote:
sio4 wrote:

친절히 잊어버린 암호를 기억해뒀다가 알려주는 사이트를 보면,
1) 뭐가 뭔지 모르는 사이트 주인은 안밉다.
2) 그딴식으로 일하고 월급받아간 개발자/개발사는 밉다.
이런 말입니다. (적어도 보안/암호화에 대한 의식이 상대적으로 부족한 일반인에게는) 친절해 보이겠지만... 아주 얍삽하고 일의 도를 모르는 양의 탈을 쓴 늑대라는 말이죠 :-(

글쎄요... 패스워드를 암호화해서 저장하지 않는건 개발자만의 문제가 아닙니다. 지금은 어떤지 모르지만, 전에 근무했던 회사에서 사장 지시로 일부러 암호화하지 않았습니다. 이유는, 패스워드를 잊어버린 이용자가 불편해 한다는 거였죠. 그래서 패스워드를 잊어버린 사용자가 간단한 개인 정보를 입력하면 패스워드 일부만 보여주는 형태였습니다. 개발자가 무식해서 암호화를 안 한게 아니라 무식한 사장 때문에 그런거였죠.

개발자만의 문제가 아닐 수는 있습니다. 다만, 엔지니어가 엔지니어이기 위해서는, 자신의 명예를 걸고 해서는 안되는 일과 해야만 하는 일을 구분할 수 있어야 합니다.

물론, 잘못된 일을 행하도록 강요받을 경우에 "어떤 선택을 해야 하는가?"는 쉽게 말할 수 없는 부분이긴 합니다. 극단적으로 "목구멍이..." 뭐, 이런 류의 이유도 있겠고요. 하지만, 그것이 어쩔 수 없는 선택이었다 하더라도 비난을 피하거나 그 선택을 정당화할 수는 없습니다. 말 그대로... "그땐 그럴 수 밖에... 흑흑..." 일 뿐입니다.

암호를 잊은 회원의 불편을 덜어줄 수 있는 방법은 그 외에도 많이 있지만, 꼭 "힌트"를 줘야겠다면 힌트 부분을 따로 저장하는 것도 방법이었을 것입니다. 어쨌든, "불편"과 "위험"이 어떤 것인지, 어떻게 다른 것인지에 대한 심사숙고가 필요했었을 것 같습니다.

무엇보다도, 사장이라는 사람이 모든 부분에 있어서 완벽하거나 똑똑하거나 유식할 수는 없습니다. 그래서 참모라는 것이 필요하고 각각의 분야에 따라 CFO, CIO, COO, CTO 등을 따로 두는 것입니다.

자신이 모시는 사람이 잘못된 길을 가려 할 때 그것을 일깨워주고 무식하다는 소리 듣고 다니지 않게 도와주는 것 또한 아랫사람의 의무 중 하나입니다.

잘못된 것들을 그냥 따르기 보다는, 작은 노력이든 큰 노력이든, 약간의 고통을 감수하고라도 하나씩 고쳐나갈려고 노력할 때, 우리 모두 "무식한 사장이 없는 세상에서 일하는 날"이 빨리 올 것 같습니다.

topeng wrote:

단순히 패스워드를 암호화해서 저장하느냐 아니냐의 문제가 아니라고 생각합니다. 암호화해서 저장하더라도 패스워드 파일을 빼내서 dictionary attack을 할 수도 있는 것이고 아니면 스니핑 툴을 설치해서 암호화해서 저장되기 전에 plaintext를 뽑아낼 수 있다는 것입니다.

이 글타레의 주제가 "사이트/서비스 보안 전반"은 아닌 것 같습니다. :-) 뭐, 할려면 뭔 짓을 못하겠습니까? 논 몇천 때문에 납치도 하고 도둑질도 하고... 심지어는 XX도 하는 세상인데...

--
"The love you take is equal to the love you make." The End, by Beatles

맹고이의 이미지

패스워드를 다양하게 하고 싶어도 6~8자 내외로 지정하라는 곳이 제법 많아서 상당히 귀찮더군요.

지리즈의 이미지

패스워드 암호화 저장에 관련된 것은
엔지니어의 몫은 아닙니다.

회사 정책(policy)에 관련된 부분이죠.

엔지니어는 제안은 할 수 있고,
그에 대한 장점 단점 득실을 보고서로
그 정책을 구성하는 집단을 설득하는 노력을 할 수 있어도,
결정권은 없다는 것이 제 생각입니다.

생각해 보면,
자판기 요금 정책에 대한 불만과 크게 다를바 없습니다.

단, 해킹이나 여러 사고로 유출되었을 때,
발생할 수 있는 문제에 대해서 기술적으로 무지한 정책구성집단을
설득할 필요성은 있으나, 이도 의무는 아니라 생각합니다.

본인의 양심에 따른 문제일 뿐이지요.

단, 회사 정책에 따르냐 안따르냐는 개인의 문제입니다. :wink:

There is no spoon. Neo from the Matrix 1999.