관리자님 조금만 힘내세요... ^_^

음...결국 new password() 를 선택하셨군요..
많은 고민이 있었을걸로 보입니다..

* 개인적인 사견을 한 마디 더 드리자면...
새로운 도약을 위해서는 과거의 것은 포기하는것도 좋은 방법이라 생각합니다..
MS 의 윈도우 95/98 이 왜 실패한 O/S 였는지를 한 번쯤 생각해볼 필요가 있지 않을까? 생각합니다..
기존 도스의 8/16비트를 떠안기 위한 (도스 사용자들이 너무 많았으므로..) 궁여지책이 결국은 실패한 O/S를 만들어낸게 아닐까? 생각합니다..
* 훌륭한 보드인 그누보드 3.x 는 3.x 로 두고 새로운 플랫폼과 알고리즘을 가지는 4.x 로 가는 것도 좋은 선택이 아니었을까 하는 바램이었습니다..

제가 말하고자 하는것은 주민번호 뒷자리 7자리를 저장하려는것이 아닌 인증번호를 만들기위해서 이며,
짬뽕된 숫자를 md5()로 임의 인증키를 만들고 그것을 임시로 인증DB저장하여,
가입시 메일로 날라간 인증키를 주민번호와 함께 입력해서 비교하는것을 말했던 겁니다.

플로어차트를 설명드리자면,

회원가입시
1. 회원 주민번호 를 입력, 이름 입력, 이메일 입력
2. 메일 인증을 위한 버튼 클릭 ( form sumit) , 2번째 페이지로 이동
3. 클릭에 해당하는 시간과 주민번호 7자리 암호화 md5();
4. 해당 인증키 임시DB저장 , 해당 메일로 발송
5. 사용자는 받은 메일을 가지고 2번째 페이지에서 인증번호 입력, 및 각종 정보 입력 (단! 여기선 주민등록 미기입)
6. Form sumit
7. 해당 인증DB와 기입된 인증키 체크, 맞다면 해당 임시DB저장된 인증키 삭제후,
8. 해당 아이디 생성,

위의 알고리즘에서 문제가 되는것은 임시로 발급된 키가  메일로 발송되지 않았을경우와,

트랜잭션이 이루어지지 않아 2~3페이지 사이에 롤백되는경우 문제가 생길수 있을껍니다.

뭐 대충 이러한 것을 생각해보았습니다.. 구현 가능하지 않을런지..

또한 기존의 주민등록이 암호화 되어있다고 하셨는데..
조금만 php를 아는사람은 그 password()함수를 제거하고 사용할수도 있다는것을 알았으면 합니다.

아.. 문제가.. 중복가입이었군요..
위의 알고리즘대로하면 중복가입을 해결할수는 없네요 ㅠㅠ;

만약 중복체크에 대한 유니크 필드를 찾지 못한다면..

주민등록 기입은 없앨수 없을꺼 같습니다.

현존의 1개짜리 필드를 2개로 나누어  앞자리6자, 뒷자리7자 를 구분하되
주민등록 기입은 앞자리 6개만 받으며,

뒷자리 7개를 인증거치는 시간의 timestemp와 짬뽕하여 mb5() 한뒤
이것을 인증 코드로 메일 인증을 거치게 한다면 안될까요?

이러면 복호화가 전혀 될수없습니다.
중복경우 주민 앞자리6자리와 이름 그리고 ID, 메일주소 체크로 가능하지 않을런지..

//This님
주민번호가 아닌, 회원가입시 기입하는 '생일'에 기입될 내용을
필수입력사항으로 '생일'을 입력하게 만드면,
굳이 "생일자 명단.php"는 사라질 필요는 없다고 봅니다.

'주민등록번호'의 강제기입(?!)은 사라져야 한다고 봅니다만,
관리자님의 말씀마따나 '중복가입'이라는 폐단이 발생할 수 있다는 부분이
상당히 걸리는 부분입니다.

그냥 개인적인 생각입니다

주민번호을 암호화 할필요성이 있나 싶네요 ㅡㅡ??

주민번호을 암호화 할 이유가 절대적으로 없다고 생각합니다.

