11 komentářů k článku Změna hashování existujících hesel:

  1. suwer

    Predpokladam, ze ten druhy priklad s foreachem pro kazdy pruchod updatne vsechny zaznamy v tabulce, ktere jsou jeste null. Chtelo by to konkretni where parametr.

    1. Michal ŠpačekAutor příspěvku

      Re:
      Díky, u sebe na webu jsem to upravil. Já věděl že tam to varování o (ne)kopírování mám dát :-)

  2. David Grudl

    Titulek

    K rozhodnutí jak uživatele ověřit využijeme obsah sloupce type.
    Neprovádějte ověření hesla nejdřív pomocí nového hashe a pak, v
    případě selhání, pomocí starého. To je zbytečně pomalé, využijte
    raději ten sloupeček.

    Ono je to především nebezpečné. Protože vlastně může dojít k situaci, kdy místo heslem se půjde přihlásit i jeho hashí (např sha1, tedy pokud se nepoužívá salt), která být v nějaké uniklé databázi.

    1. Michal ŠpačekAutor příspěvku

      Re: Titulek
      Díky, dobrá poznámka. K takové situaci by došlo až při použití tohoto způsobu ověřování ve chvíli, kdy přidáme „vyčištění“ nového hashe, u toho „nového přes starý“ se to nestane. U sebe na webu jsem to doplnil a upravil, aby to bylo jasnější.

  3. Petr

    salt
    Nějak jsem nepochopil, proč se ukládá salt do nového sloupečku old_salt, když ten původní sloupeček salt máme k dispozici.

    1. Michal ŠpačekAutor příspěvku

      Re: salt
      Pokud již máte salt uložený odděleně tak není třeba ho dávat do jiného sloupečku.

      1. Michal ŠpačekAutor příspěvku

        Re: salt
        V článku je to mimochodem zmíněno nepřímo:

        Pokud váš starý hash používá unikátní salt pro každého uživatele (statický salt, stejný pro všechny uživatele, není salt), tak budete ještě potřebovat sloupeček, do kterého tento „starý“ salt uložíte, můžeme mu říkat třeba old_salt.

        Stačí si místo old_salt nahradit salt a zaradovat se, že už to vlastně máme hotové :-)

    2. FilipJirsak

      Re: salt
      Článek nepočítá s existencí sloupečku salt. Hashe hesel se do databáze často ukládají nestrukturovaně – „heslovací“ funkce vám vyplivne řetězec, kde je nějak (obvykle pomocí oddělovačů) zakódována použitá hashovací funkce, sůl a výsledný hash.

      Vychází to jednak evolučně z ukládání hesel v unixech, kde je pro heslo určená jedna položka v řádku, i položky na řádku jsou oddělené nějakým oddělovačem. Jednak je to primitivní na použití pro programátora, který nemusí přemýšlet nad strukturou databáze a prostě ukládá string. Z hlediska návrhu databáze je to špatně, protože se strukturovaná data ukládají nestrukturovaně, ale je to navržené pro masy s myšlenkou „nezabráníme tomu, aby programovala spousta lidí, kteří tomu moc nerozumí, tak jim alespoň dejme do ruky nástroj, který to udělá jakž takž správně a nebude tak snadné na jeho použití něco zkazit“.

  4. Vasek

    Nejdřív bych měl připomenout, co to vlastně takový na ukládání hesel
    nevhodný algoritmus je. Jsou to všechny ty MD5, SHA-1, SHA-2, SHA-3, a
    to v jakékoliv variantě. Se saltem („solí“), nebo bez, „zesílené“
    pomocí několika stovek tisíc iterací, nebo jen jedno volání, je to
    jedno.
    Mohl bych poprosit o detailnější objasnění, proč toto není vhodné či proč je to nebezpečné? Pravidelně totiž v PHP vytvářím hashe pro jiné programy, proto se musím držet jistých formátů, například SSHA256, …

Napsat komentář

Zdroj: https://www.zdrojak.cz/?p=20311