Kysymys:
Voiko kukaan antaa viitteitä verkkosovellusten itsesalasanan palautusmekanismien toteuttamiseksi oikein?
bdg
2011-01-28 04:39:03 UTC
view on stackexchange narkive permalink

Toteutamme itsesalasanan palauttamista verkkosovelluksessa, ja tiedän, miten haluan sen tehdä (sähköpostin aikarajoitettu salasanan palauttamisen URL-osoite käyttäjille, jotka ovat rekisteröityneet ennalta).

Minun ongelmani on, että en löydä viitteitä, joihin kehittäjät voisivat kohdistaa tekniikkaa. Voiko kukaan osoittaa minulle hyvien viitteiden suuntaan tähän tekniikkaan?

Mitä ohjelmointikieliä käytät?
Katso myös [vastaava kysymys] (http://stackoverflow.com/q/664673/10080) SO: lla.
Katso: [Unohtuiko salasana · OWASP-huijausselosarja] (https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html)
Kahdeksan vastused:
D.W.
2011-01-30 12:05:38 UTC
view on stackexchange narkive permalink

Joitakin ehdotuksia:

Älä nollaa käyttäjän salasanaa, ennen kuin se on vahvistettu. Älä nollaa käyttäjän salasanaa välittömästi. Nollaa se vasta, kun käyttäjä napsauttaa vahvistuslinkkiä, joka lähetetään ennalta rekisteröidylle sähköpostiosoitteelleen.

Vaadi CAPTCHA. Kun käyttäjä pyytää uuden salasanan, pakota hänet ratkaista CAPTCHA ennen jatkamista. Tämän tarkoituksena on estää automatisoituja työkaluja yrittämästä monille käyttäjille surua ja pakottaa käyttäjä todistamaan olevansa ihminen (ei robotti).

Satunnaisuus. Aikarajainen salasanan palauttamisen URL-osoitteen tulee sisältää satunnainen, arvaamaton komponentti. Varmista, että käytät salauksen laadun satunnaisuutta. Tulos / dev / urandom tai System.Security.Cryptography.RNGCryptoServiceProvider olisi hyvä valinta. rand () - tai random () - tai System.Random -lähde ei ole tarpeeksi satunnainen ja olisi huono valinta. GUID tai aikaleima ei ole tarpeeksi satunnainen, eikä se olisi hyvä valinta.

Sisällytä aikaraja. Nollausvahvistuslinkin pitäisi vanhentua kohtuullisen ajan kuluttua: esimerkiksi 24 tuntia . Linkin pitäisi olla käyttökelpoinen vain kerran, ja sen on oltava voimassa välittömästi sen käytön jälkeen.

Sisällytä selittävä teksti sähköpostiin. Haluat ehkä lisätä selittävää tekstiä sähköpostitse, miksi sähköposti lähetettiin, mikäli joku pyytää nollaamista tilille, joka ei ole sinun. Voit lisätä tekstiä, kuten "Joku on pyytänyt uuden salasanan vaihtamista tilisi käyttäjänimi kohtaan site . Jos teit tämän pyynnön, vaihda salasanasi napsauttamalla tätä. Jos et tehnyt tätä pyyntöä, peruuta pyyntö napsauttamalla tätä. "

Lähetä sähköpostia salasanan palauttamisen jälkeen. Kun salasana on palautettu onnistuneesti, lähetä sähköposti käyttäjälle osoitteeseen kerro heille, että salasana on vaihdettu. Älä sisällytä uutta salasanaa kyseiseen sähköpostiin.

Tarkkaile peruutuksia. Voit harkita jonkin verran logiikkaa seurataksesi, kuinka usein käyttäjät napsauttavat peruutuslinkkiä osoittaen, että he eivät pyytäneet nollausta. Jos tämä ylittää tietyn kynnysarvon, voi olla hyödyllistä lähettää hälytys verkko-operaattoreille. Lisäksi jos jonkin pyynnön peruutuslinkissä käydään sen jälkeen, kun vahvistuslinkissä on vierailu, se on potentiaalinen osoitus hyökkäyksestä kyseistä käyttäjää vastaan ​​- saatat haluta ryhtyä toimiin siinä vaiheessa, esimerkiksi mitätöidä käyttäjän salasanan ja vaatia heitä vaihtamaan salasanansa uudelleen. (Tämä on suojaus seuraavaa hyökkäystä vastaan: hyökkääjä saa pääsyn käyttäjän postilaatikkoon, pyytää sitten salasanan vaihtamista sivustollasi ja vierailee vahvistuslinkkiä. Jos hyökkääjä ei poista näitä sähköposteja käyttäjän postilaatikosta, sitten, kun todellinen käyttäjä lukee sähköpostinsa, hän voi napsauttaa peruutuslinkkiä, mikä antaa sinulle mahdolliset ongelmat.)

Käytä HTTPS: ää. Linkin tulisi käyttää https: ää (ei http :), suojautumaan erilaisilta hyökkäyksiltä (esim. Firesheep-hyökkäykset käyttäjille, jotka surffaavat verkossa Internet-kahvilasta).

Kirjaa nämä toiminnot. Ehdotan, että kaikki tällaiset pyynnöt kirjataan. Käyttäjätunnuksen kirjaamisen lisäksi sinun on ehkä kirjattava sen asiakkaan IP-osoite, joka on pyytänyt nollauslinkkiä sähköpostitse käyttäjälle, sekä nollauslinkissä vierailleen asiakkaan IP-osoite.

Lisälukemista. Voit myös lukea Troy Huntin erinomaisen blogikirjoituksen, Kaikki mitä olet koskaan halunnut tietää suojatun salasanan palautusominaisuuden rakentamisesta. Kiitos @coryT linkistä tähän resurssiin.

Lopuksi ota huomioon muu kuin salasanan todennus. Salasanoilla on monia ongelmia todennusmekanismina, ja saatat harkita muita tapoja todentaa käyttäjiä, kuten suojatun pysyvän evästeen tallentaminen koneelle, jota ei voi arvata. salaisuus niiden todentamiseksi. Tällä tavoin ei ole salasanaa, jota unohtaa, eikä käyttäjän tietojenkalastelua, vaikka sinun on tarjottava tapa, jolla käyttäjä voi valtuuttaa pääsyn uudelta koneelta tai uudelta selaimelta (mahdollisesti sähköpostitse käyttäjän esiasetukseen). rekisteröity sähköpostiosoite). Tässä kyselyasiakirjassa on erinomainen tutkimus monista varautumismenetelmistä sekä niiden vahvuuksista ja heikkouksista.