그나저나 주민번호가 없으면 "생일자 명단.php" 는 사라지겠군요 ;;;;;

그런데 언제 그누보드4를 볼수있는거죠? 보안, 호완성---어휴 제게는 두 마리 토끼로 보여 너무 어렵습니다.

md5( ) 로 전환되어야 한다고 봅니다.
기존틀과의 호환을 우선으로 둔다면 효과적인 발전은 기대할 수 없다고 여깁니다.

1. 고민하시는 모습에 감사드립니다.

2. 암호화는 MD5로 갔으면 합니다.
3. 호환성을 위해 'password() to md5'를 누군가는 개발해야 합니다.

4. 주민번호 입력란은 꼭 필요합니다.
5. 주민번호 입력을 받느냐 안 받느냐는 해당 사이트에서 결정할 수 있어야 합니다.

제 생각입니다.

md5()의 사용은 찬성합니다.

현재 기존의 password()를 사용하는 필드 mb_passwd와 mb_jumin이었는데..

이중 mb_jumin을 빼버리신다고하니 걸림돌은 비밀번호가 되겠군요..

상용 홈페이지인경우 문제가 되겠네요.. 
주민등록번호 부재의 경우 악플과 홈페이지의 난잡을 초래할수도있습니다.
또한 광고로봇과 관련 도배로 홈페이지가 깨지는것도 감수해야할뜻 보이구요..

아이디찾기같은 경우는 쉽게 그대안이 있을수 있겠으나
중복가입문제의 대안은 글쎄요.....힘들것 같은데요.
실질적으로 1인 1 id 를 제한할수 있는건 오직 주민등록번호외에 실질적인 대안이 있을까요?
흠...

제가 뜻일 잘 이해가 안되서 이해가 잘안되네요 주민등록번호을 제외하신다는 말씀은?...

주민번호 없이 가입가능 하다는 뜻인가요? (물론 이건 아니겠죠?)

아님 주민번호는 md5을 적용 안한다는 뜻인가요?

주민번호 없이 가입 가능하게 하면 문제점이 ㅡㅡ; 상당히 많을것인데 쇼핑몰이나 동일인물 가입중복등..등.

관리자님 그럼 데이타는 아무상관없고 ? 회원 비밀번호에만 관련된 문제만 있다는 말인가요?

전 데이타 자료만 좀 있고 회원수 몃명안되서 ..... ㅡㅡ;;

만약에 md5 로 바꾸시면 데이타베이스가 완전히 바뀐다는 말씀인가요?
아님 아이디(비밀번호) 만 바뀐다는 말인가요?
지금 password() 함수 적용 되는게? 암호하고 주민번호하고 또있나?

회원 관련 데이타만 바뀐다면야.. 다행이지만...

아 첨에 그누 사용할때 md5 인줄알았느데 ㅡㅡ; 뭐 초보다 보니 소스는 봐도 모르고.. md5가 뭔지는 알아지만..아니었군요...

md5 추천이긴한데 그전에 자료들은 어더게 하지 ㅡㅡ;;;;;;;;;;;;

복호화 알고리즘이 있으니까.
password() 암호화를 복호화 해서 다시
md5()로 암호화 시켜 주는 컨버터를 만들어 주심 될것같은데요..

컨버터로 제가공? 어려운가? 귀찮은가?
사실 귀찮기는 하겠네요... ㅋㅋㅋ  걍 사용해요~ 언제 패치파일 다운받아 실행시켜~~
귀찮아서 원~~~ㅋㅋㅋ

절대 보안이 우선입니다.
md5 ~ 한표입니다.
복호화 알고리즘은 거의 없다고 생각되구요.
무차별 대입또한 수퍼급 컴퓨터가 아닌이상 그리 만만하지 않다고 생각되고요. 
그렇다면....~ md5 추~~
복호화 알고리즘 이 존재하는 암호화란 ....
하나마나 아니겠어요?
호환은 두번째라 생각

보안이 우선이 되야하지 않을까요....??? 하지만 기존 자료도 생각해야 한다면.....
호환 또한 생각 안할수 없는 문제이고...
하지만 보안이 뚫린다면.... 더 큰 피해가 있을수 있으니...
저도 md5()에 한표를 던지고 싶습니다...
관리자님 힘내세요....^____________^  화팅~~!!!!!

