Jeg hadde nylig tid til å tenke på nytt på hvordan en sikker tilbakestillingsfunksjon for passord skulle fungere, først da jeg bygde denne funksjonaliteten inn i , og så når han hjalp en annen person med å gjøre noe lignende. I det andre tilfellet ønsket jeg å gi ham en lenke til en kanonisk ressurs med alle detaljene om hvordan du trygt implementerer tilbakestillingsfunksjonen. Problemet er imidlertid at en slik ressurs ikke finnes, i hvert fall ikke en som beskriver alt som virker viktig for meg. Så jeg bestemte meg for å skrive det selv.
Du skjønner, verden av glemte passord er faktisk ganske mystisk. Det er mange forskjellige, fullstendig akseptable synspunkter og mange ganske farlige. Sjansen er stor for at du har møtt hver av dem mange ganger som sluttbruker; så jeg skal prøve å bruke disse eksemplene for å vise hvem som gjør det riktig, hvem som ikke gjør det, og hva du må fokusere på for å få funksjonen riktig i appen din.
Passordlagring: hashing, kryptering og (gisp!) ren tekst
Vi kan ikke diskutere hva vi skal gjøre med glemte passord før vi diskuterer hvordan vi lagrer dem. Passord lagres i databasen i en av tre hovedtyper:
- Enkel tekst. Det er en passordkolonne, som er lagret i ren tekstform.
- Kryptert. Bruker vanligvis symmetrisk kryptering (en nøkkel brukes til både kryptering og dekryptering), og de krypterte passordene lagres også i samme kolonne.
- Hashed. Enveisprosess (passord kan hashes, men kan ikke hashes); passord, Jeg vil gjerne håpe, etterfulgt av et salt, og hver av dem er i sin egen kolonne.
La oss gå rett til det enkleste spørsmålet: Oppbevar aldri passord i ren tekst! Aldri. En enkelt sårbarhet for , én uforsiktig sikkerhetskopi, eller en av dusinvis av andre enkle feil – og det er det, gameover, alle passordene dine – det vil si, beklager, passordene til alle kundene dine vil bli offentlig eiendom. Selvfølgelig vil dette bety en stor sannsynlighet for det fra alle deres kontoer i andre systemer. Og det vil være din feil.
Kryptering er bedre, men har sine svakheter. Problemet med kryptering er dekryptering; vi kan ta disse vanvittige chifferene og konvertere dem tilbake til ren tekst, og når det skjer er vi tilbake til den menneskelesbare passordsituasjonen. Hvordan skjer dette? En liten feil kommer inn i koden som dekrypterer passordet, og gjør det offentlig tilgjengelig - dette er én måte. Hackere får tilgang til maskinen som krypterte data lagres på - dette er den andre metoden. En annen måte, igjen, er å stjele databasesikkerhetskopien og noen får også krypteringsnøkkelen, som ofte er svært usikkert lagret.
Og dette bringer oss til hashing. Tanken bak hashing er at det er enveis; den eneste måten å sammenligne det brukeroppgitte passordet med dets hashed-versjon er å hash inndataene og sammenligne dem. For å forhindre angrep fra verktøy som regnbuebord, salter vi prosessen med tilfeldighet (les min om kryptografisk lagring). Til syvende og sist, hvis implementert på riktig måte, kan vi være sikre på at hash-passord aldri vil bli ren tekst igjen (jeg skal snakke om fordelene med forskjellige hashing-algoritmer i et annet innlegg).
Et raskt argument om hashing vs. kryptering: den eneste grunnen til at du noen gang trenger å kryptere i stedet for hash et passord, er når du trenger å se passordet i ren tekst, og du bør aldri ønske dette, i det minste i en standard nettstedsituasjon. Hvis du trenger dette, så gjør du mest sannsynlig noe galt!
Advarsel!
Nedenfor i teksten til innlegget er det en del av et skjermbilde av det pornografiske nettstedet AlotPorn. Den er pent trimmet så det er ingenting du ikke kan se på stranden, men hvis det fortsatt er sannsynlig at det vil forårsake problemer, ikke bla nedover.
Tilbakestill alltid passordet ditt aldri ikke minn ham
Har du noen gang blitt bedt om å opprette en funksjon påminnelser passord? Ta et skritt tilbake og tenk omvendt på denne forespørselen: hvorfor er denne "påminnelsen" nødvendig? Fordi brukeren har glemt passordet. Hva vil vi egentlig gjøre? Hjelp ham å logge på igjen.
Jeg innser at ordet "påminnelse" brukes (ofte) i en daglig forstand, men det vi egentlig prøver å gjøre er trygt hjelpe brukeren til å være online igjen. Siden vi trenger sikkerhet, er det to grunner til at en påminnelse (dvs. å sende brukeren passordet) ikke er passende:
- E-post er en usikker kanal. Akkurat som vi ikke ville sendt noe sensitivt over HTTP (vi ville brukt HTTPS), bør vi ikke sende noe sensitivt over e-post fordi transportlaget er usikkert. Faktisk er dette mye verre enn å bare sende informasjon over en usikker transportprotokoll, fordi post ofte lagres på en lagringsenhet, tilgjengelig for systemadministratorer, videresendes og distribueres, tilgjengelig for skadelig programvare og så videre. Ukryptert e-post er en ekstremt usikker kanal.
- Du skal uansett ikke ha tilgang til passordet. Les forrige avsnitt om lagring på nytt - du bør ha en hash av passordet (med et godt sterkt salt), noe som betyr at du ikke på noen måte skal kunne trekke ut passordet og sende det med posten.
La meg demonstrere problemet med et eksempel : Her er en typisk påloggingsside:
Det første problemet er selvsagt at påloggingssiden ikke lastes over HTTPS, men siden ber deg også sende et passord ("Send passord"). Dette kan være et eksempel på den daglige bruken av begrepet nevnt ovenfor, så la oss ta det et skritt videre og se hva som skjer:
Det ser ikke mye bedre ut, dessverre; og en e-post bekrefter at det er et problem:
Dette forteller oss to viktige aspekter ved usoutdoor.com:
- Siden hash ikke passord. I beste fall er de kryptert, men det er sannsynlig at de er lagret i ren tekst; Vi ser ingen bevis for det motsatte.
- Siden sender et langsiktig passord (vi kan gå tilbake og bruke det igjen og igjen) over en usikret kanal.
Med dette ute av veien, må vi sjekke om tilbakestillingsprosessen er gjort på en sikker måte. Det første trinnet for å gjøre dette er å sørge for at forespørselen har rett til å utføre tilbakestillingen. Før dette trenger vi med andre ord en identitetssjekk; la oss ta en titt på hva som skjer når en identitet bekreftes uten først å bekrefte at forespørslen faktisk er kontoeieren.
Oppføring av brukernavn og dets innvirkning på anonymitet
Dette problemet er best illustrert visuelt. Problem:
Ser du? Vær oppmerksom på meldingen "Det er ingen bruker registrert med denne e-postadressen." Problemet oppstår åpenbart hvis et slikt nettsted bekrefter tilgjengelighet bruker registrert med en slik e-postadresse. Bingo - du har nettopp oppdaget din mann/sjef/nabos pornofetisj!
Selvfølgelig er porno et ganske ikonisk eksempel på viktigheten av personvern, men farene ved å knytte en person til et bestemt nettsted er mye bredere enn den potensielt vanskelige situasjonen beskrevet ovenfor. En fare er sosial ingeniørkunst; Hvis angriperen kan matche en person med tjenesten, vil han ha informasjon som han kan begynne å bruke. For eksempel kan han kontakte en person som utgir seg for å være en representant for et nettsted og be om tilleggsinformasjon i et forsøk på å forplikte seg .
Slik praksis øker også faren for «brukernavnoppregning», der man kan bekrefte eksistensen av en hel samling brukernavn eller e-postadresser på et nettsted ved ganske enkelt å utføre gruppespørringer og undersøke svarene på dem. Har du en liste over e-postadresser til alle ansatte og noen minutter til å skrive et manus? Da ser du hva problemet er!
Hva er alternativet? Faktisk er det ganske enkelt, og er fantastisk implementert i :
Her avslører Entropay absolutt ingenting om eksistensen av en e-postadresse i systemet sitt til noen som ikke eier denne adressen... Hvis du egen denne adressen og den ikke finnes i systemet, vil du motta en e-post som denne:
Selvfølgelig kan det være akseptable situasjoner der noen menerat du har registrert deg på nettsiden. men dette er ikke tilfelle, eller jeg gjorde det fra en annen e-postadresse. Eksemplet ovenfor takler begge situasjonene godt. Selvfølgelig, hvis adressen samsvarer, vil du motta en e-post som gjør det enklere å tilbakestille passordet ditt.
Det finurlige ved løsningen valgt av Entropay er at identifikasjonsverifisering utføres iht e-post før noen elektronisk verifisering. Noen nettsteder ber brukere om svar på et sikkerhetsspørsmål (mer om dette nedenfor) til hvordan tilbakestillingen kan begynne; men problemet med dette er at du må svare på spørsmålet samtidig som du oppgir en form for identifikasjon (e-post eller brukernavn), som da gjør det nesten umulig å svare intuitivt uten å avsløre eksistensen av den anonyme brukerens konto.
Med denne tilnærmingen er det liten redusert brukervennlighet fordi hvis du prøver å tilbakestille en ikke-eksisterende konto, er det ingen umiddelbar tilbakemelding. Selvfølgelig er det hele poenget med å sende en e-post, men fra en reell sluttbrukers perspektiv, hvis de oppgir feil adresse, vil de bare vite for første gang når de mottar e-posten. Dette kan forårsake litt spenning fra hans side, men dette er en liten pris å betale for en så sjelden prosess.
En annen merknad, litt utenfor emnet: påloggingshjelpefunksjoner som avslører om et brukernavn eller e-postadresse er riktig har det samme problemet. Svar alltid brukeren med en "Ditt brukernavn og passordkombinasjonen er ugyldig"-melding i stedet for å eksplisitt bekrefte eksistensen av legitimasjonen (for eksempel "brukernavnet er riktig, men passordet er feil").
Sender tilbakestilt passord vs sending av tilbakestilt URL
Det neste konseptet vi må diskutere er hvordan du tilbakestiller passordet ditt. Det er to populære løsninger:
- Genererer et nytt passord på serveren og sender det via e-post
- Send en e-post med en unik URL for å gjøre tilbakestillingsprosessen enklere
Til tross for , bør det første punktet aldri brukes. Problemet med dette er at det betyr at det er det lagret passord, som du kan gå tilbake til og bruke igjen når som helst; den ble sendt over en usikker kanal og forblir i innboksen din. Sjansen er stor for at innbokser synkroniseres på tvers av mobile enheter og e-postklienten, pluss at de kan lagres online i web-e-posttjenesten i svært lang tid. Poenget er det en postkasse kan ikke betraktes som et pålitelig middel for langtidslagring.
Men i tillegg til dette har det første punktet et annet alvorlig problem - det forenkler så mye som mulig blokkering av en konto med ondsinnet hensikt. Hvis jeg kjenner e-postadressen til noen som eier en konto på et nettsted, kan jeg blokkere dem når som helst ved å tilbakestille passordet deres; Dette er et tjenestenektangrep servert på et sølvfat! Dette er grunnen til at tilbakestillingen bare skal utføres etter vellykket verifisering av forespørsels rettigheter til den.
Når vi snakker om en tilbakestilt URL, mener vi adressen til et nettsted som er unik for dette spesielle tilfellet av tilbakestillingsprosessen. Det skal selvfølgelig være tilfeldig, det skal ikke være lett å gjette, og det skal ikke inneholde noen eksterne lenker til kontoen som gjør det lettere å tilbakestille. For eksempel skal tilbakestillings-URLen ikke bare være en bane som "Reset/?username=JohnSmith".
Vi ønsker å lage et unikt token som kan sendes som en tilbakestilt URL, og deretter matches mot serverposten til brukerens konto, og dermed bekrefte at kontoeieren faktisk er den samme personen som prøver å tilbakestille passordet . Et token kan for eksempel være "3ce7854015cd38c862cb9e14a1ae552b" og lagres i en tabell sammen med ID-en til brukeren som utfører tilbakestillingen og tidspunktet tokenet ble generert (mer om dette nedenfor). Når e-posten sendes, inneholder den en URL som "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", og når brukeren laster den ned, ber siden om eksistensen av tokenet, hvoretter den bekrefter brukerens informasjon og lar dem endre passord.
Selvfølgelig, siden prosessen ovenfor (forhåpentligvis) lar brukeren opprette et nytt passord, må vi sørge for at URL-en lastes over HTTPS. Nei, , må denne token-URLen bruke transportlagsikkerhet slik at det nye passordskjemaet ikke kan angripes og det brukeropprettede passordet ble overført over en sikker tilkobling.
Også for tilbakestillings-URLen må du legge til en token-tidsgrense slik at tilbakestillingsprosessen kan fullføres innen et visst intervall, for eksempel innen en time. Dette sikrer at tilbakestillingstidsvinduet holdes på et minimum, slik at mottakeren av tilbakestillings-URLen bare kan handle innenfor det svært lille vinduet. Selvfølgelig kan angriperen starte tilbakestillingsprosessen på nytt, men de må skaffe en annen unik tilbakestillings-URL.
Til slutt må vi sørge for at denne prosessen er engangsbruk. Når tilbakestillingsprosessen er fullført, må tokenet fjernes slik at tilbakestillings-URLen ikke lenger fungerer. Det forrige punktet er nødvendig for å sikre at angriperen har et veldig lite vindu der han kan manipulere tilbakestilt URL. Pluss, selvfølgelig, når tilbakestillingen er vellykket, er tokenet ikke lenger nødvendig.
Noen av disse trinnene kan virke overflødige, men de forstyrrer ikke brukervennligheten og faktisk forbedre sikkerheten, om enn i situasjoner som vi håper vil være sjeldne. I 99 % av tilfellene vil brukeren aktivere tilbakestillingen i løpet av svært kort tid og vil ikke tilbakestille passordet igjen i nær fremtid.
Rollen til CAPTCHA
Å, CAPTCHA, sikkerhetsfunksjonen vi alle elsker å hate! Faktisk er CAPTCHA ikke så mye et beskyttelsesverktøy som det er et identifiseringsverktøy – enten du er en person eller en robot (eller et automatisert skript). Formålet er å unngå automatisk innsending av skjemaer, som selvfølgelig kan brukes som et forsøk på å bryte sikkerheten. I sammenheng med tilbakestilling av passord betyr CAPTCHA at tilbakestillingsfunksjonen ikke kan bli brutt-tvunget til verken å spamme brukeren eller prøve å fastslå eksistensen av kontoer (noe som selvfølgelig ikke vil være mulig hvis du fulgte rådene i avsnittet om bekrefter identiteter).
Selvsagt er ikke selve CAPTCHA-en perfekt; Det er mange presedenser for at programvaren "hacker" og oppnår tilstrekkelige suksessrater (60-70%). I tillegg er det en løsning vist i innlegget mitt om , hvor du kan betale folk brøkdeler av en cent for å løse hver CAPTCHA og oppnå en suksessrate på 94 %. Det vil si at den er sårbar, men den hever (litt) barrieren for inngang.
La oss ta en titt på PayPal-eksemplet:
I dette tilfellet kan tilbakestillingsprosessen ganske enkelt ikke begynne før CAPTCHA er løst, så i teorien det er umulig å automatisere prosessen. I teorien.
Men for de fleste webapplikasjoner vil dette være overkill og helt rett representerer en reduksjon i brukervennlighet - folk liker bare ikke CAPTCHA! I tillegg er CAPTCHA noe du enkelt kan gå tilbake til om nødvendig. Hvis tjenesten begynner å bli angrepet (det er her logging kommer til nytte, men mer om det senere), kan det ikke være enklere å legge til en CAPTCHA.
Hemmelige spørsmål og svar
Med alle metodene vi vurderte, var vi i stand til å tilbakestille passordet bare ved å ha tilgang til e-postkontoen. Jeg sier "bare", men det er selvfølgelig ulovlig å få tilgang til andres e-postkonto. må være en kompleks prosess. derimot .
Faktisk er lenken ovenfor om hackingen av Sarah Palins Yahoo! tjener to formål; for det første illustrerer den hvor enkelt det er å hacke (noen) e-postkontoer, og for det andre viser det hvor dårlige sikkerhetsspørsmål kan brukes med ondsinnet hensikt. Men vi kommer tilbake til dette senere.
Problemet med XNUMX % e-postbasert tilbakestilling av passord er at integriteten til kontoen for nettstedet du prøver å tilbakestille blir XNUMX % avhengig av integriteten til e-postkontoen. Alle som har tilgang til e-posten din har tilgang til en hvilken som helst konto som kan tilbakestilles ved ganske enkelt å motta en e-post. For slike kontoer er e-post "nøkkelen til alle dører" i ditt nettliv.
En måte å redusere denne risikoen på er å implementere et sikkerhetsspørsmål og svar-mønster. Ingen tvil om at du allerede har sett dem: velg et spørsmål som bare du kan svare på bør vet svaret, og når du tilbakestiller passordet ditt, blir du bedt om det. Dette gir tillit til at personen som forsøker tilbakestillingen faktisk er kontoeieren.
Tilbake til Sarah Palin: feilen var at svarene på hennes sikkerhetsspørsmål/spørsmål lett kunne bli funnet. Spesielt når du er en så betydelig offentlig person, er informasjon om morens pikenavn, utdanningshistorie eller hvor noen kan ha bodd i fortiden ikke så hemmelig. Faktisk kan det meste finnes av nesten alle. Dette er hva som skjedde med Sarah:
Hackeren David Kernell fikk tilgang til Palins konto ved å finne detaljer om bakgrunnen hennes, som universitetet og fødselsdatoen hennes, og deretter bruke Yahoo!s funksjon for gjenoppretting av glemt passord.
Dette er først og fremst en designfeil på Yahoo! — ved å spesifisere slike enkle spørsmål saboterte selskapet i hovedsak verdien av sikkerhetsspørsmålet, og dermed beskyttelsen av systemet. Å tilbakestille passord for en e-postkonto er selvfølgelig alltid vanskeligere siden du ikke kan bevise eierskap ved å sende en e-post til eieren (uten å ha en annen adresse), men heldigvis er det ikke mange bruksområder for å lage et slikt system i dag.
La oss gå tilbake til sikkerhetsspørsmål - det er et alternativ for å la brukeren lage sine egne spørsmål. Problemet er at dette vil resultere i veldig åpenbare spørsmål:
Hvilken farge er himmelen?
Spørsmål som gjør folk ukomfortable når et sikkerhetsspørsmål brukes til å identifisere mennesker (for eksempel i et kundesenter):
Hvem lå jeg med i julen?
Eller ærlig talt dumme spørsmål:
Hvordan staver du "passord"?
Når det kommer til sikkerhetsspørsmål, må brukerne reddes fra seg selv! Med andre ord bør sikkerhetsspørsmålet bestemmes av nettstedet selv, eller enda bedre, stilles serie sikkerhetsspørsmål som brukeren kan velge mellom. Og det er ikke lett å velge en; ideelt sett bør brukeren velge to eller flere sikkerhetsspørsmål på tidspunktet for kontoregistrering, som deretter vil bli brukt som en andre identifikasjonskanal. Å ha flere spørsmål øker tilliten til verifiseringsprosessen, og gir også muligheten til å legge til tilfeldighet (viser ikke alltid det samme spørsmålet), pluss gir litt redundans i tilfelle den faktiske brukeren har glemt passordet.
Hva er et godt sikkerhetsspørsmål? Dette påvirkes av flere faktorer:
- Det bør være kort — Spørsmålet må være klart og entydig.
- Svaret må være spesifikk – Vi trenger ikke et spørsmål som én person kan svare annerledes på
- Mulige svar bør være mangfoldig - Å spørre noens favorittfarge gir en veldig liten delmengde av mulige svar
- søk svaret må være komplekst - hvis svaret er lett å finne noen (husk folk i høye stillinger), da er han dårlig
- Svaret må være fast med tiden - hvis du spør noens favorittfilm, kan svaret være annerledes et år senere
Som det skjer, er det et nettsted dedikert til å stille gode spørsmål kalt . Noen av spørsmålene virker ganske gode, andre består ikke noen av testene som er beskrevet ovenfor, spesielt "ease of search"-testen.
La meg demonstrere hvordan PayPal implementerer sikkerhetsspørsmål og spesielt innsatsen nettstedet legger ned på autentisering. Ovenfor så vi siden for å starte prosessen (med en CAPTCHA), og her vil vi vise hva som skjer etter at du har skrevet inn e-postadressen din og løst CAPTCHA:
Som et resultat mottar brukeren følgende brev:
Så langt er alt ganske normalt, men her er det som skjuler seg bak denne tilbakestilte URL-adressen:
Så sikkerhetsspørsmål spiller inn. Faktisk lar PayPal deg også tilbakestille passordet ditt ved å bekrefte kredittkortnummeret ditt, så det er en ekstra kanal som mange nettsteder ikke har tilgang til. Jeg kan bare ikke endre passordet mitt uten å svare både sikkerhetsspørsmål (eller ikke vite kortnummeret). Selv om noen kapret e-posten min, ville de ikke kunne tilbakestille passordet til PayPal-kontoen min med mindre de visste litt mer personlig informasjon om meg. Hvilken informasjon? Her er alternativene for sikkerhetsspørsmål PayPal tilbyr:
Spørsmålet om skole og sykehus kan være litt usikkert når det gjelder enkel søk, men de andre er ikke så verst. Men for å øke sikkerheten krever PayPal ytterligere identifikasjon for endringer svar på sikkerhetsspørsmål:
PayPal er et ganske utopisk eksempel på sikker tilbakestilling av passord: den implementerer en CAPTCHA for å redusere faren for brute-force-angrep, krever to sikkerhetsspørsmål, og krever deretter en annen slags helt annen identifikasjon bare for å endre svarene – og dette etter brukeren har allerede logget på. Selvfølgelig er det akkurat dette vi forventet fra PayPal; er en finansinstitusjon som driver med store pengesummer. Dette betyr ikke at hver tilbakestilling av passord må følge disse trinnene – mesteparten av tiden er det overkill – men det er et godt eksempel for tilfeller der sikkerhet er en seriøs sak.
Det praktiske med sikkerhetsspørsmålssystemet er at hvis du ikke har implementert det med en gang, kan du legge det til senere hvis nivået av ressursbeskyttelse krever det. Et godt eksempel på dette er Apple, som nylig implementerte denne mekanismen [artikkel skrevet i 2012]. Når jeg begynte å oppdatere applikasjonen på iPaden min, så jeg følgende forespørsel:
Så så jeg en skjerm der jeg kunne velge flere par sikkerhetsspørsmål og svar, samt en e-postadresse for redning:
Når det gjelder PayPal, er spørsmålene forhåndsvalgt, og noen av dem er faktisk ganske gode:
Hvert av de tre spørsmål/svar-parene representerer et annet sett med mulige spørsmål, så det er mange måter å konfigurere en konto på.
Et annet aspekt å vurdere når det gjelder å svare på sikkerhetsspørsmålet ditt, er lagring. Å ha en ren tekstdatabase i databasen utgjør nesten de samme truslene som et passord, nemlig at avsløring av databasen umiddelbart avslører verdien og setter ikke bare applikasjonen i fare, men potensielt helt forskjellige applikasjoner som bruker de samme sikkerhetsspørsmålene (det igjen ). Ett alternativ er sikker hashing (en sterk algoritme og et kryptografisk tilfeldig salt), men i motsetning til de fleste passordlagringstilfeller kan det være en god grunn til at svaret er synlig som ren tekst. Et typisk scenario er identitetsverifisering av en direktetelefonoperatør. Selvfølgelig er hashing også aktuelt i dette tilfellet (operatøren kan ganske enkelt legge inn svaret navngitt av klienten), men i verste fall må det hemmelige svaret være plassert på et kryptografisk lagringsnivå, selv om det bare er symmetrisk kryptering . Oppsummer: behandle hemmeligheter som hemmeligheter!
Et siste aspekt ved sikkerhetsspørsmål og -svar er at de er mer sårbare for sosial ingeniørkunst. Å prøve å trekke ut passordet direkte til en annens konto er én ting, men å starte en samtale om dannelsen (et populært sikkerhetsspørsmål) er helt annerledes. Faktisk er det fullt mulig for deg å kommunisere med noen om mange aspekter av livet deres som kan stille et hemmelig spørsmål uten å vekke mistanke. Selve poenget med et sikkerhetsspørsmål er selvfølgelig at det er relatert til noens livserfaring, så det er minneverdig, og det er der problemet ligger - folk elsker å snakke om sine livserfaringer! Det er lite du kan gjøre med dette, bare hvis du velger slike sikkerhetsspørsmålsalternativer slik at de er det mindre kan trolig trekkes ut av sosial ingeniørkunst.
[Fortsettelse følger.]Om rettighetene til annonsering
VDSina tilbyr pålitelig , hver server er koblet til en Internett-kanal på 500 megabit og er gratis beskyttet mot DDoS-angrep!
Kilde: www.habr.com