+1, huomaa myös, että vaikka se onkin suosittu (kuten useimmat väärät vastaukset osoittavat [tästä SO-kysymyksestä] (http://stackoverflow.com/q/664673/10080)), GUID ei * ole * tarpeeksi satunnainen . Lisään myös vain kuristusmekanismin, ts. Käyttäjä ei voi pyytää salasanan vaihtamista esim. 3000 kertaa tunnissa.
Yhteenvetona keskustelustani @avid: n kanssa hänen vastauksessaan tähän kysymykseen sanoisin, että version 4 GUID on todellakin enimmäkseen satunnainen, ja [luulisin, että se on riittävän pitkä] (http://security.stackexchange.com/questions/ 1952 / kuinka kauan-satunnaisen-ei-olla-pitäisi olla). Mutta se on todennäköisesti typerä ja vähän vaarallinen käyttää, koska sitä ei ole alun perin suunniteltu tehtävään. Ja kuka tietää missä koodisi siirretään seuraavaksi?
Näyttää siltä, ​​että "jos et tehnyt tätä pyyntöä, peruuta pyyntö napsauttamalla tätä."
@nealmcb Tässä on linkki kaverin C # kääntäjätiimissä olevalta kaverilta, joka puhuu GUID-tunnuksista ja jossa erittäin voimakkaasti mainitaan, että GUID-tunnukset eivät ole millään tavalla salauksellisesti satunnaisia: http://blogs.msdn.com/b/ericlippert/archive/2012/05 /07/guid-guide-part-three.aspx - siellä oli toinen tutkimus, joka osoittaa, että Windows GUID: t eivät ole kryptografisesti satunnaisia: http://www.gotdotnet.ru/blogs/denish/1965/ - Bottom Line: Don't käytä GUID: itä salaustarkoituksiin :) (En tiedä, takaako jokin muu kuin Windows-käyttöjärjestelmä tältä osin takuita, mutta Unices-laitteilla on yleensä sekä / dev / random että / dev / urandom)
Kuinka monta merkkiä satunnaisen osan tulisi olla?
"Älä sisällytä uutta salasanaa kyseiseen sähköpostiin." Jos käyttäjän salasana on selkeässä tekstissä, teet sen väärin.
AilisvvkqlCMT 64-80 bits should be plenty for the random part. (40 bits would actually probably be enough for this purpose, but why take any chances?)
@DavidMurdoch Katso yllä julkaisemastani linkistä lisätietoja D.W.: n vastauksesta (ts. Että 64 bitin nonce on todennäköisesti hieno tähän tarkoitukseen): [Kuinka kauan satunnaisen noncesin pitäisi olla? - IT-turvallisuus] (http://security.stackexchange.com/questions/1952/how-long-should-a-random-nonce-be)
AilikofnzoCMT Thanks for the links, and as I said it is a bad choice. But in terms of assessing the actual risk, Google translate didn't help much with that russian post by Nikolay Denishchenko on something like "Device and cryptanalysis UUID-Generator for Windows". Can you summarize the results in terms of how many unpredictable bits of entropy he thinks Windows version 4 GUIDs have, and how hard it would be to guess them remotely?
coryT
2012-07-20 02:11:58 UTC
view on stackexchange narkive permalink

Troy Huntilla on erittäin hieno kirjoitus tähän tarkkaan kysymykseen. Kaikki mitä olet koskaan halunnut tietää suojatun salasanan palautusominaisuuden rakentamisesta

troy-blogi on loistava resurssi kaikille verkkoturvallisuuteen liittyville asioille
Jesper Mortensen
2011-04-05 14:25:56 UTC
view on stackexchange narkive permalink

OK, joten kysymyksesi on, miten sinun tulisi jäsentää salasanan / tilin palautusprosessi? Tämä riippuu siitä, mihin haluat optimoida: vaivaton käyttökokemus tai hyvä suojaus.

Jos haluat hyvää suojausta:

  • Rekisteröitymisen aikana käyttäjän on annettava sähköpostiosoitteensa.

  • Rekisteröitymisen aikana käyttäjän on syötettävä todentamista varten toissijainen kanava - matkapuhelinnumero tai haastekysymys & vastaus (ts. " mitä äitisi tyttönimi "tai parempi).

  • Palautuksen aikana järjestelmäsi tarkistaa ensin karkeasti henkilöllisyyden yllä olevan toissijaisen kanavan avulla - haaste kysymys, tai lähettämällä koodi matkapuhelimelle tekstiviestillä tai vastaavalla.

  • Kun ensimmäinen yllä oleva henkilöllisyystarkistus on poistettu, järjestelmä lähettää salasanan palautussähköpostin vain aiemmin syötettyyn sähköpostiosoitteeseen . Tämä on tärkeä, tärkeä toimenpide estämään f.x. Sarah Palin -tyyppi hyödyntää.

  • Sähköposti ei saa sisältää uutta salasanaa tai vastaavaa. Sillä tulisi olla napsautettava linkki sivustosi HTTPS-salattuun verkkosivuun, joka a) on linkitetty tiliin URL-osoitteessa olevan arvattoman arvattoman salaisen arvon kautta, b) on ajallisesti rajoitettu, joten tilin palautus toimii vain x tuntia sen jälkeen, kun sitä on pyydetty. c) tarjoaa loppukäyttäjälle tavan luoda uusi salasana.

  • Kirjaa kaikki tilin palautustapahtumat hyvin ja pyydä ihmistä tosiasiallisesti seuraamaan niitä ja toimimaan, jos ne näyttävät epäilyttäviltä (katso IP-osoitteiden palvelinlokit fx, tee monet pyynnöt tulevat samalta IP-osoitteelta, onko tapauksia, joissa käyttäjä yrittää nollata salasanoja muusta maasta kuin rekisteröidyn tilin omistaja jne.).

Voit myös ohittaa tämän monimutkaisuuden kokonaan: On vielä alkuaikoja, mutta OAuth / OpenID / kirjaudu sisään Facebookin, Googlen jne. kautta poistaa tämän monimutkaisuuden kokonaan järjestelmistäsi, mutta ehkä vähemmän vakiintunut käytettävyys.

Challenge questions are the opposite of security.
AilirypmooCMT can you provide a reference that discusses this? I'd like to read more on it.
@David Murdoch: Haastekysymykset vastaavat salasanaa - mutta keskeinen kysymys on mikä. Minun järjestelmässä he avaavat salasanan palautusmekanismin, joka (oletettavasti) * ei ole hyökkääjien hallinnassa *; alkuperäinen sähköpostiosoite. Mutta totta, salasanan palautusmekanismit yleensä myyvät turvallisuutta parantamaan käytettävyyttä, ehkä minun olisi pitänyt tehdä siitä selvempi.
Huomaa, että täällä vuoden 2015 häikäisevässä tulevaisuuden maailmassa puhelinnumeron käyttö osana MFA-järjestelmää on eräänlainen hajonnut, koska sama pieni kadonnut laite toimii yhdyskäytävänä sekä sähköpostiin että tekstiviesteihin.
Rich Homolka
2012-07-23 22:18:52 UTC
view on stackexchange narkive permalink

Mikä tahansa paikka, joka voi lähettää sinulle salasanan, tarkoittaa, että he eivät hajauta salasanaa, mutta tallentavat sen paikkaan, joka on jotenkin purettavissa salaiseen tekstiin. Tämä itsessään on huono.

Ei todennäköisesti "kaikkein turvallisin", mutta turvallisempi olisi:

Lähetä salasanan pyytämisen yhteydessä salasanan palautuslinkki käyttäjälle upotetulla GUID-tunnuksella. Istunto GUID: ssä vanhenee, hmm, tunti tai niin.

Joo ei mitään ongelmia, koska istunto on suojattu SQL-injektiolta, joten lähetän postia hyvin satunnaistetulla salasanan palauttamisistunnolla ja annan tunnin vaihtaa sitä, se on OK.
AilifojylvCMT - You should allow the user to select the new password not send it to them, as already explained, if your able to send the password to the user there is something broken about your security model.
This website currently generates a NEW password, sends by email, hash it and store in db, which is not good I believe.
generating a password and not expiring it on next connection is indeed a bad idea.
Jos tämä GUID on pelkkää tekstiä, se voidaan saada sql-injektiolla ja sitten voitat salasanan hajautuksen koko tarkoituksen. Tämä viesti on vaarallinen ehdotus epäselvyyden avulla.
Joten minun pitäisi salata hyvin satunnaistettu salasanan palauttaminen istuntokoodi ja 1 tunnin ikkunassa sen jälkeen sallia muutos - ei hätää.
Rory Alsop
2011-01-31 01:58:25 UTC
view on stackexchange narkive permalink

Toinen, joka saattaa olla sopiva sovelluksellesi tai ei, mutta jota käytetään verkkopankkisovelluksissa ja vastaavissa asioissa, on lähettää puolet nollauskoodista tekstiviestinä rekisteröityyn matkapuhelimeen. Hyökkääjän näkökulmasta tämä on täydellinen PITA, koska se vaatii parin kanavan kompromissin murtamiseksi.

Polynomial
2012-07-24 01:31:29 UTC
view on stackexchange narkive permalink

Turvallisin tapa suorittaa salasanan palautus on luoda suuri satunnainen yksilöllinen kertaluonteinen palautustunnus, jonka viimeinen käyttöpäivä on sidottu käyttäjätunnukseen. Tunnus tulisi hajauttaa tietokantaan, koska SQL-käyttöoikeuden omaava hyökkääjä voi käyttää sitä mielivaltaisten käyttäjän salasanojen nollaamiseen.

Palautuslinkki tulisi lähettää sähköpostiosoitteeseen, joka sisältää palautustunnuksen. Kun käyttäjä napsauttaa linkkiä, tunnuksen hash pitäisi löytyä tietokannasta, ja viimeisen käyttöpäivän olisi oltava tulevaisuudessa. Jos nämä ehdot täyttyvät, käyttäjälle tulisi antaa näyttö, joka antaa uuden salasanan kirjoittaa.

Koko tämä prosessi täytyy suorittaa SSL: n kautta, muuten hyökkääjä saattaa haistaa URL-osoitteen ja nollata salasanan ennen kuin käyttäjä tekee.

Muutamia muita vinkkejä:

  1. Salaiset kysymykset aiheuttavat vähäistä ärsytystä hyökkääjille ja suurta ärsytystä käyttäjille. Vältä niitä kokonaan.
  2. Esitä käyttäjälle ihmisen vahvistushaaste (esim. CAPTCHA) ennen salasanan palauttamista. Tämä estää automaattisia palautuspyyntöjä.
  3. Tarkista, onko palautuksen suorittava IP-osoite onnistuneesti kirjautunut tilille aiemmin. Jos se ei ole, kysy lisätietoja tilistä / käyttäjästä, esim. tilin luomisvuosi, syntymäpäivä, ensimmäinen osoiterivi.
  4. Lisää "En pyytänyt tätä sähköpostia" -linkki, jotta käyttäjät voivat ilmoittaa virheellisistä salasanan palautuspyynnöistä.
    5. ol >
Even if it is generated via SSL: you have no insurance that the e-mail itself is transferred over SSL and so this method has a huge flaw in transit -- the basic flaw of e-mail relay and retrieval.
AiligfqwkiCMT "_the basic flaw of e-mail relay and **retrieval**._" regarding email **retrieval**: it is the responsibility of the user to use an email recovery address from an email provider with POPS, IMAPS, or HTTPS webmail support (and most email providers offer all three nowadays).
@EvanCarroll Vaikka se ei ole ihanteellinen tilanne, turvallisuus on aina * toissijainen käytettävyyden kannalta. Jos otat käyttöön maailman turvallisimman selaimen sisäänkirjautumisen, mutta se vaatii JavaScriptin, Flashin, Java: n, ActiveX: n, Silverlightin ja tietojenkäsittelytieteen tutkinnon, käyttäjät sammuvat. Sähköposti on tosiasiallisesti standardi tällaiselle toiminnalle, lähinnä siksi, että sitä voivat käyttää kaikki. Käyttäjän sähköpostijärjestelmän ja henkilökohtaisen verkon turvallisuustaakka ei * ole * minun kanssani, eikä sen pitäisi olla.
@curiousguy, jos tavoitteesi on uskottava kiistettävyys, niin kyllä. Jos tavoitteesi on turvallisuus, niin ei.
@polynomial: n "tosiasiallisilla" standardeilla ei ole mitään tekemistä turvallisuuden kanssa. Se on vain argumentti säilyttää nykyinen tilanne tietämättömänä turvallisuusvaikutuksista.
AilibpxohpCMT The argument for the status quo is that there is no acceptable alternative.
Olen samaa mieltä vastauksestasi, mutta miksi sisällytät käyttäjätunnuksen linkkiin? Jos esimerkiksi tämä käyttäjätunnus on 8 merkin numero, nämä 8 merkkiä on yhtä helppo arvata kuin 8 ylimääräistä satunnaista merkkiä tunnuksessasi. Satunnaisilla merkeillä et kuitenkaan paljasta käyttäjätunnusta.
@martinstoeckli True, mutta käyttäjätunnuksen paljastaminen ei yleensä ole iso juttu. Todennäköisesti teet sen joka tapauksessa sivustosi käyttöliittymän kautta - katso StackExchange. Kysymys 17542, vastaus 17547, kommenttisi on 28508, olet käyttäjä 8343, olen käyttäjä 5400, OP on käyttäjä 10787. Yritetään piilottaa, että tieto on vaikeaa ja tuo vain hämäryyttä. Tässä tapauksessa tunnusten tulisi kuitenkin olla yksilöllisiä, joten haun tulisi aina palauttaa yksi rivi riippumatta siitä, onko käyttäjätunnus linkissä.
frank
2011-04-06 10:36:01 UTC
view on stackexchange narkive permalink

Kaksivaiheinen todennus tekstiviestillä! 1 tunnet asiakkaan ja hänen matkapuhelinnumeronsa, lähetä tekstiviesti heille yksilöllinen koodi, joka lisätään verkkosivustoon sen vahvistamiseksi, että he ovat he :)

