Sähköpostiviesti salasanasta todistaa palautuvuuden, ei skeemaa

Palvelu, joka lähettää käyttäjän nykyisen salasanan sähköpostitse, on todistanut yhden asian: se pystyy hankkimaan tämän salaisuuden muodossa, jonka se voi lähettää. Se ei ole todistanut, mikä sarake, algoritmi tai kirjasto sen tuotti. Ero on tärkeä, koska havainto on todellinen ja siitä tehty johtopäätös on yleensä liian täsmällinen. Palautuvuus jossakin polun kohdassa on mekanismi; arvattu tallennusmuoto ei ole.

Pidä todisteet sillä tasolla, niin muukin arvio pysyy paikkansa pitävänä.

Mitä vanhan salaisuuden palauttaminen todistaa

Yksisuuntainen vahvistin ei voi tuottaa alkuperäistä salasanaa, koska se suunniteltiin ei-käännettäväksi. Jos palvelu voi lähettää salasanan sähköpostitse, se pitää sillä hetkellä hallussaan aineistoa, josta salasana voidaan palauttaa, tai se sieppaa ja tallentaa selkokielisen tekstin ennen tiivistystä. Kummassakin tapauksessa palautuspolku on palautuva, ja se on todellinen tietoturvahavainto. Se ei kerro mitään siitä, käyttääkö sama tietokanta kalliisti laskettua tiivistettä muille sarakkeille.

Kiinnitä huomiota myös välikoitapaukseen: sovelluksen hallussa olevalla avaimella tallennettu salattu blob on käytännössä palautuva, vaikka sana salattu kuulostaa raportissa rauhoittavalta.

Miksi tämä on suunnitteluhavainto eikä tallennuskartta

Sähköposti todistaa palautettavuuden eikä yksilöi tarkkaa skeemaa. Se voi olla selkokielistä tekstiä, determinististä salausta, toimittajan hämärtämisrutiini tai erillinen tunnistetietovarasto, jota käytetään vain palautukseen. Tuotteen eri osat käyttävät usein eri tallennusta. Algoritmin määrittäminen yhden sähköpostin perusteella on väite, joka romahtaa jatkokokouksessa.

Se mitä voit sanoa, on kapeampaa ja hyödyllisempää: tämä polku voi palauttaa salaisuuden, joten tuote ei voi väittää, ettei palautettavia tunnistetietoja ole. Kaikki muu vaatii operaattorin todisteet.

Rakenna nollaus valtuutuksen ympärille

Nollaus ratkaisee toisen ongelman: sen todistamisen, että pyytäjä saa valita uuden salasanan. OWASPin ohjeistus tähän kuvaa turvallisesti luotuja kertakäyttöisiä tokeneita tai koodeja sopivalla vanhenemisajalla ja kohtelee pyyntövaihetta asiana, joka on suojattava luetteloinnilta ja tulvalta. Todentamaton pyyntö ei saa muuttaa tiliä itsessään. Vahvista valtuutus ennen korvaavan salasanan hyväksymistä ja tee tokenista käyttökelvoton yhden onnistuneen käytön jälkeen.

Sähköpostikanava on osa turvamallia. Tilinnimen hallussapito ei todista mitään, ja nollausvirta, joka paljastaa onko tili olemassa, antaa hyökkääjälle hakemiston, jonka varassa työskennellä.

Mitätöi se, mitä salasana suojasi

Salasanan vaihtaminen ei automaattisesti lopeta sen myöntämää pääsyä. Aktiivisilla VPN-istunnoilla, muistetuilla laitteilla ja palvelimen myöntämillä tokeneilla voi kullakin olla oma mitätöintikäyttäytymisensä. Päätä tietoisesti, mitkä niistä on lopetettava, ja varmista, että toteutus tekee niin, koska käyttäjä, joka olettaa nollauksen kirjanneen hänet ulos kaikkialta, on usein väärässä. Kirjaa tämä päätös virran yhteyteen.

Operaattoreille: dokumentoi, mikä komponentti vahvistaa pyynnön, mikä muuttaa tunnistetietoa ja miten liittyviä istuntoja käsitellään. Käyttäjille: suojaa laillinen palautuskanava ja kohtele jokaista viestiä, joka palauttaa salasanan, epäilyttävänä.

Tarkka arvio on lyhyt: mitä viesti todistaa, mikä jää tuntemattomaksi ja korvaako palautus pääsyn hallitun prosessin kautta.