Share
For de fleste nettsteder har du forskjellige områder innenfor det (hjemmeside, brukerprofil, admin side, etc.), hvorav noen vil være offentlige, og andre må være begrenset til bare bestemte brukere. Du vil ofte unikt identifisere brukere, slik at du kan gi tilpasset innhold eller å fange opp spesifikk informasjon fra en bruker. Mange nettsteder må også beskytte en del av nettstedet, for eksempel et administrativt område for å opprettholde og oppdatere innholdet på nettstedet. På et CMS-nettsted kan enkelte brukere kunne lage innhold, men andre må godkjenne det innholdet før det blir vist for allmennheten.
Uansett behovet, krever begrensning eller tilpasning å identifisere hver bruker som får tilgang til nettstedet ditt. For et Internett-vendt nettsted ment for generelle brukere, bruker brukernavnet og passordet fortsatt stor grad fordi det ikke er et bedre alternativ. Det finnes andre alternativer hvis du jobber i spesielle omgivelser, for eksempel et selskaps intranett, hvor du har litt kontroll over besøkende på nettstedet..
Mens et vanlig behov blir innlogging og passord ofte håndtert på en måte som forlater nettstedet og dets brukere, unødvendig mer utsatt for sikkerhetsangrep. Ved å følge noen gode fremgangsmåter, kan du bedre beskytte nettstedet ditt og dets innhold fra hackere. Konsekvensene av dårlig beskyttelse kan være alvorlige. Tenk deg et nettsted der en bruker kunne legge inn innhold som syntes å være fra firmaet på grunn av dårlig passordbehandling eller en nettbutikk hvor noen bruker kunne se alle bestillinger plassert på nettstedet.
La oss ta en titt på noen få sikkerhetshensyn mens du jobber med pålogginger og passord på nettsteder.
Påloggingen består av et brukernavn som identifiserer deg, og et passord som bekrefter deg er brukeren du hevder å være. Nettsteder tillater ofte at brukeren enten angir et egendefinert brukernavn eller bruker brukerens e-postadresse som brukernavn.
E-postmeldinger endres ikke ofte, og de fleste nettsteder samler allerede denne informasjonen, slik at brukeren også vil være mindre sannsynlig å glemme e-posten enn et brukernavn de opprettet. E-posten vil også automatisk være unik fordi brukere sjelden deler en e-postkonto, og de som gjør det, vil sannsynligvis ikke ha separate kontoer.
Ulemperne til en e-post inkluderer at to personer som deler en e-post, ikke kan ha separate kontoer. I tillegg, hvis nettstedet ditt har en legitim grunn til at en person har flere kontoer, er dette kanskje ikke mulig med e-post, men enklere å implementere ved bruk av brukernavn. Det er også sannsynlig at en e-post er lettere å hacke siden en bruker sannsynligvis bruker den samme e-posten på hvert nettsted, men de fleste brukernavnene vil sannsynligvis ikke være mye vanskeligere å hacke, siden brukerne pleier å gjenbruke brukernavn like mye som de gjenbruker passord.
Med mindre du har en bestemt grunn til å unngå en e-postadresse, foretrekker du e-postadressen for brukernavnet. Bruken av e-posten har også blitt normen på nettsteder. Ikke glem å gi en e-postbasert pålogging med en måte å endre e-posten på. Uten denne funksjonen vil en bruker måtte opprette en ny konto og miste all tidligere historie, bare fordi de forandret Internett-leverandører eller mistet en tidligere konto på grunn av oppgradering eller endring av jobber, og forårsaket at den gamle e-posten gikk bort.
Vær alltid forsiktig når du bruker e-post som logg inn for ikke å vise det offentlig, av både personvernsårsaker og spamforebyggende problemer.
Innloggingssiden til nettstedet ditt vil være det første punktet for forskning for en hacker. Hackeren vil forsøke å fastslå gyldige kontoer som eksisterer på et nettsted. Ved å håndtere innloggingssiden, blir hackerens jobb vanskeligere. For å starte, bør du minimere mengden data som et mislykket innlogging gir til en angriper. Din opprinnelige tanke når noen går inn i et brukernavn som ikke er gjenkjent, kan være å gi en nyttig melding om at de skal sjekke brukernavnet sitt. Du kan gi en sikrere side ved å vise samme feilmelding når brukernavnet ikke ble funnet og når passordet ikke samsvarer med passordet for den oppgitte brukeren. Meldingen skal indikere at kombinasjonen av brukernavn og passord ikke var korrekt, for å la brukeren vite om å verifisere begge deler av informasjonen, ikke bare den ene eller den andre.
Hvis nettstedet ditt bruker e-post for påloggingsnavnet, kan en angriper enkelt validere hvis en bruker har en konto til tjeneste hvis du returnerer en annen melding for et ukjent innlogging i forhold til en mislykket brukernavn og passordkombinasjon. Det gjør ting litt mindre praktisk for brukeren, men den ekstra sikkerheten er vanligvis den bedre handel.
Som nevnt, tok vekk den spesifikke meldingen for et ugyldig brukernavn, økt sikkerhet for en verre brukeropplevelse. Å gi en melding om at en pålogging ikke eksisterer, vil hjelpe brukeren å legge merke til typoer som å skrive john i stedet for jon lettere. Denne meldingen hjelper også en bruker som ikke husker hvilket brukernavn de brukte på nettstedet ditt. Husk at disse typer meldinger gir hackere en enkel og enkel måte å bekrefte om en bruker eksisterer på nettstedet ditt.
Du kan også bidra til å folie en hacker ved å bedre håndtere flere påloggingsforsøk. Ulykkelig feilyping av brukernavn eller passord mer enn en gang forekommer ganske vanlig fra et feilaktig tegn, transponerer to tegn, eller bruker passordet for et annet nettsted i stedet for riktig passord. Å tillate ubegrensede påloggingsforsøk åpner døren for et brutalt kraftangrep ved å prøve brukernavn og passord gjentatte ganger for å bestemme riktig innlogging. Automatiserte verktøy og skript øker prosessen slik at hacker kan metodisk arbeide gjennom mange potensielle passord, til du finner riktig innlogging.
Å introdusere en økende forsinkelsestid etter hvert mislyktes påloggingsforsøk hjelper også foliehackere. Det første påloggingsforsøket skjer normalt. Den andre påloggingen er forsinket en brøkdel av et sekund før du returnerer resultatet. Ytterligere forsøk blir forsinket stadig lenger før de returnerer et svar. Denne forsinkelsen tillater minimal forstyrrelse for en legitim bruker som har gjort en feil, men bremser hackeren som forsøker å ødelegge nettstedet.
For mer sensitive data, kan en sterkere tilnærming bli tatt ved å låse ut kontoen etter en rekke mislykkede forsøk. Låser kontoen deaktiverer den enten midlertidig eller permanent. Lockout stopper brute force angrep som etter et punkt, vil påloggingen ikke fungere. En midlertidig deaktivering bør ha minimal innvirkning på brukeren så lenge en melding om årsaken til låsen ut vises. En permanent lås krever at brukeren kontakter støtter for å fikse problemet og passer bedre til pålogginger, og beskytter viktige data.
Passord er det mest sensitive aspektet av påloggingen. Lagre aldri passord i vanlig tekst. Aldri. Noensinne. Dette betyr at nesten alle sikkerhetsproblemer kan avsløre innloggingsinformasjon. Selv krypterte passord bør unngås som om hackeren får tilgang til krypterte data, dekrypteringsprosessen kan være mye lettere. Enhver lagring der du kan hente et passord, gjør det lettere for en hacker å gjøre det samme.
Passord skal lagres saltet og hashed. Et salt er en tilfeldig generert, unik verdi lagret for hver pålogging og lagt til før hash. Å legge til saltet forhindrer identiske passord fra å ha samme hash og forhindrer hacker fra å bygge en liste over hashresultatet av mulige passordkombinasjoner på forhånd. Ved å legge til tilfeldig hash, et passord for abc123 (vær så snill å aldri bruke noe som det egentlige passordet) vil resultere i en annen hash for hver bruker.
En hash-funksjon gjør passordet til en fast lengdeverdi. Det er funksjoner som er spesielt utviklet for passord som PBKDF2 eller Bcrypt. GPU-prosessorene i moderne grafikkort kan utføre beregningene som trengs for hash og kan gå i stykker mange svake algoritmer raskt. Dedikerte maskiner for å bryte passord kan bestemme hvilket som helst åtte tegn passord eller mindre på under seks timer.
Brukere har ofte en tendens til å gjenbruke det samme passordet for de fleste nettsteder der de har kontoer. Mange nettsteder har begynt å teste de eksponerte legitimasjonene fra store kontoinnloggingshacker mot sine egne pålogginger og kontakte brukere som har kombinert brukernavn og passord. Evernote og Facebook nylig undersøkt påloggingsinformasjonen fra Adobe og varslede brukere som bruker de samme legitimasjonene.
Den enkleste måten å håndtere passordene på riktig måte er å bruke verktøyene som er inkludert i webrammen. Passordsikring er komplisert og å få bare en ting galt kan la brukerens passord åpne for angrep. pH-pass gir et offentlig domene bibliotek for PHP ved hjelp av Bcrypt. De eldre innebygde .NET-medlemskapsleverandørene brukte svakere hash, men de nye universelle leverandørene bruker PBKDF2. Rails gir også en Bcrypt perle.
Når du sikkert sikrer passord slik at de ikke kan hentes, mister du muligheten til å gi brukeren et glemt passord. Deretter må du gi en alternativ måte for en bruker som lovlig har glemt passordet for å tilbakestille passordet på en sikker måte.
En god reset-passord-side lar brukeren endre passordet uten å vite det nåværende passordet. Den tradisjonelle metoden tillater brukeren å skrive inn sin e-postadresse og sender deretter en lenke til en nettside som gjør at de kan tilbakestille passordet. Å sende en kobling er sikrere enn å sende et passord siden det nye passordet ikke er opprettet før brukeren får tilgang til siden. Å sende et nytt passord via e-post, vil opprette en ny legitimasjon som alle som fanger opp e-posten, kunne bruke uten brukerens kunnskap. Hvis noen avbryter e-posten og tilbakestiller passordet, vil brukeren vite når de får tilgang til og forsøker å tilbakestille passordet.
En god tilbakestillingsside bør heller ikke gi validering om at en konto eksisterer. Logikken er den samme som vi diskuterte med hensyn til ikke å gi tilbakemelding hvis en konto ikke eksisterte da du loggte inn. Selv om påloggingen ikke eksisterer i systemet. Den beste tilnærmingen er å gi en melding om at instruksjonene er sendt til e-postadressen på filen. Du bør fortsatt sende en e-post til den angitte e-posten, siden det kunne være et legitimt tilfelle av å ha glemt hvilken e-post som ble brukt til en konto, for eksempel å skrive inn en arbeids-e-post i stedet for en personlig e-post.
Koblingen til tilbakestilling av passord bør utformes, slik at tilbakestillingsforespørselen har en begrenset levetid og kun kan brukes en gang. Opprett et unikt symbol for hver tilbakestillingsforespørsel, knyttet til den forespurte kontoen, og lagre den i en database. Denne token blir en del av nettadressen som sendes til e-post for å tilbakestille passordet. Tildelen skal også tildeles en utløpstid og fjernes når tilbakestillingen er fullført. Hvis noen forsøker å bruke et token som allerede er brukt eller utløpt, vil forespørselen mislykkes. Utløpstiden må være lang nok til å tillate at e-posten mottas og brukeren fullfører handlingen, men ikke så lenge som å tillate bruk for langt i fremtiden. En tidsramme på noen få timer vil vanligvis være tilstrekkelig.
Tilbakestilling av et passord ved hjelp av e-post gjør også sikkerheten til nettstedet ditt avhengig av integriteten til brukerens e-post. Hvis e-posten er tilgjengelig, kan den personen tilbakestille passordet. Nettsteder kan legge til sikkerhetsspørsmål som må besvares før du tilbakestiller passordet. Sikkerhetsspørsmål gir litt ekstra sikkerhet hvis svarene er enkle å finne. Et sikkerhetsspørsmål om "Hva er min hjemby?" gir liten sikkerhet hvis svaret finnes på personens Facebook-profil. For mer om å utvikle gode spørsmål, se http://goodsecurityquestions.com/.
Et brukernavn og passord krever bare ett par opplysninger for å få tilgang til et nettsted. Når denne informasjonen er gitt, antas brukeren å være den riktige personen. For å gjøre stjeleopplysningene mindre effektive, kan du legge til et nytt trinn i autentiseringsprosessen. I tillegg til noe brukeren vet (brukernavnet og passordet), må brukeren også bruke noe de har i sin nåværende besittelse, vanligvis en mobiltelefon via enten SMS eller et program for dette formålet.
Bankene var trolig den første som implementerte denne prosessen ved hjelp av tilpasset maskinvare for å generere en tidsavhengig kode. Google populariserte bruken av SMS-tekstmeldinger eller en app som et annet trinn. Mange nettsteder bruker nå en pålogging som er kompatibel med Googles implementering av RFC 6238. Du kan finne biblioteker som allerede implementerer denne teknikken for de mest populære rammene som ASP.NET, ASP.NET # 2, Ruby on Rails, PHP og Django..
For å unngå disse problemene har du et annet alternativ, la noen andre håndtere alt dette ved å integrere med en tredjepart for godkjenning som Twitter, Facebook eller OpenID. Å gjøre det gir fordeler og ulemper. Det tar bort de fleste sikkerhetsproblemer som vi har diskutert her som noen andre behandler disse problemene. Imidlertid er disse andre nettstedene også sannsynligvis et større hackermål enn deg. Hvis du bruker et annet nettsted for å håndtere godkjenning, så har hackerne tilgang til nettstedet ditt hvis innlogging er skadet.
Bruke en kjent tredjepart kan både hjelpe og skade fra et omdømme og sosialt synspunkt. Fordelen med å tillate innlogging med enten Facebook eller Twitter er at så mange brukere allerede har kontoer der, at de vil gjerne bruke den. Andre besøkende kan se integrasjonen med disse nettstedene som en negativ funksjon, og ikke bruke nettstedet ditt på grunn av det, eller hvis det er det eneste alternativet til dem.
Din applikasjons innlogging spiller en viktig rolle for å sikre nettstedet ditt. Ta vare på å beskytte innloggingen din, vil gjøre mye for å beskytte nettstedet ditt, brukerne dine og deres private opplysninger. For å fungere trygt med pålogginger, minimer du mengden data som tilbakestillingssider for innlogging og passord kan gi en hacker. Legg også sikkerhetstiltak på plass for å gjøre det vanskeligere å gjette brukerens passord via brute force.
Beskytte passord er en kritisk bekymring for et hvilket som helst nettsted. Dårlig beskyttet passord gjør hackers jobb lettere og kan ende med innloggingsinformasjonen til nettstedet ditt, som er utsatt for offentligheten. Ved å bruke hashed og saltede passord blir hackerens jobb mye vanskeligere. I tillegg kan legge til muligheten for et andre trinn til påloggingsprosessen gi mer beskyttelse for nettstedets brukere. Du kan også velge å bruke en tredjepart til å håndtere innlogginger på nettstedet ditt.
Accentsconagua