Se ei välttämättä ole 2-tekijäinen ratkaisu, mutta se on bändin ulkopuolella.
Kunnes joku varastaa puhelimensa.
Andrzej Bobak
2012-07-24 19:28:06 UTC
view on stackexchange narkive permalink

Tee siitä muutama vaihe. Esimerkiksi jotain tällaista:

  1. Käyttäjä unohti salasanansa. Hän napsauttaa "Unohdin salasanani, lähetä minulle sähköpostia, mitä tehdä seuraavaksi" -painiketta (painikkeen nimi voi vaihdella;))
  2. Palvelimesi lähettää hänelle linkin www.omaverkkotunnus.com/lostpassword?param_1 = x; param_2 = y
  3. Hän napsauttaa linkkiä ja voi luoda itselleen uuden salasanan.
  4. Hän napsauttaa Lähetä. Kaikki tehty. Kaikki onnellisia

Yksi ja ainoa saalis on kohdassa 3). X- ja Y-arvojen tulisi olla satunnaisia, arvaamattomia ja yhdistetty tähän tiettyyn tiliin. Niiden tulisi olla myös vain kertakäyttöisiä ja niiden tulisi olla vanhentuneita lyhyen ajan kuluttua (24 tuntia?). Tallenna molemmat arvot erilliseen taulukkoon vastaavilla sarakkeilla: 

  | jotkut_id | käyttäjän_tunnus | X | Y | expire_time

Jos käyttäjä yrittää käyttää oikeaa linkkiä, tarkista, onko vanhentumisaika täyttymättä, ja jos ei, anna hänen vaihtaa salasana.

Kuinka tämä eroaa muista vastauksista? Ei ole hyötyä siitä, että sinulla on sekä X että Y, käytä vain yhtä satunnaisarvoa.
Selvä siisti, mutta kuinka se on turvallinen SQL-injektiota vastaan? Onko se omistetun pöydän takia?
@Polynominal: n yksi arvo on helppo rikkoa raa'an voimahyökkäyksen avulla.
AililhuxbzCMT you prevent yourself from an sql injection in a complete different way. It's how you filter user input and how you pass it to your queries.
@AndrzejBobak: Kaksi arvoa on yhtä helppo murtaa raa'an voiman läpi kuin yksi arvo kaksinkertaistaa jommankumman pituuden.


ⓘ
Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 2.0-lisenssistä, jolla sitä jaetaan.
Loading...