{"id":97639,"date":"2020-10-20T02:42:56","date_gmt":"2020-10-20T00:42:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2"},"modified":"2020-10-20T02:42:56","modified_gmt":"2020-10-20T00:42:56","slug":"vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","title":{"rendered":"Allt du ville veta om s\u00e4ker \u00e5terst\u00e4llning av l\u00f6senord. Del 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tv\u00e5faktorsautentisering<\/h2>\n

\nAllt som ni har l\u00e4st i f\u00f6rsta delen<\/a><\/noindex> handlade om identifiering baserat p\u00e5 vad den som beg\u00e4r k\u00e4nner till<\/em><\/strong>. De vet sin e-postadress, vet hur man f\u00e5r \u00e5tkomst till den (d.v.s. vet sitt e-postl\u00f6senord) och k\u00e4nner till svaren p\u00e5 hemliga fr\u00e5gor. <\/p>\n

\u00abK\u00e4nnedom\u00bb betraktas som en autentiseringsfaktor; tv\u00e5 andra vanliga faktorer \u00e4r vad ni har<\/em><\/strong>, till exempel en fysisk enhet, och vem ni \u00e4r<\/em><\/strong>, till exempel fingeravtryck eller n\u00e4thinna.<\/p>\n

\"Allt
\n<\/a><\/noindex>
\nI de flesta fall \u00e4r det sv\u00e5rt att genomf\u00f6ra biologisk identifiering, s\u00e4rskilt n\u00e4r vi pratar om s\u00e4kerheten f\u00f6r webbapplikationer, d\u00e4rf\u00f6r anv\u00e4nds vanligtvis den andra attributet i tv\u00e5faktorsautentisering (two factor authentication, 2FA) \u2014 \"vad ni har\". En popul\u00e4r variant av denna andra faktor \u00e4r en fysisk token, till exempel, RSA SecurID<\/a><\/noindex>:<\/p>\n

\"Allt
\nEn fysisk token anv\u00e4nds ofta f\u00f6r autentisering i f\u00f6retags VPN och finansiella tj\u00e4nster. F\u00f6r autentisering i tj\u00e4nsten m\u00e5ste ni anv\u00e4nda b\u00e5de l\u00f6senord och koden p\u00e5 token (som ofta \u00e4ndras) i kombination med en PIN-kod. Teoretiskt sett, f\u00f6r att identifiera en angripare m\u00e5ste denne veta l\u00f6senordet, ha token och ocks\u00e5 k\u00e4nna till tokenens PIN-kod. I ett scenario f\u00f6r \u00e5terst\u00e4llning av l\u00f6senord \u00e4r sj\u00e4lva l\u00f6senordet uppenbarligen ok\u00e4nt, men innehav av token kan anv\u00e4ndas f\u00f6r att bekr\u00e4fta \u00e4garskapet av kontot. Sj\u00e4lvklart erbjuder detta, som med alla skyddsmekanismer, inte \"foolproof\" skydd<\/a><\/noindex>, men \u00f6kar definitivt intr\u00e4desbarri\u00e4ren.<\/p>\n

Ett av de fr\u00e4msta problemen med denna metod \u00e4r kostnaden och logistiken f\u00f6r att genomf\u00f6ra; vi talar om att ge fysiska enheter till varje kund och utbilda dem i den nya processen. Dessutom m\u00e5ste anv\u00e4ndarna ha enheten med sig, vilket i fallet med en fysisk token inte alltid \u00e4r m\u00f6jligt. Ett annat alternativ \u00e4r att genomf\u00f6ra den andra autentiseringsfaktorn med hj\u00e4lp av SMS, som i fallet med 2FA kan fungera som bekr\u00e4ftelse p\u00e5 att den som genomf\u00f6r \u00e5terst\u00e4llningsprocessen har \u00e4garens mobiltelefon. S\u00e5 h\u00e4r g\u00f6r Google:<\/p>\n

\"Allt
\nDet \u00e4r ocks\u00e5 n\u00f6dv\u00e4ndigt att aktivera tv\u00e5stegsverifiering<\/a><\/noindex>, men det inneb\u00e4r att din mobiltelefon vid n\u00e4sta \u00e5terst\u00e4llning av l\u00f6senordet kan bli en andra autentiseringsfaktor. L\u00e5t mig demonstrera detta med min iPhone av sk\u00e4l som snart kommer att bli uppenbara:<\/p>\n

\"Allt
\nEfter att e-postadressen till Google-kontot har identifierats uppt\u00e4cker systemet att 2FA har aktiverats och vi kan \u00e5terst\u00e4lla kontot genom en verifiering som skickas via SMS till kontoinnehavarens mobiltelefon:<\/p>\n

\"Allt
\nNu beh\u00f6ver vi v\u00e4lja att p\u00e5b\u00f6rja \u00e5terst\u00e4llningsprocessen:<\/p>\n

\"Allt
\nDenna \u00e5tg\u00e4rd leder till att ett e-postmeddelande skickas till den registrerade adressen:<\/p>\n

\"Allt
\nDetta meddelande inneh\u00e5ller en \u00e5terst\u00e4llnings-URL:<\/p>\n

\"Allt
\nVid \u00e5tkomst av \u00e5terst\u00e4llnings-URL:en skickas ett SMS och webbplatsen ber om att det ska anges:<\/p>\n

\"Allt
\nH\u00e4r \u00e4r detta SMS:<\/p>\n

\"Allt
\nN\u00e4r vi anger det i webbl\u00e4saren \u00e5terv\u00e4nder vi till den klassiska \u00e5terst\u00e4llningen av l\u00f6senord:<\/p>\n

\"Allt
\nDet verkar kanske n\u00e5got omst\u00e4ndligt, och det \u00e4r det, men formul\u00e4ret bekr\u00e4ftar att den som \u00e5terst\u00e4ller har tillg\u00e5ng till b\u00e5de kontoinnehavarens e-postadress och mobiltelefon. Men detta kan vara nio g\u00e5nger s\u00e4krare \u00e4n att bara \u00e5terst\u00e4lla l\u00f6senordet via e-post. Det finns dock problem...<\/p>\n

Problemet r\u00f6r smartphones. Enheten som visas nedan kan verifiera endast en autentiseringsfaktor \u2014 den kan ta emot SMS, men inte e-post:<\/p>\n

\"Allt
\nMen denna enhet kan ta emot SMS och<\/em> ta emot e-postmeddelanden om \u00e5terst\u00e4llning av l\u00f6senord:<\/p>\n

\"Allt
\nProblemet \u00e4r att vi betraktar e-posten som den f\u00f6rsta autentiseringsfaktorn, och SMS (eller till och med en app som genererar tokens) som den andra, men idag \u00e4r de sammanslagna i en enhet. Det betyder naturligtvis att om n\u00e5gon f\u00e5r tag p\u00e5 din smartphone, s\u00e5 minimeras allt detta bekv\u00e4mlighet till att vi \u00e5ter \u00e4r tillbaka till en kanal; den andra faktorn \u201cn\u00e5got du har\u201d inneb\u00e4r att du ocks\u00e5 har den f\u00f6rsta faktorn. Och allt detta skyddas av en fyrsiffrig PIN-kod\u2026 om telefonen ens har en PIN-kod och<\/em> den var l\u00e5st.<\/p>\n

Ja, den implementerade Google-funktionen 2FA ger helt klart ett ytterligare skydd, men den skyddar inte mot 'dumheter', och den beror absolut inte p\u00e5 tv\u00e5 helt frist\u00e5ende kanaler.<\/p>\n

\u00c5terst\u00e4llning via anv\u00e4ndarnamn mot \u00e5terst\u00e4llning via e-postadress<\/h2>\n

\nSka man till\u00e5ta \u00e5terst\u00e4llning endast via e-postadress? Eller ska anv\u00e4ndaren kunna \u00e5terst\u00e4lla \u00e4ven med anv\u00e4ndarnamn? Problemet med att \u00e5terst\u00e4lla med anv\u00e4ndarnamn \u00e4r att det inte finns n\u00e5got s\u00e4tt att informera anv\u00e4ndaren om ett felaktigt anv\u00e4ndarnamn, utan att avsl\u00f6ja<\/em> att n\u00e5gon annan kan ha ett konto med det namnet. I f\u00f6reg\u00e5ende avsnitt garanterade \u00e5terst\u00e4llning via e-post att den legitima \u00e4garen av denna e-post alltid skulle f\u00e5 feedback utan att offentligt avsl\u00f6ja sin existens i systemet. Med hj\u00e4lp av endast anv\u00e4ndarnamnet \u00e4r detta om\u00f6jligt.<\/p>\n

S\u00e5 svaret \u00e4r enkelt: endast e-post. Om du f\u00f6rs\u00f6ker \u00e5terst\u00e4lla endast med hj\u00e4lp av anv\u00e4ndarnamn, kommer det att uppst\u00e5 situationer d\u00e4r anv\u00e4ndaren undrar vad som har h\u00e4nt, eller<\/em> du kommer att avsl\u00f6ja existensen av konton. Ja, det \u00e4r bara ett anv\u00e4ndarnamn, inte en e-postadress och ja, vem som helst kan v\u00e4lja vilket (tillg\u00e4ngligt) anv\u00e4ndarnamn som helst, men det finns fortfarande en stor risk att du indirekt avsl\u00f6jar kontoinnehavarna p\u00e5 grund av anv\u00e4ndarnas ben\u00e4genhet att \u00e5teranv\u00e4nda namn.<\/p>\n

Vad h\u00e4nder d\u00e5 n\u00e4r n\u00e5gon gl\u00f6mmer sitt anv\u00e4ndarnamn? Om vi antar att anv\u00e4ndarnamnet inte \u00e4r samma som e-postadress (vilket ofta \u00e4r fallet), s\u00e5 liknar processen hur \u00e5terst\u00e4llning av l\u00f6senord b\u00f6rjar - vi anger e-postadressen och skickar sedan ett meddelande till denna adress utan att avsl\u00f6ja dess existens. Den enda skillnaden \u00e4r att detta meddelande bara inneh\u00e5ller anv\u00e4ndarnamnet, inte en URL f\u00f6r \u00e5terst\u00e4llning av l\u00f6senord. Antingen det, eller s\u00e5 st\u00e5r det i e-postmeddelandet att det inte finns n\u00e5got konto f\u00f6r denna adress.<\/p>\n

Identitetsverifiering och noggrannhet av e-postadresser<\/h2>\n

\nEn avg\u00f6rande aspekt av l\u00f6senords\u00e5terst\u00e4llningar, och kanske den mest<\/em> avg\u00f6rande aspekten \u00e4r verifiering av identiteten hos personen som f\u00f6rs\u00f6ker \u00e5terst\u00e4lla. \u00c4r det verkligen den legitima \u00e4garen av kontot, eller \u00e4r det n\u00e5gon som f\u00f6rs\u00f6ker hacka eller orsaka besv\u00e4r f\u00f6r \u00e4garen?<\/p>\n

Det \u00e4r uppenbart att e-post \u00e4r den mest bekv\u00e4ma och vanligaste kanalen f\u00f6r identitetsverifiering. Den \u00e4r inte skyddad mot klumpigt handhavande (\"fr\u00e5n en idiot\"), och det finns m\u00e5nga fall d\u00e4r den enkla m\u00f6jligheten att ta emot mejl p\u00e5 en kontoinnehavares adress inte \u00e4r tillr\u00e4cklig, om en h\u00f6g grad av s\u00e4kerhet i identifieringen kr\u00e4vs (d\u00e4rf\u00f6r anv\u00e4nds 2FA). Men n\u00e4stan alltid \u00e4r det en utg\u00e5ngspunkt f\u00f6r \u00e5terst\u00e4llningsprocessen.<\/p>\n

Om e-post ska spela en roll f\u00f6r att s\u00e4kerst\u00e4lla tillfredsst\u00e4llelse, \u00e4r det f\u00f6rsta steget att se till att e-postadressen faktiskt \u00e4r korrekt. Om n\u00e5gon g\u00f6r ett fel tecken, kommer \u00e5terst\u00e4llning uppenbarligen inte att p\u00e5b\u00f6rjas. Processen f\u00f6r verifiering av e-post vid registrering \u00e4r ett tillf\u00f6rlitligt s\u00e4tt att kontrollera att adressen \u00e4r korrekt. Vi har alla sett det i praktiken: du registrerar dig, ett mejl med en unik URL skickas till dig, som du m\u00e5ste klicka p\u00e5, vilket bekr\u00e4ftar att du verkligen \u00e4r \u00e4garen av den h\u00e4r e-postadressen. Of\u00f6rm\u00e5ga att logga in f\u00f6rr\u00e4n denna process \u00e4r slutf\u00f6rd garanterar att det finns motivation f\u00f6r att bekr\u00e4fta adressen.<\/p>\n

Som med m\u00e5nga andra aspekter av s\u00e4kerhet, minskar en s\u00e5dan modell anv\u00e4ndarv\u00e4nligheten f\u00f6r att s\u00e4kerst\u00e4lla en h\u00f6gre grad av s\u00e4kerhet ang\u00e5ende anv\u00e4ndarens identitet. Detta kan vara acceptabelt f\u00f6r en webbplats d\u00e4r anv\u00e4ndaren v\u00e4rdes\u00e4tter registreringen h\u00f6gt och g\u00e4rna l\u00e4gger till ytterligare ett steg i processen (betj\u00e4nade tj\u00e4nster, bankverksamhet, etc.), men s\u00e5dana \u00e5tg\u00e4rder kan avskr\u00e4cka anv\u00e4ndaren om de ser sitt konto som \"eng\u00e5ngs\" och till exempel bara anv\u00e4nder det som ett s\u00e4tt att kommentera ett inl\u00e4gg.<\/p>\n

Identifiering av vem som initierade \u00e5terst\u00e4llningsprocessen<\/h2>\n

\nDet \u00e4r uppenbart att det finns sk\u00e4l till skadlig anv\u00e4ndning av \u00e5terst\u00e4llningsfunktionen, och angripare kan anv\u00e4nda den p\u00e5 m\u00e5nga olika s\u00e4tt. Ett enkelt trick som vi kan anv\u00e4nda f\u00f6r att hj\u00e4lpa till att bekr\u00e4fta k\u00e4llan till beg\u00e4ran (detta trick fungerar vanligtvis<\/em> och g\u00e5r ut p\u00e5) att inkludera IP-adressen f\u00f6r den som beg\u00e4rde i mejlet med \u00e5terst\u00e4llningserbjudandet. Detta ger mottagaren en viss<\/em> information f\u00f6r att identifiera k\u00e4llan till beg\u00e4ran.<\/p>\n

H\u00e4r \u00e4r ett exempel fr\u00e5n en \u00e5terst\u00e4llningsfunktion som jag f\u00f6r n\u00e4rvarande integrerar i ASafaWeb:<\/p>\n

\"Allt
\nL\u00e4nken \"find out more\" (\"L\u00e4s mer\") tar anv\u00e4ndaren till webbplatsen ip-adress.com<\/a><\/noindex>, som ger information som plats och organisation av den som beg\u00e4r omst\u00e4llning:<\/p>\n

\"Allt
\nNaturligtvis har alla som vill d\u00f6lja sin identitet m\u00e5nga s\u00e4tt att maskera sin verkliga IP-adress, men detta \u00e4r ett praktiskt s\u00e4tt att l\u00e4gga till delvis identifiering av den som beg\u00e4r, och i de flesta<\/em> m\u00e5nga fall kommer det att ge dig en bra uppfattning om vem som g\u00f6r beg\u00e4ran om l\u00f6senords\u00e5terst\u00e4llning.<\/p>\n

E-postavisering om \u00e4ndringar<\/h2>\n

\nDetta inl\u00e4gg genomsyras av ett tema \u2013 kommunikation; informera kontoinnehavaren s\u00e5 mycket som m\u00f6jligt om vad som h\u00e4nder i varje steg av processen, utan att avsl\u00f6ja n\u00e5got som kan anv\u00e4ndas i ond tro. Detta g\u00e4ller \u00e4ven situationen n\u00e4r l\u00f6senordet faktiskt har \u00e4ndrats \u2013 informera kontoinnehavaren om detta!<\/em><\/strong><\/p>\n

Orsakerna till att byta l\u00f6senord kan komma fr\u00e5n tv\u00e5 k\u00e4llor:<\/p>\n

    \n
  1. Byte av l\u00f6senord efter inloggning eftersom anv\u00e4ndaren vill ha ett nytt l\u00f6senord<\/li>\n
  2. \u00c5terst\u00e4llning av l\u00f6senord utan inloggning eftersom anv\u00e4ndaren har gl\u00f6mt det<\/li>\n<\/ol>\n

    \n\u00c4ven om detta inl\u00e4gg huvudsakligen handlar om \u00e5terst\u00e4llning, minskar aviseringen i det f\u00f6rsta fallet risken f\u00f6r att n\u00e5gon \u00e4ndrar l\u00f6senordet utan att den legitima \u00e4garen \u00e4r medveten om det. Hur kan detta h\u00e4nda? Ett mycket vanligt scenario \u00e4r att en illvillig akt\u00f6r f\u00e5r tag p\u00e5 \u00e4garens l\u00f6senord (ett \u00e5teranv\u00e4nt l\u00f6senord som l\u00e4ckt fr\u00e5n en annan k\u00e4lla; ett l\u00f6senord som f\u00e5ngats av tangentbordslogger; ett l\u00e4tt gissat l\u00f6senord etc.), och d\u00e5 best\u00e4mmer sig f\u00f6r att \u00e4ndra det, vilket l\u00e5ser \u00e4garen ute. Utan e-postavisering kommer den verkliga \u00e4garen inte att veta om l\u00f6senordsbytet.<\/p>\n

    Sj\u00e4lvklart, i h\u00e4ndelse av en l\u00f6senords\u00e5terst\u00e4llning b\u00f6r \u00e4garen redan ha initierat processen sj\u00e4lv (eller kringg\u00e5tt de n\u00e4mnda identitetskontrollmetoderna), s\u00e5 bytet b\u00f6r<\/em> inte vara en \u00f6verraskning f\u00f6r honom, men en bekr\u00e4ftelse via e-post skulle vara positiv feedback och en extra kontroll. Dessutom s\u00e4kerst\u00e4ller detta konsistens med det tidigare beskrivna scenariot.<\/p>\n

    Och f\u00f6r att det inte ska vara otydligt \u2013 skicka inte det nya l\u00f6senordet via e-post!<\/em><\/strong> Detta kan f\u00e5 n\u00e5gon att skratta, men s\u00e5dant h\u00e4nder<\/a><\/noindex>:<\/p>\n

    \"Allt<\/p>\n

    Loggar, loggar, loggar och lite mer loggar<\/h2>\n

    \nFunktionen f\u00f6r \u00e5terst\u00e4llning av l\u00f6senord \u00e4r attraktiva f\u00f6r illvilliga akt\u00f6rer: en angripare vill ha \u00e5tkomst till n\u00e5gon annans konto, eller s\u00e5 vill de helt enkelt orsaka besv\u00e4r f\u00f6r kontoinnehavaren\/systemet. M\u00e5nga av de ovan beskrivna metoderna kan minska risken f\u00f6r missbruk, men de f\u00f6rhindrar dem inte, och de kommer definitivt inte att stoppa folk fr\u00e5n att f\u00f6rs\u00f6ka anv\u00e4nda funktionen p\u00e5 ett otill\u00e5tet s\u00e4tt.<\/p>\n

    En ov\u00e4rderlig praxis f\u00f6r att uppt\u00e4cka illvilligt beteende \u00e4r loggning, och jag menar mycket detaljerad loggning<\/em><\/strong>. Logga misslyckade inloggningsf\u00f6rs\u00f6k, \u00e5terst\u00e4llningar av l\u00f6senord, \u00e4ndringar av l\u00f6senord (d.v.s. n\u00e4r anv\u00e4ndaren redan \u00e4r inloggad) och praktiskt taget allt som kan hj\u00e4lpa dig att f\u00f6rst\u00e5 vad som h\u00e4nder; detta kommer att vara mycket anv\u00e4ndbart i framtiden. Logga \u00e4ven individuella delar<\/em> av processen, exempelvis b\u00f6r en bra \u00e5terst\u00e4llningsfunktion inkludera initiering av \u00e5terst\u00e4llning via webbplatsen (logga beg\u00e4ran och inloggningsf\u00f6rs\u00f6k f\u00f6r \u00e5terst\u00e4llning med felaktigt anv\u00e4ndarnamn eller e-post), logga bes\u00f6k p\u00e5 webbsidan enligt URL:en f\u00f6r \u00e5terst\u00e4llning (inklusive f\u00f6rs\u00f6k att anv\u00e4nda en ogiltig token), och sedan logga om svar p\u00e5 s\u00e4kerhetsfr\u00e5gan var korrekt eller inte.<\/p>\n

    N\u00e4r jag pratar om loggning menar jag inte bara registreringen av att en sida har laddats, utan att samla s\u00e5 mycket information som m\u00f6jligt, om den inte \u00e4r konfidentiell<\/em><\/strong>. H\u00f6rni, v\u00e4nligen skriv inte ner l\u00f6senord i loggar!<\/em><\/strong> I loggarna b\u00f6r identiteten p\u00e5 den inloggade anv\u00e4ndaren registreras (han kommer att vara inloggad om han \u00e4ndrar<\/em> ett befintligt l\u00f6senord eller f\u00f6rs\u00f6ker \u00e5terst\u00e4lla n\u00e5gon annans l\u00f6senord<\/em> efter inloggning), alla anv\u00e4ndarnamn eller e-postadresser som han f\u00f6rs\u00f6ker samt vilka \u00e5terst\u00e4llningstoken han f\u00f6rs\u00f6ker anv\u00e4nda. Men det kan ocks\u00e5 vara nyttigt att logga s\u00e5dana aspekter som IP-adresser och, om m\u00f6jligt, \u00e4ven beg\u00e4rhuvuden. Detta g\u00f6r att du kan \u00e5terskapa inte bara vad<\/em> vad anv\u00e4ndaren (eller angriparen) f\u00f6rs\u00f6ker g\u00f6ra, utan \u00e4ven vem<\/em> vem han \u00e4r.<\/p>\n

    Delegation av ansvar till andra akt\u00f6rer<\/h2>\n

    \nOm du tycker att allt detta verkar vara en enorm m\u00e4ngd arbete, s\u00e5 \u00e4r du inte ensam. Att bygga ett p\u00e5litligt system f\u00f6r kontohantering \u00e4r faktiskt en tuff uppgift. Det handlar inte bara om den tekniska sv\u00e5righeten, utan det finns m\u00e5nga aspekter att ta h\u00e4nsyn till. Det handlar inte bara om att \u00e5terst\u00e4lla, det finns en hel process f\u00f6r registrering, s\u00e4ker lagring av l\u00f6senord, hantering av flera misslyckade inloggningsf\u00f6rs\u00f6k osv. Jag fr\u00e4mjar id\u00e9n om att anv\u00e4nda f\u00e4rdiga l\u00f6sningar som ASP.NET membership provider<\/a><\/noindex>, men det finns fortfarande mycket mer att g\u00f6ra.<\/p>\n

    Idag finns det m\u00e5nga tredjepartsleverant\u00f6rer som g\u00e4rna tar p\u00e5 sig allt besv\u00e4r och abstraherar allt detta till en hanterad tj\u00e4nst. Bland s\u00e5dana tj\u00e4nster finns OpenID, OAuth och till och med Facebook. Vissa m\u00e4nniskor har en gr\u00e4nsl\u00f6s tro p\u00e5 denna modell<\/a><\/noindex> (OpenID har faktiskt visat sig vara v\u00e4ldigt framg\u00e5ngsrik p\u00e5 Stack Overflow), men andra ser den bokstavligen som en mardr\u00f6m<\/a><\/noindex>.<\/p>\n

    Utan tvekan l\u00f6ser tj\u00e4nster som OpenID m\u00e5nga problem f\u00f6r utvecklare, men det \u00e4r ocks\u00e5 uppenbart att de tillf\u00f6r nya. Har de n\u00e5gon betydelse? Ja, men det \u00e4r tydligt att vi inte ser massanv\u00e4ndning av autentiseringstj\u00e4nster. Banker, flygbolag och till och med butiker \u2014 alla implementerar sina egna autentiseringsmekanismer, vilket uppenbarligen har mycket starka sk\u00e4l.<\/p>\n

    Skadlig \u00e5terst\u00e4llning<\/h2>\n

    \nEn viktig aspekt av varje av de tidigare n\u00e4mnda exemplen \u00e4r att det gamla l\u00f6senordet betraktas som v\u00e4rdel\u00f6st f\u00f6rst efter att identiteten hos kontoinnehavaren har bekr\u00e4ftats<\/em><\/strong>. Detta \u00e4r viktigt eftersom om ett konto kunde \u00e5terst\u00e4llas till<\/em> utan identitetsverifiering, skulle det m\u00f6jligg\u00f6ra alla m\u00f6jliga skadliga handlingar.<\/p>\n

    H\u00e4r \u00e4r ett exempel: n\u00e5gon deltar i budgivning p\u00e5 en auktionssajt, och n\u00e4r budgivningen b\u00f6rjar n\u00e4rma sig sitt slut blockerar de sina konkurrenter genom att p\u00e5b\u00f6rja \u00e5terst\u00e4llningsprocessen, vilket p\u00e5 s\u00e5 s\u00e4tt eliminerar dem fr\u00e5n budgivningen. Uppenbart, om en d\u00e5ligt utformad \u00e5terst\u00e4llningsfunktion kan utnyttjas p\u00e5 fel s\u00e4tt, kan det leda till allvarliga negativa konsekvenser. Det b\u00f6r noteras att kontoblockering genom flera misslyckade inloggningsf\u00f6rs\u00f6k \u00e4r en liknande situation, men det \u00e4r ett \u00e4mne f\u00f6r ett annat inl\u00e4gg.<\/p>\n

    Som jag n\u00e4mnde tidigare, om man ger anonyma anv\u00e4ndare m\u00f6jlighet att \u00e5terst\u00e4lla l\u00f6senord f\u00f6r vilken konto som helst bara genom att k\u00e4nna till e-postadressen, s\u00e5 \u00e4r det en perfekt situation f\u00f6r en \"\u00f6verbelastningsattack\". Det h\u00e4r kanske inte \u00e4r den DoS<\/a><\/noindex>, som vi \u00e4r vana vid att diskutera, men det finns inget snabbare s\u00e4tt att blockera \u00e5tkomsten till ett konto \u00e4n med en d\u00e5ligt t\u00e4nkt \u00e5terst\u00e4llningsfunktion.<\/p>\n

    Den svagaste l\u00e4nken<\/h2>\n

    \nUr perspektivet av att skydda ett konto \u00e4r allt ovanst\u00e5ende utm\u00e4rkt, men man m\u00e5ste alltid t\u00e4nka p\u00e5 ekosystemet som omger det skyddade kontot. L\u00e5t mig ge ett exempel:<\/p>\n

    ASafaWeb \u00e4r v\u00e4rd p\u00e5 en fantastisk tj\u00e4nst som tillhandah\u00e5lls av AppHarbor. \u00c5terst\u00e4llningsprocessen f\u00f6r kontot i hostingtj\u00e4nsten g\u00e5r till s\u00e5 h\u00e4r:<\/p>\n

    Steg 1:<\/strong><\/p>\n

    \"Allt
    \nSteg 2:<\/strong><\/p>\n

    \"Allt
    \nSteg 3:<\/strong><\/p>\n

    \"Allt
    \nSteg 4:<\/strong><\/p>\n

    \"Allt
    \nEfter att ha l\u00e4st all tidigare information \u00e4r det redan l\u00e4tt att f\u00f6rst\u00e5 vilka aspekter som vi skulle genomf\u00f6ra annorlunda i en perfekt v\u00e4rld. Men h\u00e4r vill jag s\u00e4ga att om jag skulle publicera en webbplats liknande ASafaWeb p\u00e5 AppHarbor och sedan komma p\u00e5 utm\u00e4rkta hemliga fr\u00e5gor och svar, l\u00e4gga till tv\u00e5faktorsautentisering och g\u00f6ra allt annat enligt reglerna, s\u00e5 avskaffar det inte det faktum att den svagaste l\u00e4nken i hela processen fortfarande kan bryta ner allt detta. Om n\u00e5gon framg\u00e5ngsrikt autentiserar sig p\u00e5 AppHarbor med min information, s\u00e5 kan de \u00e4ndra l\u00f6senordet f\u00f6r vilket konto som helst p\u00e5 ASafaWeb!<\/p>\n

    Po\u00e4ngen \u00e4r att robustheten i s\u00e4kerhetsimplementeringen b\u00f6r betraktas helhetsm\u00e4ssigt: man m\u00e5ste modellera hoten fr\u00e5n varje ing\u00e5ngspunkt till systemet, \u00e4ven om det \u00e4r en ytlig process som att logga in p\u00e5 AppHarbor. Detta b\u00f6r ge mig en god uppfattning om hur mycket arbete jag beh\u00f6ver l\u00e4gga ner i \u00e5terst\u00e4llningsprocessen f\u00f6r l\u00f6senordet p\u00e5 ASafaWeb.<\/p>\n

    Sammanfoga allt<\/h2>\n

    \nDetta inl\u00e4gg inneh\u00e5ller mycket information, s\u00e5 jag vill sammanfatta det i ett enkelt visuellt schema:<\/p>\n

    \"Allt
    \nKom ih\u00e5g att man b\u00f6r utf\u00f6ra s\u00e5 detaljerad loggning som m\u00f6jligt av var och en av dessa punkter. Det \u00e4r allt, det \u00e4r enkelt!<\/p>\n

    Sammanfattning<\/h2>\n

    \nMitt inl\u00e4gg verkar vara omfattande, men det finns m\u00e5nga ytterligare material som jag skulle kunna<\/em> inkludera det, men beslutade att avst\u00e5 fr\u00e5n detta f\u00f6r korthetens skull: rollen av adressen f\u00f6r r\u00e4ddande e-post, en situation d\u00e4r du f\u00f6rlorar tillg\u00e5ng till den e-post som \u00e4r kopplad till kontot (till exempel om du slutade p\u00e5 jobbet) och s\u00e5 vidare. Som jag sa tidigare, \u00e4r \u00e5terst\u00e4llningsfunktionen inte s\u00e5 komplicerad, det finns bara m\u00e5nga synpunkter p\u00e5 den.<\/p>\n

    Trots att \u00e5terst\u00e4llningen inte \u00e4r s\u00e5 sv\u00e5r, implementeras den ofta felaktigt. Ovan s\u00e5g vi ett par exempel p\u00e5 n\u00e4r implementeringen hantera pl\u00f6tsliga kraschar och visa anv\u00e4ndbara detaljer f\u00f6r fels\u00f6kning, som stacktrace. Att skicka felmeddelanden har f\u00f6renklats \u2014 det r\u00e4cker att klicka p\u00e5 l\u00e4nken.<\/em> ledde till problem, och det finns mycket fler exempel d\u00e4r felaktig \u00e5terst\u00e4llning verkligen<\/em> orsakade problem. Nyligen avsl\u00f6jades det att \u00e5terst\u00e4llning av l\u00f6senord har anv\u00e4nts f\u00f6r att stj\u00e4la bitcoins till ett v\u00e4rde av 87 000 dollar.<\/a><\/noindex>Det h\u00e4r \u00e4r ett allvarligt negativt resultat!<\/p>\n

    D\u00e4rf\u00f6r, var f\u00f6rsiktig med dina \u00e5terst\u00e4llningsfunktioner, modellera hot<\/a><\/noindex> p\u00e5 olika punkter, och n\u00e4r du designar funktionen, ta inte av din svarta hatt, f\u00f6r det finns en stor sannolikhet att n\u00e5gon annan kommer att ta p\u00e5 sig den!<\/p>\n

    <\/p>\n

    I reklamens namn<\/h4>\n

    \nVDSina<\/b> erbjuder prisv\u00e4rda servrar f\u00f6r uthyrning<\/a><\/noindex> med daglig betalning, varje server \u00e4r ansluten till en internetkanal p\u00e5 500 Megabit och \u00e4r gratis skyddad mot DDoS-attacker!<\/p>\n

    \"Allt<\/a><\/noindex>
    \n
    K\u00e4lla:     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0414\u0432\u0443\u0445\u0444\u0430\u043a\u0442\u043e\u0440\u0430\u044f \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u0412\u0441\u0451 \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u043d\u043d\u043e\u0435 \u0432\u0430\u043c\u0438 \u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u043a\u0430\u0441\u0430\u043b\u043e\u0441\u044c \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0438 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e \u0437\u043d\u0430\u0435\u0442 \u0437\u0430\u043f\u0440\u0430\u0448\u0438\u0432\u0430\u044e\u0449\u0438\u0439. \u041e\u043d \u0437\u043d\u0430\u0435\u0442 \u0441\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043f\u043e\u0447\u0442\u044b, \u0437\u043d\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043a \u043d\u0435\u0439 \u0434\u043e\u0441\u0442\u0443\u043f (\u0442.\u0435. \u0437\u043d\u0430\u0435\u0442 \u0441\u0432\u043e\u0439 \u043f\u0430\u0440\u043e\u043b\u044c \u043e\u0442 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043f\u043e\u0447\u0442\u044b) \u0438 \u0437\u043d\u0430\u0435\u0442 \u043e\u0442\u0432\u0435\u0442\u044b \u043d\u0430 \u0441\u0435\u043a\u0440\u0435\u0442\u043d\u044b\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b. \u00ab\u0417\u043d\u0430\u043d\u0438\u0435\u00bb \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u043e\u0434\u043d\u0438\u043c \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u043c \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438; \u0434\u0432\u0443\u043c\u044f \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0451\u043d\u043d\u044b\u043c\u0438 \u0444\u0430\u043a\u0442\u043e\u0440\u0430\u043c\u0438 \u044f\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u0442\u043e, \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97640,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97639","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Allt du ville veta om s\u00e4ker \u00e5terst\u00e4llning av l\u00f6senord. Del 2 | ProHoster","description":"Tv\u00e5faktorsautentisering Allt du har l\u00e4st p\u00e5 f\u00f6rsta delen handlar om identifiering utifr\u00e5n det som.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u0441\u0451, \u0447\u0442\u043e \u0432\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u0437\u043d\u0430\u0442\u044c \u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u043c \u0441\u0431\u0440\u043e\u0441\u0435 \u043f\u0430\u0440\u043e\u043b\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 2 | ProHoster","og:description":"\u0414\u0432\u0443\u0445\u0444\u0430\u043a\u0442\u043e\u0440\u0430\u044f \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u0412\u0441\u0451 \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u043d\u043d\u043e\u0435 \u0432\u0430\u043c\u0438 \u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u043a\u0430\u0441\u0430\u043b\u043e\u0441\u044c \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0438 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e.","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-20T00:42:56+00:00","article:modified_time":"2020-10-20T00:42:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97639","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:16:25","updated":"2022-10-03 07:14:42","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/97639","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=97639"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/97639\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/97640"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=97639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=97639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=97639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}