Share
För de flesta webbplatser har du olika områden inom den (hemsida, användarprofil, administratörssida, etc.), varav några kommer att vara offentliga och andra måste begränsas till endast vissa användare. Du vill ofta identifiera användare så att du kan tillhandahålla anpassat innehåll eller att fånga in specifik information från en användare. Många webbplatser måste också skydda en del av webbplatsen, till exempel ett administrativt område för att upprätthålla och uppdatera innehållet på webbplatsen. På en CMS-webbplats kan vissa användare skapa innehåll, men andra måste godkänna det innehållet innan det visas för allmänheten.
Oavsett behovet kräver begränsning eller anpassning att identifiera varje användare som använder din webbplats. För en webbsidor som är avsedd för allmänna användare, råder användarnamnet och lösenordet till stor del för att det inte finns något bättre alternativ. Det finns andra alternativ om du arbetar i speciella miljöer, till exempel ett företags intranät, där du har viss kontroll över besökarna på webbplatsen.
Medan ett vanligt behov hanteras, loggas och lösenord ofta hanteras på ett sätt som lämnar webbplatsen och dess användare, onödigt mer sårbar för säkerhetsattacker. Genom att följa några bästa metoder kan du bättre skydda din webbplats och dess innehåll från hackare. Konsekvenserna av dåligt skydd kan vara allvarliga. Föreställ dig en webbplats där någon användare kunde lägga in innehåll som tycktes vara från företaget på grund av dålig lösenordshantering eller en nätbutik där någon användare kunde se alla beställningar som placerades på webbplatsen.
Låt oss ta en titt på några säkerhetshänsyn när du arbetar med inloggningar och lösenord på dina webbplatser.
Inloggningen består av ett användarnamn som identifierar dig, och ett lösenord som validerar dig är den användare du påstår att vara. Webbplatser tillåter ofta användaren att antingen ange ett användarnamn eller använd användarens e-postadress som sitt användarnamn.
E-postmeddelanden ändras inte ofta och de flesta webbplatser samlar redan denna information, så användaren kommer också mindre sannolikt att glömma deras e-post än ett användarnamn de skapade. E-postmeddelandet kommer också automatiskt att vara unikt eftersom användare sällan delar ett e-postkonto och de som gör det, skulle sannolikt inte vilja ha separata konton.
Nackdelarna till ett email inkluderar att två personer som delar ett e-postmeddelande inte kan ha separata konton. Om din webbplats har en legitim anledning till att en person har flera konton, kan det hända att det inte går att göra det med e-postmeddelanden, men det är lättare att implementera med användarnamn. Det är troligt att ett e-postmeddelande är lättare att hacka eftersom en användare brukar använda samma e-postadress på varje sida, men majoriteten av användarnamn kommer sannolikt inte att vara mycket svårare att hacka, eftersom användarna brukar återanvända användarnamn lika mycket som de återanvända lösenord.
Om du inte har en specifik anledning att undvika en e-postadress, föredra e-postadressen för användarnamnet för inloggning. Användningen av e-postmeddelandet har också blivit normen på webbplatser. Glöm inte, för att ge en e-postbaserad inloggning med ett sätt att ändra e-postmeddelandet. Utan denna funktion skulle en användare behöva skapa ett nytt konto och förlora alla tidigare historier bara för att de ändrade Internetleverantörer eller förlorade ett tidigare konto på grund av examen eller byta jobb, vilket ledde till att deras gamla e-post gick bort.
Var alltid försiktig när du använder e-post som inloggning för att inte visa den offentligt, av både integritetsskäl och problem med spamförebyggande.
Inloggningssidan på din webbplats kommer att vara den första punkten för forskning för en hackare. Hackaren kommer att försöka fastställa giltiga konton som finns på en webbplats. Att hantera inloggningssidan på rätt sätt gör hackarens jobb svårare. För att börja bör du minimera mängden data som en felaktig inloggning ger till en angripare. Din första tanke när någon kommer in i ett användarnamn som inte känns igen kan vara att ge ett användbart meddelande om att de ska kontrollera sitt användarnamn. Du kan skapa en säkrare sida genom att visa samma felmeddelande när användarnamnet inte hittades och när lösenordet inte matchar lösenordet för den angivna användaren. Meddelandet ska indikera att kombinationen av användarnamn och lösenord inte var korrekt, för att låta användaren veta att verifiera båda bitarna av information, inte bara den ena eller den andra.
Om din webbplats använder e-post för användarnamnet för inloggning kan en angripare enkelt validera om en användare har ett konto till din tjänst om du returnerar ett annat meddelande för en okänd inloggning jämfört med ett misslyckat användarnamn och lösenordskombination. Det gör sakerna lite mindre lämpliga för användaren, men den extra säkerheten är normalt bättre avvägning.
Som noterat ökar trafiken det specifika meddelandet för ett ogiltigt användarnamn för en sämre användarupplevelse. Ett meddelande om att en inloggning inte existerar kommer att hjälpa användaren att märka typsnitt som att skriva john istället för jon lättare. Det meddelandet hjälper också en användare som inte kommer ihåg vilket användarnamn de använde på din webbplats. Tänk på att dessa typer av meddelanden ger hackare ett enkelt och enkelt sätt att verifiera om en användare finns på din webbplats.
Du kan också hjälpa till med att följa en hackare genom att hantera flera inloggningsförsök bättre. Olyckligtvis misstänker ett användarnamn eller lösenord mer än en gång ganska vanligt från ett felaktigt tecken, transponerar två tecken eller använder lösenordet för en annan webbplats i stället för rätt lösenord. Om du tillåter obegränsat inloggningsförsök öppnas dörren till en brute force attack av att försöka användarnamn och lösenord flera gånger för att bestämma rätt inloggning. Automatiserade verktyg och skript påskyndar processen så att en hacker kan fungera metodiskt genom många potentiella lösenord tills du hittar rätt inloggning.
Att introducera en ökad fördröjningstid efter varje misslyckat inloggningsförsök hjälper också foliehackare. Det första inloggningsförsöket sker normalt. Den andra inloggningen försenas en bråkdel av en sekund innan resultatet återges. Ytterligare försök försenas alltmer längre innan de återvänder ett svar. Denna fördröjning möjliggör minimal störning för en legitim användare som har gjort ett misstag, men saktar ner hackaren som försöker att brute tvinga platsen.
För mer känslig data kan ett starkare tillvägagångssätt vidtas genom att låsa kontot efter ett antal misslyckade försök. Låsning av kontot inaktiverar det antingen tillfälligt eller permanent. Låsningen stoppar brutta kraftattacker som efter en punkt, kommer inloggningen inte att fungera. En tillfälligt inaktiverande ska ha minimal inverkan på användaren så länge som ett meddelande av orsaken till låsningen visas. Ett permanent lås kräver att användaren kontaktar support för att åtgärda problemet och passar bättre inloggningar och skyddar viktiga data.
Lösenord är den känsligaste delen av inloggningen. Spara aldrig lösenord i vanlig text. Aldrig. Någonsin. Detta innebär att nästan alla säkerhetsproblem kan avslöja inloggningsinformation. Även krypterade lösenord bör undvikas som om hackaren får tillgång till krypterad data, och dekrypteringsprocessen kan vara mycket enklare. Varje lagring där du kan hämta ett lösenord gör det lättare för en hackare att göra detsamma.
Lösenorden ska lagras saltad och hashed. Ett salt är ett slumpmässigt genererat, unikt värde lagrat för varje inloggning och lagts till före hash. Att lägga till saltet hindrar identiska lösenord från att ha samma hash och förhindrar en hacker från att bygga en lista över hashresultatet av möjliga lösenordskombinationer i förväg. Genom att lägga till slumpmässig hash, ett lösenord för abc123 (använd aldrig någonting som ett verkligt lösenord) resultera i en annan hash för varje användare.
En hashfunktion gör lösenordet till ett fastlängdsvärde. Det finns funktioner som är särskilt utformade för lösenord som PBKDF2 eller Bcrypt. GPU-processorerna i moderna grafikkort kan utföra beräkningarna som behövs för hash och burk ha sönder många svaga algoritmer snabbt. Dedikerade maskiner för att bryta lösenord kan bestämma alla åtta tecken lösenord eller mindre på under sex timmar.
Användare brukar ofta använda samma lösenord för de flesta webbplatser där de har konton. Många webbplatser har börjat testa de exponerade referenserna från stora kontoinloggningshackar mot sina egna inloggningar och kontakta användare vars användarnamn och lösenordskombinationer matchar. Evernote och Facebook undersökte nyligen inloggningsuppgifter från Adobe och varnade användare med samma uppgifter.
Det enklaste sättet att hantera lösenord korrekt är att använda verktygen som ingår i din webbram. Lösenordsäkerhet är komplicerat och att bara en sak fel kan låta användarens lösenord öppna för attack. pH-pass ger ett offentligt domänbibliotek för PHP med hjälp av Bcrypt. De äldre inbyggda .NET-medlemskapsleverantörerna använde svagare hash, men de nya universella leverantörerna använder PBKDF2. Rails ger också en Bcrypt pärla.
När du korrekt säkra lösenord så att de inte kan hämtas, förlorar du möjligheten att ge användaren ett glömt lösenord. Då måste du tillhandahålla ett alternativt sätt för en användare som legitimt glömde sitt lösenord för att återställa lösenordet på ett säkert sätt.
En bra återställnings-lösenordssida gör att användaren kan ändra lösenordet utan att känna till det aktuella lösenordet. Den traditionella metoden låter användaren ange sin e-postadress och skickar sedan en länk till en webbsida som låter dem återställa lösenordet. Att skicka en länk är säkrare än att skicka ett lösenord eftersom det nya lösenordet inte skapades förrän användaren åtkomst till sidan. Om du skickar ett nytt lösenord via e-post skulle du skapa en ny behörighet som alla som avlyssnar e-postmeddelandet skulle kunna använda utan användarens kunskaper. Om någon avbryter e-postmeddelandet och återställer lösenordet kommer användaren att veta när de kommer åt och försöker återställa sitt lösenord.
En bra återställningssida ska inte heller ge validering om att ett konto finns. Logiken är densamma som vi diskuterade när det gäller att inte ge feedback om ett konto inte existerade vid inloggning. Även om inloggningen inte existerar i systemet. Det bästa sättet är att ge ett meddelande om att instruktioner har skickats till e-postadressen i filen. Du borde fortfarande skicka ett mail till det inmatade e-postmeddelandet eftersom det kan vara ett legitimt fall att ha glömt vilket e-postmeddelande som använts för ett konto, till exempel inmatning av ett arbetsmail i stället för en personlig e-post.
Länken för att återställa lösenord bör utformas så att återställningsbegäran har en begränsad livslängd och kan bara användas en gång. Skapa ett unikt token för varje återställningsförfrågan, kopplad till det begärda kontot och lagra det i en databas. Denna token blir en del av webbadressen som mailas för att återställa lösenordet. Teckenet bör också tilldelas en utgångstid och tas bort efter att återställningen är klar. Om någon försöker använda en token som redan har använts eller upphört, skulle förfrågan misslyckas. Utgångstiden måste vara tillräckligt lång för att tillåta e-postmeddelandet och användaren att slutföra åtgärden, men inte så länge att den tillåter användning för långt i framtiden. En tidsram på några timmar brukar vara tillräcklig.
Om du återställer ett lösenord med e-post gör det också att webbplatsens säkerhet är beroende av användarens e-postadress. Om e-posten kan nås kan den personen återställa lösenordet. Webbplatser kan lägga till säkerhetsfrågor som måste besvaras innan du återställer lösenordet. Säkerhetsfrågor ger lite extra säkerhet om svaren är lätta att hitta. En säkerhetsfråga om "Vad är min hemstad?" ger liten säkerhet om svaret finns på personens Facebook-profil. För mer om att utveckla goda frågor, se http://goodsecurityquestions.com/.
En inloggning och ett lösenord kräver endast ett par uppgifter för att komma åt en webbplats. När den informationen tillhandahålls antas användaren vara den rätta personen. För att göra stavningsuppgifter mindre effektiva kan du lägga till ett andra steg till autentiseringsprocessen. Förutom något som användaren vet (användarnamnet och lösenordet) måste användaren också använda något de har i sin nuvarande innehav, vanligtvis en mobiltelefon via antingen SMS eller en ansökan för detta ändamål.
Bankerna var förmodligen de första som genomförde processen genom att använda anpassad maskinvara för att generera en tidsberoende kod. Google populariserade användningen av sms-textmeddelanden eller en app som ett andra steg. Många webbplatser använder nu en inloggning som är kompatibel med Googles implementering av RFC 6238. Du kan hitta bibliotek som redan genomför denna teknik för de mest populära ramarna som ASP.NET, ASP.NET # 2, Ruby on Rails, PHP och Django..
För att undvika dessa problem har du ett annat alternativ, låt någon annan hantera allt detta genom att integrera med en tredje part för autentisering som Twitter, Facebook eller OpenID. Att göra det erbjuder fördelar och nackdelar. Det tar bort de flesta säkerhetsproblemen som vi har diskuterat här som någon annan hanterar dessa problem. Men dessa andra webbplatser är också förmodligen ett större hackermål än du. Om du använder en annan webbplats för att hantera autentisering, kan hackarna ha tillgång till din webbplats om den inloggningen äventyras.
Att använda en känd tredje part kan både hjälpa och skada ur rykte och social synvinkel. Fördelen med att tillåta inloggning med antingen Facebook eller Twitter är att så många användare redan har konton där att de skulle gärna använda den. Andra besökare kan se integrationen med dessa webbplatser som en negativ funktion och inte använda din webbplats på grund av den eller om det är det enda alternativet som de tillhandahåller.
Din webbapplikations inloggning spelar en viktig roll för att säkra din webbplats. Om du skyddar din inloggning kommer du att göra mycket för att skydda din webbplats, webbplatsens användare och deras privata uppgifter. För att arbeta säkert med inloggningar, minimera antalet data som dina inloggnings- och lösenordsåterställningssidor eventuellt kan ge till en hackare. Sätt också säkerhetsåtgärder för att göra det svårare att gissa din användares lösenord via brute force.
Att skydda lösenord är en kritisk angelägenhet för en webbplats. Dåligt skyddade lösenord gör hackarens jobb enklare och kan sluta med inloggningsuppgifterna på din webbplats som är utsatta för allmänheten. Att använda hackade och saltade lösenord gör hackarens jobb mycket svårare. Dessutom kan du lägga till alternativet för ett andra steg till inloggningsprocessen, vilket ger bättre skydd för webbplatsens användare. Du kan också välja att använda en tredje part för att hantera inloggningar på din webbplats.
Accentsconagua