제작자나 관리자 입장에서는 물론 정보를 다시금 손봐야 하는 부담이 있지만..
정보가 유출되는것은 부담을 넘어선 문제가 될것 같습니다.
저도 md5()를 추천 합니다.. ^^*

기존 자료변경방법을 확실하게 정해주시고 바꾸면 좋겠습니다.

mysql 4.x 대로 오면서 password 함수에 대한 변경으로 여러가지 혼란이 온것이 사실입니다.
그리고 버젼업이 될수록 여러가지 상황에 맞추어서 지원하는 방식이 달라지는 것 또한 사실이죠..
아마 앞으로도 계속 그럴거라 생각이 됩니다.
그렇다면, 앞으로의 지원방식에 대한 변경을 염두에 두고 독립적으로 갈 수 있는 md5() 가 어떨지...
개인적인 사견입니다..

이런 내용을 투표로 옮기는 것이 좋지 않을까요?..^.^..

개인적으로는 md5()에 한표입니다. 사실 비밀번호 다시 입력받는 것은 여러가지 방법으로 가능하지 않습니까..^.^.

흠. 어렵네요..
최강그누보드

호환은 나중에 일괄 패치가능한 파일하나 만들어서 패스워드 패치하도록 수정하면 될것 같고 (그래봐야 유저가 입력받은값 비밀번호 password값하고 일치하는지 확인하고 특정필드 만들고 패스워드 변경되었는지 확인해서 안되었으면 MD5로 저장하는 귀찮은 방식이 되겠지만)
아무래도 보안은 가장 중요한부분이기때문에 호환에 문제가 되지만...어차피 그누3과 그누4의 소스자체가 주소체계의 큰 차이로 호환이 안될껀데 바뀔때 과감하게 그리고 확실한게 좋타에 한표 던져봅니다.

흐음... 저는 검증된 MD5를 추천하고 싶네요 :)
호환이야. 관리자께서 컨버터를 만들어 주시기를 바랄 뿐이고요 ㅠ_ㅠ..

password 가 어디로 빠져 나간것만 해도 뭔가 잘못이 있어보이는데...;;

아무튼.. 16자리로 절대적이라면...
password 저장 바로전 앞, 뒤에 다른 문자나 숫자를 대입시키는건 별거 아닐래나요?

제 생간엔 항상 호환이 앞서야 한다고 생각합니다.

플스2가 성공할수 있었던 계기가 ps1 호환이라죠.
0보드도 스킨(호환)이 아니였다면... 그 것도 그럴꺼구요.

삽집 => 삽질 ^^

제가 아는게 없지만 저 같으면.....

보안이 우선입니다. ^^*
자료야 삽집 좀 하면 되죠뭐....

관리자님 최종결정을 적극 지지합니다.
개인적으론 모두들 말씀하신것 처럼 md5()를 했으면 합니다만
보드의 호환성을 위해서 password() 결정하신것은 잘하신 것이라 생각됩니다.

위에서 짱이님이 말씀하신것처럼
>> 호환성을 위해 'password() to md5'를 누군가는 개발해야 합니다.

password() to md5()가 가능하다면(개인 pc 레벌에서 하루이틀... 일주일정도 돌려서) 관리자님 의견에 적극 지지하지는 못할것 같군요. 그러나 그놈이 그렇게 쉬운것이 아니라고 판단되므로 호환성을 생각하신것은 잘결정하신것이라 생각합됩니다.

그리고 앞으로도 기존 사용자들을 위한 호환성에 많은 지원을 아끼지 않으셨으면 합니다.

g4 출시시점에서도 기존 3.xx 사용자를 위한 테이블 변경 스크립터 하나정도 돌려주셔서
그후에는 신경 안써도록 되었으면 좋겠구요.(신규 설치는 필요없겠지만)

스킨변경이야 이것도 쉬운것은 아니지만 2.65에서 3.xx로 변경되면서 한번들 해보신 일이므로 그나마 조언자들이 많을것이라 생각되는구요.