Minulla oli äskettäin aikaa miettiä uudelleen, kuinka turvallisen salasanan palautusominaisuuden pitäisi toimia, ensin kun rakensin tätä toimintoa , ja sitten kun hän auttoi toista henkilöä tekemään jotain vastaavaa. Toisessa tapauksessa halusin antaa hänelle linkin kanoniseen resurssiin, jossa on kaikki yksityiskohdat palautustoiminnon turvallisesta toteuttamisesta. Ongelmana on kuitenkin se, että sellaista resurssia ei ole olemassa, ainakaan sellaista, joka kuvaa kaikkea, mikä minusta tuntuu tärkeältä. Joten päätin kirjoittaa sen itse.
Unohdettujen salasanojen maailma on itse asiassa melko mystinen. On olemassa monia erilaisia, täysin hyväksyttäviä näkökulmia ja monia melko vaarallisia. Olet todennäköisesti kohdannut jokaisen niistä monta kertaa loppukäyttäjänä; joten yritän näiden esimerkkien avulla näyttää, kuka tekee sen oikein, kuka ei ja mihin sinun on keskityttävä saadaksesi ominaisuuden oikein sovellukseesi.
Salasanan tallennus: hajautus, salaus ja (haukkua!) pelkkä teksti
Emme voi keskustella siitä, mitä tehdä unohdetuille salasanoille, ennen kuin keskustelemme niiden tallentamisesta. Salasanat tallennetaan tietokantaan jollakin kolmesta päätyypistä:
- Yksinkertaista tekstiä. Siellä on salasanasarake, joka on tallennettu tekstimuodossa.
- Salattu. Tyypillisesti käytetään symmetristä salausta (yhtä avainta käytetään sekä salaukseen että salauksen purkamiseen), ja myös salatut salasanat tallennetaan samaan sarakkeeseen.
- Tiivistetty. Yksisuuntainen prosessi (salasana voidaan tiivistää, mutta sitä ei voida poistaa); Salasana, haluaisin toivoa, jota seuraa suola, ja jokainen on omassa sarakkeessaan.
Siirrytään suoraan yksinkertaisimpaan kysymykseen: Älä koskaan säilytä salasanoja pelkkänä tekstinä! Ei koskaan. Yksi haavoittuvuus , yksi huolimaton varmuuskopio tai yksi kymmenistä muista yksinkertaisista virheistä - ja siinä kaikki, gameover, kaikki salasanasi - eli anteeksi, kaikkien asiakkaidesi salasanat tulee julkiseksi. Tietenkin tämä tarkoittaisi suurta todennäköisyyttä kaikista tileistään muissa järjestelmissä. Ja se on sinun syytäsi.
Salaus on parempi, mutta siinä on heikkoutensa. Salauksen ongelma on salauksen purkaminen; Voimme ottaa nämä hullun näköiset salaukset ja muuntaa ne takaisin tavalliseksi tekstiksi, ja kun se tapahtuu, palaamme ihmisen luettavaan salasanatilanteeseen. Miten tämä tapahtuu? Pieni virhe tulee koodiin, joka purkaa salasanan ja tekee sen julkisesti saatavilla - tämä on yksi tapa. Hakkerit pääsevät koneeseen, jolle salattuja tietoja on tallennettu – tämä on toinen tapa. Toinen tapa on jälleen varastaa tietokannan varmuuskopio ja joku saa myös salausavaimen, joka on usein erittäin epäturvallisesti tallennettu.
Ja tämä vie meidät tiivistykseen. Hajautusajatus on, että se on yksisuuntainen; Ainoa tapa verrata käyttäjän syöttämää salasanaa sen hajautusversioon on tiivistää syöte ja vertailla niitä. Estääksemme sateenkaaripöytien kaltaisten työkalujen hyökkäykset suolaamme prosessin satunnaisesti (lue minun kryptografisesta tallennustilasta). Loppujen lopuksi voimme olla varmoja, että tiivistetyistä salasanoista ei tule enää koskaan pelkkää tekstiä, jos ne toteutetaan oikein (puhun eri hajautusalgoritmien eduista toisessa viestissä).
Nopea argumentti hajauttamisesta vs. salauksesta: Ainoa syy, miksi sinun on koskaan salattava salasana hajautusasetuksen sijaan, on se, että sinun täytyy nähdä salasana pelkkänä tekstinä ja sinun ei pitäisi koskaan haluta tätä, ainakin tavallisessa verkkosivustotilanteessa. Jos tarvitset tätä, teet todennäköisesti jotain väärin!
Varoitus!
Alla postauksen tekstissä on osa kuvakaappausta pornografisesta verkkosivustosta AlotPorn. Se on siististi leikattu, joten rannalla ei ole mitään, mitä et näe, mutta jos se silti todennäköisesti aiheuttaa ongelmia, älä vieritä alas.
Palauta aina salasanasi ei koskaan älä muistuta häntä
Onko sinua koskaan pyydetty luomaan funktio muistutuksia Salasana? Ota askel taaksepäin ja ajattele tätä pyyntöä käänteisesti: miksi tämä "muistutus" on tarpeen? Koska käyttäjä on unohtanut salasanan. Mitä me todella haluamme tehdä? Auta häntä kirjautumaan uudelleen.
Ymmärrän, että sanaa "muistutus" käytetään (usein) puhekielessä, mutta yritämme todella tehdä auttaa käyttäjää olemaan jälleen verkossa turvallisesti. Koska tarvitsemme turvallisuutta, on kaksi syytä, miksi muistutus (eli salasanan lähettäminen käyttäjälle) ei ole sopiva:
- Sähköposti on turvaton kanava. Aivan kuten emme lähettäisi mitään arkaluontoista HTTP:n kautta (käyttäisimme HTTPS:ää), meidän ei pitäisi lähettää mitään arkaluontoista sähköpostin kautta, koska sen kuljetuskerros on turvaton. Itse asiassa tämä on paljon pahempaa kuin pelkkä tietojen lähettäminen suojaamattoman siirtoprotokollan kautta, koska sähköpostit tallennetaan usein tallennuslaitteeseen, järjestelmänvalvojien käytettävissä, välitetään ja jaetaan, haittaohjelmien käytettävissä ja niin edelleen. Salaamaton sähköposti on erittäin turvaton kanava.
- Sinulla ei kuitenkaan pitäisi olla pääsyä salasanaan. Lue uudelleen edellinen tallennusta koskeva osio - sinulla pitäisi olla salasanan tiiviste (hyvällä vahvalla suolalla), mikä tarkoittaa, että et voi millään tavalla purkaa salasanaa ja lähettää sitä postitse.
Haluan osoittaa ongelman esimerkillä : Tässä on tyypillinen kirjautumissivu:
Ilmeisesti ensimmäinen ongelma on, että kirjautumissivu ei lataudu HTTPS:n kautta, mutta sivusto kehottaa myös lähettämään salasanan ("Lähetä salasana"). Tämä saattaa olla esimerkki yllä mainitun termin puhekielestä, joten mennään vielä askeleen pidemmälle ja katsotaan mitä tapahtuu:
Se ei valitettavasti näytä paljon paremmalta; ja sähköposti vahvistaa, että ongelma on olemassa:
Tämä kertoo meille kaksi tärkeää usoutdoor.comin näkökohtaa:
- Sivusto ei hajauta salasanoja. Parhaimmillaan ne on salattu, mutta on todennäköistä, että ne on tallennettu pelkkänä tekstinä; Emme näe todisteita päinvastaisesta.
- Sivusto lähettää pitkäaikaisen salasanan (voimme palata takaisin ja käyttää sitä yhä uudelleen) suojaamattoman kanavan kautta.
Kun tämä on poissa tieltä, meidän on tarkistettava, onko nollausprosessi tehty turvallisesti. Ensimmäinen askel tämän tekemiseksi on varmistaa, että pyytäjällä on oikeus suorittaa nollaus. Toisin sanoen ennen tätä tarvitsemme henkilöllisyyden tarkistuksen; Katsotaanpa, mitä tapahtuu, kun henkilöllisyys vahvistetaan varmistamatta ensin, että pyynnön esittäjä on todella tilin omistaja.
Käyttäjänimien luettelointi ja sen vaikutus nimettömyyteen
Tämä ongelma havainnollistetaan parhaiten visuaalisesti. Ongelma:
Näetkö? Kiinnitä huomiota viestiin "Tällä sähköpostiosoitteella ei ole rekisteröityä käyttäjää." Ongelma ilmeisesti syntyy, jos tällainen sivusto vahvistaa saatavuus käyttäjä on rekisteröitynyt kyseisellä sähköpostiosoitteella. Bingo – löysit juuri aviomiehesi/pomosi/naapurisi pornofetissin!
Porno on tietysti melko ikoninen esimerkki yksityisyyden tärkeydestä, mutta identiteetin liittämisestä tiettyyn verkkosivustoon liittyvät vaarat ovat paljon laajempia kuin yllä kuvattu mahdollisesti hankala tilanne. Yksi vaara on sosiaalinen suunnittelu; Jos hyökkääjä pystyy yhdistämään henkilön palveluun, hänellä on tietoja, joita hän voi alkaa käyttää. Hän voi esimerkiksi ottaa yhteyttä henkilöön, joka esiintyy verkkosivuston edustajana ja pyytää lisätietoja yrittäessään sitoutua .
Tällaiset käytännöt lisäävät myös "käyttäjätunnusten luetteloimisen" vaaraa, jolloin voidaan varmistaa koko kokoelma käyttäjätunnuksia tai sähköpostiosoitteita verkkosivustolla tekemällä ryhmäkyselyitä ja tutkimalla niihin annettuja vastauksia. Onko sinulla luettelo kaikkien työntekijöiden sähköpostiosoitteista ja muutama minuutti aikaa käsikirjoituksen kirjoittamiseen? Sitten näet, mikä ongelma on!
Mikä on vaihtoehto? Itse asiassa se on melko yksinkertainen, ja se on upeasti toteutettu :
Tässä Entropay ei paljasta mitään sähköpostiosoitteen olemassaolosta järjestelmässään jollekin, joka ei omista tätä osoitetta... Jos sinä oma tämä osoite ja sitä ei ole järjestelmässä, saat seuraavanlaisen sähköpostin:
Tietysti voi olla hyväksyttäviä tilanteita, joissa joku ajatteleeettä olet rekisteröitynyt sivustolle. mutta näin ei ole, tai tein sen toisesta sähköpostiosoitteesta. Yllä oleva esimerkki käsittelee molemmat tilanteet hyvin. Ilmeisesti, jos osoite täsmää, saat sähköpostin, joka helpottaa salasanan vaihtamista.
Entropayn valitseman ratkaisun hienovaraisuus on, että tunnistetodentaminen suoritetaan sen mukaan sähköposti ennen online-tarkistusta. Jotkut sivustot pyytävät käyttäjiltä vastausta turvakysymykseen (lisätietoja alla) до kuinka nollaus voi alkaa; Ongelmana tässä on kuitenkin se, että sinun on vastattava kysymykseen samalla, kun annat jonkinlaisen tunnisteen (sähköpostiosoite tai käyttäjätunnus), mikä tekee lähes mahdottomaksi vastata intuitiivisesti paljastamatta anonyymin käyttäjän tilin olemassaoloa.
Tällä lähestymistavalla on pieni heikentynyt käytettävyys, koska jos yrität nollata olemattoman tilin, välitöntä palautetta ei tule. Tietysti se on sähköpostin lähettämisen tarkoitus, mutta todellisen loppukäyttäjän näkökulmasta, jos hän syöttää väärän osoitteen, hän tietää ensimmäisen kerran vasta, kun he saavat sähköpostin. Tämä saattaa aiheuttaa hänelle jännitteitä, mutta tämä on pieni hinta maksettavaksi niin harvinaisesta prosessista.
Toinen huomautus, hieman aiheen vierestä: sisäänkirjautumisen aputoiminnoilla, jotka paljastavat, onko käyttäjätunnus tai sähköpostiosoite oikein, on sama ongelma. Vastaa aina käyttäjälle "Käyttäjätunnuksesi ja salasanasi yhdistelmä on virheellinen" -viestillä sen sijaan, että vahvistaisit nimenomaisesti tunnistetietojen olemassaolon (esimerkiksi "käyttäjätunnus on oikein, mutta salasana on väärä").
Nollaussalasanan lähettäminen vs. nollaus-URL-osoitteen lähettäminen
Seuraava käsite, josta meidän on keskusteltava, on salasanasi nollaus. On olemassa kaksi suosittua ratkaisua:
- Luo uusi salasana palvelimelle ja lähetä se sähköpostitse
- Lähetä sähköpostilla yksilöllinen URL-osoite helpottaaksesi nollausprosessia
Huolimatta , ensimmäistä kohtaa ei tule koskaan käyttää. Ongelma tässä on, että se tarkoittaa, että on olemassa tallennettu salasana, johon voit palata ja käyttää sitä uudelleen milloin tahansa; se lähetettiin suojaamattoman kanavan kautta ja pysyy postilaatikossasi. On mahdollista, että postilaatikot synkronoidaan mobiililaitteiden ja sähköpostiohjelman välillä, ja ne voivat säilyä verkossa verkkosähköpostipalvelussa erittäin pitkään. Pointti on siinä postilaatikkoa ei voida pitää luotettavana pitkäaikaissäilytysvälineenä.
Mutta tämän lisäksi ensimmäisessä kohdassa on toinen vakava ongelma - se yksinkertaistaa niin paljon kuin mahdollista tilin estäminen pahantahtoisella tarkoituksella. Jos tiedän jonkun verkkosivustolla tilin omistavan sähköpostiosoitteen, voin estää hänet milloin tahansa yksinkertaisesti nollaamalla hänen salasanansa. Tämä on palvelunestohyökkäys, joka tarjoillaan hopealautasella! Tästä syystä nollaus tulisi suorittaa vasta sen jälkeen, kun pyytäjän oikeudet on varmistettu onnistuneesti.
Kun puhumme nollattavasta URL-osoitteesta, tarkoitamme sellaisen verkkosivuston osoitetta, joka on ainutlaatuinen tässä nollausprosessin tapauksessa. Tietenkin sen tulee olla satunnainen, sen ei pitäisi olla helppo arvata, eikä se saa sisältää ulkoisia linkkejä tiliin, jotka helpottavat palauttamista. Esimerkiksi nollaus-URL-osoite ei saa olla vain polku, kuten "Reset/?username=JohnSmith".
Haluamme luoda yksilöllisen tunnuksen, joka voidaan lähettää palautus-URL-osoitteena ja sitten verrata käyttäjän tilin palvelintietueeseen. Näin varmistetaan, että tilin omistaja on itse asiassa sama henkilö, joka yrittää nollata salasanan . Tunnus voi esimerkiksi olla "3ce7854015cd38c862cb9e14a1ae552b" ja tallentaa taulukkoon nollauksen suorittavan käyttäjän tunnuksen ja tunnuksen luomisajan kanssa (lisätietoja alla). Kun sähköposti lähetetään, se sisältää URL-osoitteen, kuten "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", ja kun käyttäjä lataa sen, sivu kysyy tunnuksen olemassaolosta, minkä jälkeen se vahvistaa käyttäjän tiedot ja sallii käyttäjän muuttaa Salasana.
Tietenkin, koska yllä oleva prosessi (toivottavasti) antaa käyttäjän luoda uuden salasanan, meidän on tietysti varmistettava, että URL-osoite ladataan HTTPS:n kautta. Ei, , tämän tunnuksen URL-osoitteen on käytettävä kuljetuskerroksen suojausta, jotta uutta salasanalomaketta ei voida hyökätä ja käyttäjän luoma salasana lähetettiin suojatun yhteyden kautta.
Myös nollaus-URL-osoitteelle on lisättävä tunnuksen aikaraja, jotta nollausprosessi voidaan suorittaa tietyn aikavälin sisällä, esimerkiksi tunnin sisällä. Tämä varmistaa, että nollausaikaikkuna pidetään mahdollisimman pienenä, jotta nollatun URL-osoitteen vastaanottaja voi toimia vain tässä hyvin pienessä ikkunassa. Hyökkääjä voi tietysti aloittaa palautusprosessin uudelleen, mutta hänen on hankittava toinen yksilöllinen palautus-URL-osoite.
Lopuksi meidän on varmistettava, että tämä prosessi on kertakäyttöinen. Kun nollausprosessi on valmis, tunnus on poistettava, jotta nollaus-URL-osoite ei enää toimi. Edellinen kohta on välttämätön sen varmistamiseksi, että hyökkääjällä on hyvin pieni ikkuna, jonka aikana hän voi käsitellä nollattua URL-osoitetta. Lisäksi tietysti, kun nollaus on onnistunut, merkkiä ei enää tarvita.
Jotkut näistä vaiheista saattavat tuntua liian tarpeettomilta, mutta ne eivät häiritse käytettävyyttä ja itse asiassa parantaa turvallisuutta, vaikkakin tilanteissa, joiden toivomme olevan harvinaisia. 99 %:ssa tapauksista käyttäjä ottaa nollauksen käyttöön hyvin lyhyessä ajassa eikä nollaa salasanaa uudelleen lähitulevaisuudessa.
CAPTCHA:n rooli
Oi, CAPTCHA, tietoturvaominaisuus, jota me kaikki rakastamme vihata! Itse asiassa CAPTCHA ei ole niinkään suojaustyökalu kuin tunnistustyökalu - olitpa sitten henkilö tai robotti (tai automaattinen komentosarja). Sen tarkoituksena on välttää automaattinen lomakkeiden lähettäminen, mikä tietysti voida käyttää yrityksenä rikkoa suojaus. Salasanan nollauksen yhteydessä CAPTCHA tarkoittaa, että nollaustoimintoa ei voida raa'asti pakottaa roskapostiksi käyttäjälle tai yrittää määrittää tilien olemassaoloa (mikä ei tietenkään ole mahdollista, jos noudatat osiossa henkilöllisyyden vahvistaminen).
CAPTCHA itsessään ei tietenkään ole täydellinen; Sen ohjelmistojen "hakkerointi" ja riittävä onnistumisprosentti (60-70 %) ovat olemassa monia ennakkotapauksia. Lisäksi viestissäni on ratkaisu , jossa voit maksaa ihmisille sentin murto-osia jokaisen CAPTCHA:n ratkaisemisesta ja 94 prosentin onnistumisprosentin saavuttamisesta. Toisin sanoen se on haavoittuvainen, mutta se (hieman) nostaa markkinoille pääsyn estettä.
Katsotaanpa esimerkkiä PayPalista:
Tässä tapauksessa nollausprosessi ei yksinkertaisesti voi alkaa ennen kuin CAPTCHA on ratkaistu, joten teoriassa prosessia on mahdotonta automatisoida. Teoriassa.
Useimmille verkkosovelluksille tämä on kuitenkin ylivoimaista aivan oikeassa tarkoittaa käytettävyyden heikkenemistä - ihmiset eivät vain pidä CAPTCHAsta! Lisäksi CAPTCHA on jotain, johon voit helposti palata tarvittaessa. Jos palvelu alkaa joutua hyökkäyksen kohteeksi (tässä kirjaamisesta on hyötyä, mutta siitä lisää myöhemmin), CAPTCHA:n lisääminen ei voisi olla helpompaa.
Salaisia kysymyksiä ja vastauksia
Kaikilla harkitsemillamme menetelmillä pystyimme palauttamaan salasanan vain käyttämällä sähköpostitiliä. Sanon "vain", mutta tietysti on laitonta päästä jonkun toisen sähköpostitiliin. täytyy olla monimutkainen prosessi. kuitenkin .
Itse asiassa yllä oleva linkki Sarah Palinin Yahoo! palvelee kahta tarkoitusta; Ensinnäkin se havainnollistaa, kuinka helppoa (joidenkin) sähköpostitilien hakkeroiminen on, ja toiseksi se osoittaa, kuinka huonoja turvakysymyksiä voidaan käyttää haitallisesti. Mutta palataan tähän myöhemmin.
XNUMX-prosenttisesti sähköpostiin perustuvien salasanan nollausten ongelmana on, että sen sivuston tilin eheys, jota yrität nollata, riippuu XNUMX-prosenttisesti sähköpostitilin eheydestä. Kaikki, joilla on pääsy sähköpostiisi voi käyttää kaikkia tilejä, jotka voidaan nollata vastaanottamalla sähköposti. Tällaisissa tileissä sähköposti on online-elämäsi "avain kaikkiin oviin".
Yksi tapa vähentää tätä riskiä on ottaa käyttöön turvakysymys- ja vastausmalli. Olet epäilemättä jo nähnyt ne: valitse kysymys, johon vain sinä voit vastata olla tiedät vastauksen, ja kun nollaat salasanasi, sinulta kysytään sitä. Tämä lisää luottamusta siihen, että nollausta yrittävä henkilö on todellakin tilin omistaja.
Takaisin Sarah Paliniin: virhe oli, että vastaukset hänen turvakysymykseen/kysymyksiinsä löytyi helposti. Varsinkin kun olet niin merkittävä julkisuuden henkilö, tieto äitisi tyttönimestä, koulutushistoriasta tai siitä, missä joku on saattanut asua menneisyydessä, ei ole niin salainen. Itse asiassa suurimman osan siitä voi löytää melkein kuka tahansa. Sarahille kävi näin:
Hakkeri David Kernell pääsi Palinin tiliin etsimällä tietoja hänen taustastaan, kuten yliopistostaan ja syntymäaikastaan, ja käyttämällä sitten Yahoo!:n unohdetun salasanan palautusominaisuutta.
Ensinnäkin tämä on suunnitteluvirhe Yahoo! — Tällaisilla yksinkertaisilla kysymyksillä yritys sabotoi olennaisesti turvakysymyksen arvon ja siten järjestelmänsä suojan. Tietenkin sähköpostitilin salasanojen nollaus on aina vaikeampaa, koska omistajuutta ei voi todistaa lähettämällä sähköpostia omistajalle (ilman toista osoitetta), mutta onneksi tällaisen järjestelmän luomiseen ei ole nykyään paljon käyttöä.
Palataan turvakysymyksiin – on mahdollisuus antaa käyttäjälle mahdollisuus luoda omia kysymyksiä. Ongelmana on, että tämä johtaa hirveän ilmeisiin kysymyksiin:
Minkä värinen taivas on?
Kysymykset, jotka saavat ihmiset tuntemaan olonsa epämukavaksi, kun tunnistamiseen käytetään turvakysymystä ihmiset (esimerkiksi puhelinkeskuksessa):
Kenen kanssa nukuin jouluna?
Tai suoraan sanottuna tyhmiä kysymyksiä:
Miten kirjoitetaan "salasana"?
Turvakysymyksissä käyttäjien on pelastettava itseltään! Toisin sanoen turvakysymys tulisi määrittää sivuston itsensä toimesta tai vielä paremmin kysyä sarja turvakysymyksiä, joista käyttäjä voi valita. Eikä ole helppo valita yksi; Ihannetapauksessa käyttäjän tulisi valita kaksi tai useampi turvakysymys tilin rekisteröinnin yhteydessä, jota käytetään sitten toisena tunnistuskanavana. Useiden kysymysten saaminen lisää luottamusta varmennusprosessiin ja tarjoaa myös mahdollisuuden lisätä satunnaisuutta (ei aina näytä samaa kysymystä), sekä tarjoaa hieman redundanssia, jos todellinen käyttäjä on unohtanut salasanan.
Mikä on hyvä turvakysymys? Tähän vaikuttavat useat tekijät:
- Sen pitäisi olla lyhyt — kysymyksen on oltava selkeä ja yksiselitteinen.
- Vastauksen täytyy olla erityinen – Emme tarvitse kysymystä, johon yksi henkilö voi vastata eri tavalla
- Mahdollisia vastauksia pitäisi olla monipuolinen - Jonkun lempivärin kysyminen antaa hyvin pienen osajoukon mahdollisia vastauksia
- haku vastauksen on oltava monimutkainen - jos vastaus löytyy helposti kaikki (muistakaa ihmiset korkeissa asemissa), silloin hän on huono
- Vastauksen täytyy olla DC ajoissa - jos kysyt jonkun suosikkielokuvaa, niin vuotta myöhemmin vastaus voi olla erilainen
Kuten se tapahtuu, on olemassa verkkosivusto, joka on omistettu hyvien kysymysten esittämiseen . Jotkut kysymyksistä vaikuttavat melko hyviltä, toiset eivät läpäise kaikkia yllä kuvattuja testejä, etenkään "haun helppous" -testiä.
Haluan näyttää, kuinka PayPal toteuttaa turvakysymykset ja erityisesti sivuston todentamisen vaivaa. Yllä näimme sivun prosessin aloittamiseksi (CAPTCHA:lla), ja tässä näytämme, mitä tapahtuu sen jälkeen, kun annat sähköpostiosoitteesi ja ratkaisit CAPTCHA:n:
Tämän seurauksena käyttäjä saa seuraavan kirjeen:
Toistaiseksi kaikki on aivan normaalia, mutta tässä on mitä tämän nollaus-URL-osoitteen takana on piilotettu:
Joten turvallisuuskysymykset tulevat peliin. Itse asiassa PayPalin avulla voit myös nollata salasanasi vahvistamalla luottokorttisi numeron, joten käytettävissä on lisäkanava, johon monilla sivustoilla ei ole pääsyä. En vain voi vaihtaa salasanaani vastaamatta molemmat turvakysymys (tai et tiedä kortin numeroa). Vaikka joku kaappaaisi sähköpostini, hän ei voisi nollata PayPal-tilini salasanaa, ellei he tietäisi hieman henkilökohtaisia tietojani. Mitä tietoja? Tässä ovat PayPalin turvakysymysvaihtoehdot:
Koulu- ja sairaalakysymys voi olla haun helppouden kannalta hieman hankala, mutta muut eivät ole huonoja. Turvallisuuden parantamiseksi PayPal vaatii kuitenkin lisätunnistuksen muutokset vastauksia turvallisuuskysymyksiin:
PayPal on melko utopistinen esimerkki suojatuista salasanan nollauksista: se toteuttaa CAPTCHA:n vähentämään raa'an voiman hyökkäysten vaaraa, vaatii kaksi turvakysymystä ja vaatii sitten toisenlaisen täysin erilaisen tunnistuksen vain muuttaakseen vastauksia – ja tämä käyttäjän jälkeen. on jo kirjautunut sisään. Tietysti tämä on juuri sitä mitä me odotettavissa PayPalista; on rahoituslaitos, joka käsittelee suuria rahasummia. Tämä ei tarkoita, että jokaisen salasanan nollauksen on noudatettava näitä vaiheita – useimmiten se on ylivoimaista – mutta se on hyvä esimerkki tapauksista, joissa turvallisuus on vakava asia.
Turvakysymysjärjestelmän mukavuus on, että jos et ole ottanut sitä heti käyttöön, voit lisätä sen myöhemmin, jos resurssien suojaustaso sitä vaatii. Hyvä esimerkki tästä on Apple, joka vasta äskettäin otti tämän mekanismin käyttöön [artikkeli kirjoitettu vuonna 2012]. Kun aloin päivittämään sovellusta iPadillani, näin seuraavan pyynnön:
Sitten näin näytön, josta saatoin valita useita turvakysymyksiä ja vastauksia sekä pelastussähköpostiosoitteen:
Mitä tulee PayPaliin, kysymykset ovat esivalittuja ja jotkut niistä ovat itse asiassa melko hyviä:
Jokainen kolmesta kysymys/vastaus-parista edustaa erilaista mahdollisia kysymyksiä, joten tilin määrittämiseen on monia tapoja.
Toinen huomioitava näkökohta turvakysymykseesi vastaamisessa on tallennus. Pelkän tekstin sisältävän tietokannan käyttö tietokannassa aiheuttaa lähes samat uhat kuin salasana, nimittäin että tietokannan paljastaminen paljastaa välittömästi arvon ja vaarantaa sovelluksen lisäksi mahdollisesti täysin erilaiset sovellukset, jotka käyttävät samoja turvakysymyksiä (niin taas ). Yksi vaihtoehto on turvallinen hajautus (vahva algoritmi ja kryptografisesti satunnainen suola), mutta toisin kuin useimmissa salasanan tallennustapauksissa, vastauksen näkymiseen pelkkänä tekstinä voi olla hyvä syy. Tyypillinen skenaario on henkilöllisyyden vahvistaminen live-puhelinoperaattorin toimesta. Tietysti hajautus on sovellettavissa myös tässä tapauksessa (operaattori voi yksinkertaisesti syöttää asiakkaan nimeämän vastauksen), mutta pahimmassa tapauksessa salaisen vastauksen on sijaittava jollakin salaustallennustasolla, vaikka kyseessä olisikin vain symmetrinen salaus. . Yhteenveto: kohtele salaisuuksia kuin salaisuuksia!
Viimeinen turvallisuuskysymysten ja -vastausten näkökohta on, että ne ovat alttiimpia sosiaaliselle suunnittelulle. Yritetään purkaa salasana suoraan jonkun muun tilille on yksi asia, mutta keskustelun aloittaminen sen muodostamisesta (suosittu turvakysymys) on täysin eri asia. Itse asiassa voit hyvin kommunikoida jonkun kanssa monista hänen elämänsä näkökohdista, jotka saattavat herättää salaisen kysymyksen herättämättä epäilyksiä. Turvakysymyksen ydin on tietysti se, että se liittyy jonkun elämänkokemukseen, joten se on mieleenpainuva, ja siinä se ongelma piileekin. ihmiset rakastavat puhua elämänkokemuksistaan! Tälle ei voi juurikaan tehdä, vain jos valitset turvakysymysvaihtoehdot niin, että ne ovat vähemmän se voitaisiin todennäköisesti vetää pois sosiaalisen manipuloinnin avulla.
[Jatkuu.]Mainonnan oikeuksista
VDSina tarjoaa luotettavia , jokainen palvelin on yhdistetty 500 megabitin Internet-kanavaan ja on suojattu DDoS-hyökkäyksiltä ilmaiseksi!
Lähde: will.com