2009-09-04 10 views
14

Mam starą aplikację, która ma hasła użytkownika przechowywane w bazie danych za pomocą skrótu MD5. Chciałbym zastąpić to czymś w rodzinie SHA-2.Jak mogę przekonwertować haszowanie hasła z MD5 na SHA?

Pomyślałem o dwóch możliwych sposobach, aby to osiągnąć, ale obie wydają się raczej niezgrabne.

1) Dodaj boolean pole "flag". Gdy użytkownik po raz pierwszy uwierzytelni się po tym, zamień hash hasła MD5 z hasłem hasła SHA i ustaw flagę. Mogę następnie sprawdzić flagę, aby sprawdzić, czy hash hasła zostało przekonwertowane.

2) Dodaj drugie pole hasła do przechowywania skrótu SHA. Gdy użytkownik po raz pierwszy uwierzytelni się, zaszyfruje hasło za pomocą SHA i zapisze go w nowym polu (prawdopodobnie usunie swój skrót MD5 w tym samym czasie). Następnie mogę sprawdzić, czy pole SHA ma wartość; to w zasadzie staje się moją flagą.

W obu przypadkach uwierzytelnianie MD5 musiałoby pozostać na miejscu przez jakiś czas dla wszystkich użytkowników, którzy logują się nieczęsto. Wszyscy użytkownicy, którzy nie są już aktywni, nigdy nie zostaną przełączeni na SHA.

Czy jest lepszy sposób to zrobić?

+3

Twoje dwa rozwiązania wyglądają mi dobrze. – wtaniguchi

+0

I podnoszę odpowiedź Neda, on ma dobry punkt. – wtaniguchi

+5

Jeśli chodzi o użytkowników, którzy nigdy nie zostali przełączeni - rozważałbym, gdy pewien procent osób zostanie przełączony i upłynie wystarczająco dużo czasu, aby pozbyć się skrótów MD5. Osoby, które nie zalogowały się w tym czasie, będą musiały zresetować swoje hasła, gdy i kiedykolwiek będą się logować. To, czy akceptacja (i kiedy) jest akceptowalna, jest decyzją biznesową. –

Odpowiedz

11

zasadniczo taki sam, ale może bardziej elegancki niż dodając dodatkowe pola: w domyślnej można zorganizować uwierzytelniania w Django, hashe haseł są przechowywane jako ciągi skonstruowanych tak:

hashtype$salt$hash 

Hashtype jest albo SHA1 lub MD5 salt to losowy ciąg używany do zasolenia surowego hasła, a na końcu pojawia się samo hash.Przykładowa wartość:

sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4 
+0

To jest najlepsza odpowiedź. –

+0

Jedyny problem polega na tym, że przechowuje sól w taki sposób, że czyni ją oczywiście solą, zamiast używać innej unikalnej lub pochodnej wartości dla użytkownika (takiej jak zmutowana wersja sygnatury czasowej ich konta lub bitu -wybieranie ich nazwy użytkownika itp.). Można spierać się, czy to powoduje jakąkolwiek obecnie możliwą różnicę w tym, ile czasu zajmie złamanie, jestem po prostu paranoikiem. – defines

+0

@Dustin: dodatkową mocą jest to, że sól może być zmieniana za każdym razem, gdy użytkownik zmieni swoje hasło. – Joshua

3

Myślę, że masz już najlepsze możliwości. Lubię # 1 więcej niż # 2, ponieważ nie ma sensu dla md5 po ustawieniu sha.

Nie ma możliwości odwrócenia MD5, więc należy poczekać, aż użytkownik ponownie się uwierzytelni, aby utworzyć nowy skrót.

0

Twoja druga sugestia brzmi dla mnie najlepiej. W ten sposób często użytkownicy będą mieli bezpieczniejsze doświadczenie w przyszłości.

Pierwszy efektywnie działa w trybie "dziwactwa" i zapewnia tylko, że nowi użytkownicy mają lepszą obsługę SHA.

+0

Wydaje mi się, że oba rozwiązania są takie same, a jedynie nieco inaczej zaimplementowane. W obu przypadkach twoje hasło zostanie ponownie zmienione przy następnym logowaniu. –

+0

W każdej z tych opcji wymieniłabym hasła istniejących użytkowników przy następnym logowaniu. To tylko kwestia, jak powiadomić aplikację, która mieszanka ma być używana po tym. –

2

Nie - zasadniczo musisz trzymać MD5 w miejscu, dopóki wszyscy zainteresowani użytkownicy nie zostaną przekonwertowani. To jest właśnie charakter mieszania - nie masz wystarczających informacji, aby ponownie przeprowadzić konwersję.

Inną opcją w-zgodzie z innymi byłoby, aby skutecznie pole hasła self-opisując, np

MD5:(md5 hash) 
SHA:(sha hash) 

Następnie można łatwo wykryć, który algorytm należy użyć do porównania i uniknąć dwóch pól. Ponownie, będziesz nadpisywać MD5 przy pomocy SHA.

pewnością chcesz zrobić wstępną aktualizację, aby wszystkie aktualne hasło deklarują się jako MD5.

+4

Rozmiar skrótu powoduje, że jest samoopisujący: MD5 jest zawsze mniejszy. –

+2

Długość nie może być jedynym wskaźnikiem. Możesz chcieć zmienić to, co dzieje się w haszymdzie (na przykład obliczenia nonce, inne dane o źródle), używając tego samego algorytmu do mieszania, aby wszystko przetrawić. Posiadanie osobnego identyfikatora wskazuje, który z systemów hashowania * twojego * hasła jest w użyciu. – Rob

+1

Jeśli twoje jedyne dwie metody różnią się długością, z pewnością możesz użyć długości jako wskaźnika. –

-1

Jeśli MD5 nie są solone zawsze można użyć tabel strona deszyfrowania/tęczowe, takie jak: http://passcracking.com/index.php uzyskać haseł. Prawdopodobnie łatwiej jest po prostu użyć metody ponownego kodowania.

+5

Jeśli jest to wykonalne, nie jest to zbyt etyczne, o ile nie zechcesz przechowywać hasła podczas ich łamania. –

+3

@ Vinko - z jakiegoś powodu jest to nieetyczne, nawet jeśli starasz się, aby hasło nie było przechowywane/wyciekło. –

6

można przekonwertować wszystkie swoje MD5 Struny do SHA1 przez hashuje je w DB jeśli tworzysz swoje przyszłe haseł najpierw je MD5ing. Sprawdzanie haseł wymaga najpierw MD5 ich również, ale nie sądzę, że to duży hit.

php-kod (login):

Prev: $ logowanie = (md5 ($ password) == $ storedMd5PasswordHash);

po: $ login = (sha1 (md5 ($ hasło)) == $ storedSha1PasswordHash);

Działa również z soleniem, ale otrzymała wstępny pomysł od here.

-4

Tak powinieneś poznać prawdziwe hasło zanim przekształcić go w SHA-1 ..

Jeśli chcesz znaleźć prawdziwe hasło z md5 szyfrowane ciąg, można spróbować md5pass.com

+3

To nigdy nie powinno być możliwe w dobrze zaprojektowanym systemie. Wszystkie hasła powinny być przechowywane w solance. –

Powiązane problemy