{"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\/da\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","title":{"rendered":"Alt, hvad du ville vide om sikrende nulstilling af adgangskoder. Del 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

To-faktor autentificering<\/h2>\n

\nAlt, hvad du har l\u00e6st i f\u00f8rste del<\/a><\/noindex> handler om identifikation baseret p\u00e5, hvad anmoderen kender<\/em><\/strong>. Han kender sin e-mailadresse, ved, hvordan man f\u00e5r adgang til den (dvs. kender sin e-mail-adgangskode) og ved svarene p\u00e5 de hemmelige sp\u00f8rgsm\u00e5l. <\/p>\n

\u00abViden\u00bb betragtes som en autentificeringsfaktor; to andre almindelige faktorer er hvad du har<\/em><\/strong>, s\u00e5som en fysisk enhed, og hvem du er<\/em><\/strong>, s\u00e5som fingeraftryk eller iris-scanning.<\/p>\n

\"Alt,
\n<\/a><\/noindex>
\nI de fleste tilf\u00e6lde er biologisk identifikation sv\u00e6rt at implementere, is\u00e6r n\u00e5r vi taler om sikkerheden ved webapplikationer, s\u00e5 ved to-faktor autentificering (two factor authentication, 2FA) anvendes normalt den anden attribut \u2014 \u00abhvad du har\u00bb. En popul\u00e6r mulighed for denne anden faktor er et fysisk token, for eksempel, RSA SecurID<\/a><\/noindex>:<\/p>\n

\"Alt,
\nEt fysisk token bruges ofte til autentificering i virksomhedernes VPN og finansielle tjenester. For at autentificere dig i tjenesten skal du anvende b\u00e5de adgangskoden og koden p\u00e5 tokenet (som ofte \u00e6ndres) i kombination med en PIN. Teoretisk set, for at identificere en angriber, skal de kende adgangskoden, have tokenet og ogs\u00e5 kende tokenets PIN. I scenariet for nulstilling af adgangskoden er selve adgangskoden \u00e5benlyst ukendt, men besiddelse af tokenet kan bruges til at bekr\u00e6fte ejerskabet af kontoen. Naturligvis, som med enhver implementering af sikkerhed, giver det ikke \u00abidiotsikring\u00bb<\/a><\/noindex>, men h\u00e6ver bestemt adgangsbarrieren.<\/p>\n

Et af de st\u00f8rste problemer med denne tilgang er omkostningerne og logistikken ved implementering; vi taler om at skulle levere fysiske enheder til hver kunde og tr\u00e6ne dem i den nye proces. Desuden skal brugerne have enheden med sig, hvilket ikke altid er tilf\u00e6ldet med et fysisk token. En anden mulighed er at implementere den anden faktor af autentificering via SMS, som i 2FA kan fungere som bekr\u00e6ftelse p\u00e5, at den person, der udf\u00f8rer nulstillingsprocessen, har ejerens mobiltelefon. S\u00e5dan g\u00f8r Google:<\/p>\n

\"Alt,
\nDet er ogs\u00e5 n\u00f8dvendigt at aktivere to-trins verifikation<\/a><\/noindex>, men det betyder, at din mobiltelefon kan blive den anden faktor for autentificering ved n\u00e6ste nulstilling af adgangskoden. Lad mig demonstrere dette med min iPhone af grunde, der snart vil blive klare:<\/p>\n

\"Alt,
\nEfter identifikation af e-mailadressen til Google-kontoen, konstaterer systemet, at 2FA er aktiveret, og vi kan nulstille kontoen ved hj\u00e6lp af verifikation, der sends via SMS til ejerens mobiltelefon:<\/p>\n

\"Alt,
\nNu skal vi v\u00e6lge, hvordan vi vil starte nulstillingsprocessen:<\/p>\n

\"Alt,
\nDenne handling f\u00f8rer til, at der sendes en e-mail til den registrerede adresse:<\/p>\n

\"Alt,
\nDenne e-mail indeholder URL'en til nulstillingen:<\/p>\n

\"Alt,
\nN\u00e5r man tilg\u00e5r URL'en til nulstillingen, sendes der en SMS, og webstedet beder om at indtaste den:<\/p>\n

\"Alt,
\nHer er SMS'en:<\/p>\n

\"Alt,
\nEfter at have indtastet den i browseren, vender vi tilbage til siden for klassisk nulstilling af adgangskoden:<\/p>\n

\"Alt,
\nDette virker m\u00e5ske lidt omst\u00e6ndeligt, og det er det, men formen bekr\u00e6fter, at personen, som nulstiller, har adgang til b\u00e5de e-mailadressen og mobiltelefonen til ejerens konto. Men dette kan v\u00e6re op til ni gange mere sikkert end at nulstille adgangskoden kun via e-mail. Dog er der nogle problemer...<\/p>\n

Problemet handler om smartphones. Enheden, der vises nedenfor, kan kun autentificere \u00e9n faktor for autentificering \u2014 den kan modtage SMS, men ikke e-mails:<\/p>\n

\"Alt,
\nMen denne enhed kan modtage SMS'er og<\/em> modtage e-mails om nulstilling af adgangskoden:<\/p>\n

\"Alt,
\nProblemet er, at vi betragter e-mail som den f\u00f8rste faktor for autentificering, og SMS (eller endda en token-genererende app) som den anden, men i dag er de samlet p\u00e5 \u00e9n enhed. Det betyder naturligvis, at hvis nogen f\u00e5r fat i din smartphone, vil al denne bekvemmelighed f\u00f8re til, at vi igen er tilbage p\u00e5 \u00e9n kanal; denne anden faktor \u00abden, du har\u00bb betyder, at du ogs\u00e5 har den f\u00f8rste faktor. Og alt dette beskyttes med en PIN-kode best\u00e5ende af fire cifre\u2026 hvis der overhovedet er en PIN-kode p\u00e5 telefonen. og<\/em> den var l\u00e5st.<\/p>\n

Ja, den implementerede Google-funktion 2FA leverer bestemt ekstra beskyttelse, men den er ikke beskyttet \u00abmod dummies\u00bb, og den afh\u00e6nger bestemt ikke af to helt autonome kanaler.<\/p>\n

Nulstilling via brugernavn versus nulstilling via e-mailadresse<\/h2>\n

\nSkal man kun tillade nulstilling via e-mail? Eller skal brugeren have mulighed for ogs\u00e5 at nulstille med sit navn? Problemet med nulstilling med brugernavn er, at der ikke er nogen m\u00e5de at underrette brugeren om et forkert brugernavn, uden at afsl\u00f8re<\/em> at nogen anden kan have en konto med det navn. I det forrige afsnit sikrede nulstilling via e-mail, at den legitime ejer af denne e-mail altid ville modtage feedback uden offentligg\u00f8relse af dens eksistens i systemet. Det er ikke muligt kun at g\u00f8re det med brugernavnet.<\/p>\n

S\u00e5 svaret er kort: kun e-mail. Hvis du fors\u00f8ger at nulstille kun med brugernavnet, vil der opst\u00e5 tilf\u00e6lde, hvor brugeren er forvirret over, hvad der er sket, eller<\/em> for du vil afsl\u00f8re eksistensen af konti. Ja, det er kun et brugernavn og ikke en e-mail-adresse, og ja, enhver kan v\u00e6lge et hvilket som helst (tilg\u00e6ngeligt) brugernavn, men der er stadig en stor sandsynlighed for, at du indirekte afsl\u00f8rer ejerne af konti p\u00e5 grund af brugernes tendens til at genbruge navne.<\/p>\n

Hvad sker der s\u00e5, n\u00e5r nogen glemmer deres brugernavn? Hvis vi antager, at brugernavnet ikke er straks e-mail-adressen (hvilket ofte er tilf\u00e6ldet), s\u00e5 ligner processen det, der sker ved nulstilling af adgangskoden \u2014 indtastning af e-mail-adressen og derefter sending af en besked til denne adresse uden at afsl\u00f8re dens eksistens. Den eneste forskel er, at denne gang indeholder beskeden kun brugernavnet og ikke en URL til nulstilling af adgangskode. Eller ogs\u00e5 vil der st\u00e5 i e-mailen, at der ikke er nogen konto for denne adresse.<\/p>\n

Identitetskontrol og n\u00f8jagtighed af e-mail-adresser<\/h2>\n

\nEn central aspekt af nulstilling af adgangskoder, og faktisk m\u00e5ske den<\/em> vigtigste aspekt er at verificere identiteten af den person, der fors\u00f8ger at nulstille. Er det faktisk den legitime ejer af kontoen, eller fors\u00f8ger nogen at hacke den eller p\u00e5f\u00f8re ejeren besv\u00e6r?<\/p>\n

Det er tydeligt, at e-mail er den mest bekvemme og udbredte kanal til identitetsbekr\u00e6ftelse. Den er ikke beskyttet mod uforsigtig h\u00e5ndtering (\"fra en amat\u00f8r\"), og der er mange tilf\u00e6lde, hvor det blot at kunne modtage e-mails p\u00e5 kontoejerens adresse ikke er tilstr\u00e6kkeligt, hvis der kr\u00e6ves en h\u00f8j grad af sikkerhed i identifikationen (deraf brugen af 2FA), men den er n\u00e6sten altid startpunktet i nulstillingsprocessen.<\/p>\n

Hvis e-mail skal spille en rolle i at sikre tillid, er det f\u00f8rste, man skal g\u00f8re, at sikre, at e-mailadressen faktisk er korrekt. Hvis nogen har fejlet et tegn, vil nulstillingen tydeligvis ikke starte. E-mail-verifikationsprocessen ved registrering er en p\u00e5lidelig metode til at kontrollere e-mailadressens rigtighed. Vi har alle set det i praksis: du registrerer dig, du f\u00e5r sendt en e-mail med et unikt URL, som du skal klikke p\u00e5, hvilket bekr\u00e6fter, at du faktisk er ejer af denne e-mailkonto. Manglende adgang til systemet, indtil denne proces er afsluttet, sikrer motivationen for at bekr\u00e6fte adressen.<\/p>\n

Som med mange andre aspekter af sikkerhed reducerer en s\u00e5dan model brugervenligheden i bytte for en h\u00f8jere grad af sikkerhed med hensyn til at have tillid til brugerens identitet. Dette kan v\u00e6re acceptabelt for en hjemmeside, som brugeren s\u00e6tter stor pris p\u00e5, og villigt vil tilf\u00f8je et ekstra skridt i processen (betalte tjenester, bankvirksomhed osv.), men s\u00e5danne tiltag kan afskr\u00e6kke brugeren, hvis de ser kontoen som \"engangs\" og bruger den f.eks. bare som et middel til at kommentere et indl\u00e6g.<\/p>\n

Identifikation af den, der har initieret nulstillingsprocessen<\/h2>\n

\nDet er tydeligt, at der er grunde til ondsindet brug af nulstillingsfunktionen, og angribere kan udnytte den p\u00e5 mange forskellige m\u00e5der. Et enkelt trick, som vi kan bruge til at bekr\u00e6fte anmodningens kilde (dette trick virker normalt<\/em> \u2014 er at tilf\u00f8je anmoders IP-adresse i e-mailen med nulstillingsanmodningen. Dette giver modtageren nogle<\/em> oplysninger til at identificere anmodningens kilde.<\/p>\n

Her er et eksempel fra nulstillingsfunktionen, som jeg i \u00f8jeblikket implementerer i ASafaWeb:<\/p>\n

\"Alt,
\nLinken \u00abfind out more\u00bb (\u00abFind out more\u00bb) f\u00f8rer brugeren til en hjemmeside ip-adress.com<\/a><\/noindex>, som giver oplysninger som placering og organisationen bag anmodningen om nulstilling:<\/p>\n

\"Alt,
\nSelvf\u00f8lgelig har enhver, der \u00f8nsker at skjule sin identitet, adskillige m\u00e5der at obfuskere sin reelle IP-adresse p\u00e5, men dette er en praktisk m\u00e5de at tilf\u00f8je delvis identifikation af anmoderen, og i de fleste<\/em> tilf\u00e6lde vil det give dig en tilstr\u00e6kkelig id\u00e9 om, hvem der foretager anmodningen om nulstilling af adgangskoden.<\/p>\n

Underretning om \u00e6ndringer via e-mail<\/h2>\n

\nDette indl\u00e6g er gennemsyret af \u00e9t tema \u2014 kommunikation; informer kontohaveren s\u00e5 meget som muligt om, hvad der sker p\u00e5 hvert trin af processen, uden at afsl\u00f8re noget, der kan misbruges. Det samme g\u00e6lder for situationen, hvor adgangskoden faktisk er blevet \u00e6ndret \u2014 inform\u00e9r kontohaveren!<\/em><\/strong><\/p>\n

\u00c5rsagerne til at \u00e6ndre adgangskoden kan komme fra to kilder:<\/p>\n

    \n
  1. \u00c6ndring af adgangskoden efter login, fordi brugeren \u00f8nsker en ny adgangskode<\/li>\n
  2. Nulstilling af adgangskoden uden login, fordi brugeren har glemt den<\/li>\n<\/ol>\n

    \nSelvom dette indl\u00e6g hovedsageligt handler om nulstilling, reducerer en underretning i det f\u00f8rste tilf\u00e6lde risikoen for, at nogen \u00e6ndrer adgangskoden uden at den retm\u00e6ssige ejer er informeret. Hvordan kan det ske? Et almindeligt scenarie er, at en angriber f\u00e5r adgang til den lovlige ejers password (et genbrugt password, som er blevet l\u00e6kket fra en anden kilde; et password, der er opn\u00e5et ved keylogging; et let g\u00e6ttepassword osv.), hvorefter de beslutter at \u00e6ndre det og derved blokere ejeren. Uden e-mail-besked vil den faktiske ejer ikke vide noget om \u00e6ndringen af adgangskoden.<\/p>\n

    Selvf\u00f8lgelig b\u00f8r ejeren i tilf\u00e6lde af nulstilling allerede have igangsat processen selv (eller omg\u00e5 de identitetsbekr\u00e6ftelsesmetoder, der er beskrevet ovenfor), s\u00e5 \u00e6ndringen burde ikke<\/em> overraske ham, men en bekr\u00e6ftelse via e-mail ville v\u00e6re en positiv feedback og en yderligere kontrol. Derudover sikrer det konsistens med det ovenfor beskrevne scenarie.<\/p>\n

    \u00c5h, og i tilf\u00e6lde af at det endnu ikke er tydeligt \u2014 send ikke den nye adgangskode via e-mail!<\/em><\/strong> Det kan f\u00e5 nogle til at grine, men s\u00e5danne ting sker<\/a><\/noindex>:<\/p>\n

    \"Alt,<\/p>\n

    Logs, logs, logs og lidt flere logs<\/h2>\n

    \nFunktionen til nulstilling af adgangskoder er tiltr\u00e6kkende for angribere: en angriber \u00f8nsker enten at f\u00e5 adgang til en anden persons konto eller blot for\u00e5rsage ulempe for ejeren af kontoen\/systemet. Mange af de ovenfor beskrevne metoder kan reducere risikoen for misbrug, men de forhindrer dem ikke, og de vil bestemt ikke stoppe folk i at fors\u00f8ge at bruge funktionen p\u00e5 en uautoriseret m\u00e5de.<\/p>\n

    En absolut uvurderlig praksis til at opdage ondsindet adf\u00e6rd er logging, og jeg mener meget detaljeret logging<\/em><\/strong>. Registrer mislykkede loginfors\u00f8g, nulstillingsanmodninger, \u00e6ndringer af adgangskoder (dvs. n\u00e5r brugeren allerede er logget ind) og n\u00e6sten alt, der kan hj\u00e6lpe dig med at forst\u00e5, hvad der sker; dette vil v\u00e6re meget nyttigt i fremtiden. Registrer endda separate dele<\/em> af processen, for eksempel b\u00f8r en god nulstillingsfunktion inkludere initiativet til at nulstille via hjemmesiden (registrer anmodningen og loginfors\u00f8g for nulstilling med et forkert brugernavn eller e-mail), registrer bes\u00f8get p\u00e5 nulstillings-URL'en (herunder fors\u00f8g p\u00e5 at bruge et forkert token), og log derefter succes eller fejl i svaret p\u00e5 det hemmelige sp\u00f8rgsm\u00e5l.<\/p>\n

    N\u00e5r jeg taler om logging, mener jeg ikke kun at registrere faktum om sideindl\u00e6sning, men ogs\u00e5 at indsamle s\u00e5 mange oplysninger som muligt, s\u00e5fremt de ikke er fortrolige<\/em><\/strong>. Folk, venligst undg\u00e5 at registrere adgangskoder i logs!<\/em><\/strong> I logs skal identiteten af den autoriserede bruger registreres (de vil v\u00e6re autoriseret, hvis de \u00e6ndrer<\/em> en eksisterende adgangskode eller fors\u00f8ger at nulstille en anden persons adgangskode<\/em> efter at v\u00e6re logget ind), enhver brugernavn eller e-mailadresse, de fors\u00f8ger, samt enhver nulstillings-token, de pr\u00f8ver at bruge. Men det er ogs\u00e5 v\u00e6rd at registrere aspekter som IP-adresser og, hvis muligt, endda anmodningsoverskrifter. Det giver dig mulighed for at genskabe ikke kun hvad<\/em> brugeren (eller angriberen) fors\u00f8ger at g\u00f8re, men ogs\u00e5 hvem<\/em> de er.<\/p>\n

    Delegere ansvar til andre udf\u00f8rere.<\/h2>\n

    \nHvis du mener, at alt dette udg\u00f8r en stor arbejdsbyrde, er du ikke alene. At bygge et p\u00e5lideligt system til kontoadministration er faktisk en kompliceret opgave. Det handler ikke om, at det er teknisk sv\u00e6rt; det rummer blot mange nuancer. Det handler ikke kun om nulstilling; der er en hel proces med registrering, sikker opbevaring af adgangskoder, behandling af adskillige forkerte loginfors\u00f8g osv. osv. Selvom jeg promoverer ideen om at bruge eksisterende funktionalitet s\u00e5som ASP.NET membership provider<\/a><\/noindex>, er der stadig meget mere, der skal g\u00f8res.<\/p>\n

    I dag findes der mange tredjepartsleverand\u00f8rer, som gerne tager sig af alle besv\u00e6rlighederne og abstraherer alt dette i \u00e9n administreret service. Blandt disse tjenester er OpenID, OAuth og endda Facebook. Nogle mennesker har ubegribelig tillid til denne model<\/a><\/noindex> (OpenID har faktisk vist sig at v\u00e6re meget succesfuld p\u00e5 Stack Overflow), mens andre bogstaveligt talt ser den som et mareridt<\/a><\/noindex>.<\/p>\n

    Uden tvivl l\u00f8ser en service som OpenID mange udviklerproblemer, men det er ogs\u00e5 helt klart, at den tilf\u00f8jer nye. Spiller de en rolle? Ja, men det er tydeligt, at vi ikke ser massivt brug af tjenester fra autentificeringsudbydere. Banker, flyselskaber og endda butikker \u2014 alle implementerer deres eget autentificeringssystem, og det er \u00e5benlyst, at der er meget gode grunde til dette.<\/p>\n

    Ondsindet nulstilling<\/h2>\n

    \nEn vigtig aspekt af hvert af de n\u00e6vnte eksempler er, at den gamle adgangskode kun anses for at v\u00e6re ubrugelig efter bekr\u00e6ftelsen af kontoejerens identitet<\/em><\/strong>. Det er vigtigt, fordi hvis en konto kunne nulstilles op til<\/em> uden identitetsbekr\u00e6ftelse, ville det give mulighed for alle mulige ondsindede handlinger.<\/p>\n

    Her er et eksempel: nogen deltager i budgivning p\u00e5 et auktionssite, og t\u00e6ttere p\u00e5 slutningen af budgivningen blokerer de konkurrenterne ved at starte nulstillingsprocessen, hvilket eliminerer dem fra budgivningen. Det er \u00e5benlyst, at hvis en d\u00e5rligt designet nulstillingsfunktion kan udnyttes forkert, kan det f\u00f8re til alvorlige negative konsekvenser. Det er v\u00e6rd at bem\u00e6rke, at blokering af konti via forkerte loginfors\u00f8g er en lignende situation, men det er allerede et emne for et andet indl\u00e6g.<\/p>\n

    Som jeg n\u00e6vnte f\u00f8r, hvis man giver anonyme brugere mulighed for at nulstille adgangskoden til enhver konto blot ved at kende dens e-mailadresse, s\u00e5 er det en oplagt situation for et 'Denial of Service'-angreb. Det er m\u00e5ske ikke den type, vi plejer at tale om, men der er ikke nogen hurtigere m\u00e5de at blokere adgangen til en konto p\u00e5 end gennem en d\u00e5rligt gennemt\u00e6nkt nulstillingsfunktion. DoS<\/a><\/noindex>, som vi kender det, men der er ikke nogen hurtigere m\u00e5de at blokere adgangen til en konto p\u00e5 end gennem en d\u00e5rligt gennemt\u00e6nkt nulstillingsfunktion.<\/p>\n

    Det svageste led<\/h2>\n

    \nN\u00e5r vi taler om beskyttelse af \u00e9n konto, er det hele s\u00e5 fantastisk, men man skal altid huske p\u00e5 \u00f8kosystemet, der omgiver den konto, man beskytter. Lad mig give et eksempel:<\/p>\n

    ASafaWeb er hostet p\u00e5 en fantastisk service, der leveres af AppHarbor. Processen for nulstilling af hostingkontoen forl\u00f8ber s\u00e5dan her:<\/p>\n

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

    \"Alt,
    \nTrin 2:<\/strong><\/p>\n

    \"Alt,
    \nTrin 3:<\/strong><\/p>\n

    \"Alt,
    \nTrin 4:<\/strong><\/p>\n

    \"Alt,
    \nEfter at have l\u00e6st al den forudg\u00e5ende information er det allerede nemt at forst\u00e5, hvilke aspekter vi i en ideel verden ville implementere anderledes. Men her vil jeg sige, at hvis jeg offentligg\u00f8r en hjemmeside som ASafaWeb p\u00e5 AppHarbor, og derefter finder p\u00e5 fremragende hemmelige sp\u00f8rgsm\u00e5l og svar, tilf\u00f8jer to-faktor-autentificering og g\u00f8r alt andet korrekt, fjerner det ikke det faktum, at det svageste led i hele processen vil v\u00e6re i stand til at bryde alt dette. Hvis nogen lykkes med at autentificere sig i AppHarbor ved at bruge mine oplysninger, vil de kunne \u00e6ndre adgangskoden til enhver ASafaWeb-konto til hvad de \u00f8nsker!<\/p>\n

    Pointen er, at robustheden af beskyttelsesimplementeringen skal betragtes holistisk: man skal modellere truslerne ved hver indgangspunkt i systemet, selvom det er en overfladisk proces, for eksempel login i AppHarbor. Dette b\u00f8r give mig et godt indblik i, hvor meget arbejde jeg skal investere i nulstillingsprocessen for ASafaWeb.<\/p>\n

    Sammens\u00e6t det hele<\/h2>\n

    \nDette indl\u00e6g indeholder en stor m\u00e6ngde information, s\u00e5 jeg vil fors\u00f8ge at koncentrere det i et enkelt visuelt diagram:<\/p>\n

    \"Alt,
    \nHusk p\u00e5, at der skal f\u00f8res s\u00e5 detaljere logning som muligt for hver af disse punkter. Det er det hele, det er enkelt!<\/p>\n

    Resum\u00e9<\/h2>\n

    \nMit indl\u00e6g virker omfattende, men der findes mange ekstra materialer, som jeg kunne<\/em> inkludere det, men besluttede at frase dette for korthedens skyld: rollen som adresse til den rednings-email, situationen hvor du mister adgangen til den tilknyttede email (for eksempel, hvis du sagde op fra jobbet) og s\u00e5 videre. Som jeg sagde tidligere, er nulstillingsfunktionen ikke s\u00e5 kompleks, men der er mange synspunkter p\u00e5 den.<\/p>\n

    Selv om nulstilling ikke er s\u00e5 sv\u00e6rt, implementeres det ofte forkert. Ovenfor har vi set et par eksempler, hvor implementeringen kan<\/em> f\u00f8re til problemer, og der er mange flere pr\u00e6cedenser, hvor fejlagtig nulstilling faktisk<\/em> for\u00e5rsagede problemer. Det blev for nylig afsl\u00f8ret, at nulstillingen af adgangskoder blev brugt til at stj\u00e6le bitcoins for 87 tusinde dollars<\/a><\/noindex>. Det er et alvorligt negativt resultat!<\/p>\n

    S\u00e5 v\u00e6r forsigtig med dine nulstillingsfunktioner, modell\u00e9r truslerne<\/a><\/noindex> p\u00e5 forskellige punkter, og n\u00e5r du designer funktionen, skal du ikke tage din sorte hat af, for der er en stor sandsynlighed for, at den vil blive b\u00e5ret af nogen andre!<\/p>\n

    <\/p>\n

    Annoncering<\/h4>\n

    \nVDSina<\/b> tilbyder billige servere til leje<\/a><\/noindex> med daglig betaling, hver server er tilsluttet et internet link p\u00e5 500 megabit og er gratis beskyttet mod DDoS-angreb!<\/p>\n

    \"Alt,<\/a><\/noindex>
    \n
    Kilde:     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\udd47Alt, hvad du \u00f8nskede at vide om sikker nulstilling af adgangskoder. Del 2 | ProHoster","description":"To-faktor autentifikation Alt, hvad du har l\u00e6st i den f\u00f8rste del, handlede om identifikation baseret p\u00e5 det,","canonical_url":"https:\/\/prohoster.info\/da\/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":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/97639","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=97639"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/97639\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/97640"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=97639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=97639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=97639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}