Personlig vil jeg sannsynligvis implementere både med at nye brukere får en sterk moderne hash (bcrypt eller annen nøkkelforsterket kryptografisk hash) og gamle brukere som har den svake hashen pakket rundt bcrypt. Før folk klager over ekstra implementeringskompleksitet, er alternativet å alltid tvinge nye brukere til å bruke svak hash-algoritme pakket rundt sterk hash-algoritme, og det betyr at du aldri blir kvitt den opprinnelige ordningen.

Jeg vil ha en eller annen dokumentert indikator av typen hash-ordning som er analog med $ 1 $ , $ 2a $ , $ 5 $ , eller $ 6 $ i krypt (sitat fra kryptsiden):

  Hvis salt er en tegnstreng som begynner med tegnene "$ id $" etter ned av en streng avsluttet med "$": $ id $ salt $ kryptert ... id identifiserer krypteringsmetoden som brukes, og dette bestemmer deretter hvordan resten av passordstrengen tolkes. Følgende verdier av id støttes: ID | Metode ─────────────────────── ──────── 1 | MD5 2a | Blowfish (ikke i hovedlinjen glibc; lagt til i noen | Linux-distribusjoner) 5 | SHA-256 (siden glibc 2.7) 6 | SHA-512 (siden glibc 2.7)  

I dette tilfellet trenger du tre typer passordhash:

1. De gamle raske svake hashene
2. Den gamle raske svake hasjen som er pakket rundt en langsom hasj med et sterkt salt
3. Den nye langsomme hasjen.

På dag 1 vil jeg ta alt fra kategori 1 og flytte det til kategori 2. Nye passord vil bli satt inn i kategori 3. Videre, når folk logger inn, kan du til og med migrere alle vellykkede autentiserte hash fra kategori 2 til kategori 3 mens passordet for ren tekst er i minnet. På et tidspunkt kan du til og med fullstendig eliminere bevis / arv vedlikehold av den svake hashing-ordningen. (For eksempel å tvinge brukere med kontoer som ikke har logget på i over 2 år etter endringen til å tilbakestille passordene sine.)

Forslaget ditt 2 (ta den gamle hashverdien som "passord" for den nye hashen) er god hvis følgende forhold stemmer:

• gammel hash er tilstrekkelig motstandsdyktig mot forhåndsbilder.
• Den nye hashen bruker alle de nødvendige bells'n-fløytene for å betrakte den som "robust" (dvs. det er bcrypt med mange runder, og et nytt tilfeldig salt for hvert passord, inkludert for passordendringer for en gitt bruker).
• Den gamle hashen kan beregnes effektivt nok til at hele "konfigurerbar treghet" -virksomheten er avhengig av den nye hasjen eksklusivt.

Merk at MD5, selv om den er grundig ødelagt med hensyn til kollisjoner, fremdeles ser ut til å være rimelig sterk når det gjelder forhåndsbilder.

Det vil fortsatt tjene best for deg interesser for å inkludere et "type hash" -felt i databasen din, slik at migrasjoner kan håndteres greit. Du kan for eksempel bruke hash-of-hash, og deretter planlegge en overføring til en passordhashing-ordning som bare bruker den nye hash-passord vil bli oppdatert til den nye ordningen når de blir opprettet eller endret, for en gradvis migrasjon. Senere (si om ett år) kan du konfigurere en tvungen oppdatering (brukeren må oppgi passordet ved neste pålogging) for passordene som fremdeles bruker det gamle formatet.

Selv om du ikke liker migrasjoner ( hvem gjør det?), virker det bare forsvarlig å sørge for en mulig fremtidig migrasjon, hvis forholdene på det tidspunktet tvinger migrasjonen mot deg (f.eks. et ødeleggende kryptanalytisk brudd).

Jeg vil bruke bcrypt som den nye hashen. Ellers bør løsningen din med å "pakke inn" de gamle hasjene være sikre, gitt at du bruker et godt salt for for bcrypt. Jeg har sett denne løsningen fungere et par ganger når systemer vil oppgradere hvordan de hash passordene sine.

Hvis du ikke vil bry deg med å bruke den gamle hash-funksjonen, men ikke vil tvinge alle til å endre passordet ditt, er det en elegant løsning.

Legg til en kolonne / verdi i hver brukerprofil. La oss ringe hvis HashVersion

Når brukeren går for å logge på for første gang siden overføringen din, vil systemet da kunne oppdage at det bruker den gamle hash-funksjonen. Så hvis passordet som leveres av brukeren samsvarer med hash-en, tar du passordet i ren tekst og hash det med den nye algoritmen din, og tilbakestiller salter og så videre. Og så støter du HashVersion slik at du vet at den nå bruker den nye hash-funksjonen.

Dette er etter min mening den beste løsningen, spesielt hvis din forrige hash-funksjon var veldig usikker.

Så lenge den gamle hasjen er anstendig (MD5 eller DES-Crypt er greit, ikke CRC32), er denne tilnærmingen sikker. Bruk av det samme saltet bør heller ikke føre til problemer, forutsatt at saltet er godt nok, dvs. (nesten) globalt unikt.

For den ytre hashfunksjonen anbefaler jeg å bruke en av scrypt, bcrypt eller PBKDF2.

Du finner dusinvis av open source-applikasjoner som har løst dette problemet. Wordpress kommer raskt i tankene, men det er andre også. Selv Microsoft Windows bruker samme teknikk. Den generelle løsningen er denne:

• Utgangen for hver støttede hashfunksjon distribueres lett; enten ved å sjekke utgangsformatet eller lengden, eller (mer hensiktsmessig) ved å forhåndsstille en identifikatorstreng (f.eks. sha1: salt: _hash_output ____ ) eller ved å legge til et nytt felt i databasen for å identifisere hash-typen.
• Du fortsetter å støtte autentisering via alle tidligere brukte hashfunksjoner, men alle nye hashes sender bare den foretrukne versjonen.
• Eventuelt hvis en bruker er autentisert ved hjelp av en tidligere hash-versjon vil det autentiserte passordet bli hashatt på nytt ved hjelp av den foretrukne algoritmen, og den lagrede hash vil bli oppdatert.