Ainus teave, mida võiksite loota "peita", on järjestus : kuna andmebaas eraldab esmase võtme väärtused loenduriga, saavad inimesed, kes näevad nende võtmeid, arvata millal vastav kasutajakonto loodi. Peale selle pole muud teavet, mida mõni varjamisskeem tegelikult varjata võiks. Ründaja teab juba, et erinevatele kasutajatele viidatakse eraldiseisvate võtmete kaudu ja see on andmebaasi "esmane võti" semantika ulatus.

Seetõttu, kui te ei leia, et konto loomise tellimus on privaatne teave, mis vajab varjamiseks ütleksin, et teie varjamisskeem on mõttetu.

Üks lihtne viis oleks kasutada meetodit, mida kasutavad YouTube ja muud veebisaidid. See on räsiivid ( http://hashids.org).

Selle meetodiga saate anna linke, näiteks: http://www.example.org/user/fce7db/edit, samal ajal kui fce7db võrdub arvuga, nt: 12

Selle eeliseks on toimivus vastupidiselt teise juhusliku räsi genereerimisele andmebaasis, sest peate selle tõlkima vaid ühe korra ja seejärel saate andmebaasist otsida algse esmase võtme järgi, nagu varemgi.

Selle raskendamiseks Kasutajad saavad juhuslikult leida teisi ID-sid. Võite kasutada salajast soola ühe ja minimaalse pikkusega, et vältida nende jõhkrat sundimist.

Ühe salajase soola omamisega saavad inimesed siiski URL-e vahetada näiteks http://www.example.com/image/c8yDa.

Ei Ühel või teisel viisil peate konkreetse kirje identifitseerima URL-is unikaalse identifikaatoriga. See võib olla esmane võti või midagi muud. Kui peate järjestuse või järjestuse peitma, võite kasutada teist veergu juhusliku ja ainulaadse stringiga, näiteks Z2wDKo0ubb1D2VngFh4N.

Kui soovite suuremat turvalisust, kasutage SSL-i. See ei takista kasutajal URL-i ja parameetreid nägemast, nagu märkis @eggyal.

SSL-i kasutades on URL-i parameetrid krüptitud ja takistavad pealtkuulamist. Ja jah, me teame praeguseks, et SSL on vigane, mitte tegelikult nii turvaline, kuid see annab rohkem turvalisust kui selle kasutamata jätmine. Kuid ärge kasutage URL-i paroolide jaoks! Nagu alati, kasutage sisselogimiseks ja andmete esitamiseks POST-i, teabe hankimiseks GET-i.

Vaadake lehte https://stackoverflow.com/questions/499591/are-https-urls-encrypted

Põhjused, miks URL-is salajast teavet ei kasutata : DNS-i päringud pole tõenäoliselt krüptitud (kuid nagu kommentaarides märgib @tgies, pole päringute osa lisatud, seega siin pole ID-d), brauseri ajalugu ja serverilogid.

Olen loonud mõned süsteemid, mis URL-is esmast võtit (või muud identifikaatorit) kasutavad või ei kasuta. See, mida me kasutame, sõltub täielikult kahjutegurist - näiteks sait, mis on andmepõhine, on loetav, kasutame URL-is esmast võtit; meid ei huvita, kas keegi käib tooteid järjest läbi.

Turvanõuetega süsteemide korral oleme järjestikuse ennustatava ID asemel kasutanud ühte kahest skeemist:

1. põhiteavet säilitame brauseri seansis. Lihtne, arusaadav ja kui meie server pole turvaline, on meil suuremaid probleeme.
2. Oleme genereerinud juhusliku arvu (ja kontrollinud ainulaadsust) kas siis, kui kirje luuakse VÕI ainult seansi jaoks; ja kasutas seda juhuslikku numbrit URL-is.

Edu,

Larry

Jah, peaksite neid ID-sid hägustama, kuna lekitate teavet.

Kui teie rakendus on täiesti turvaline, võib kasutajate ainus teave (ab) teada saada kasutajate arvu hinnangu kaudu millegi nimega Doomsday Argument ^‡ kasutamine. Kui nad saavad teada mitme kasutaja ID-d, saavad nad teada, kes esimesena sisse logis, ja arvavad, kui kaugel see juhtus. Ja nad saavad õpetlikult arvata ka teiste kasutajate ID-sid.

If teie rakendus on täiesti turvaline.

Kui see pole nii, ja peaksite alati eeldama, et see ei pruugi olla, olete andnud kasulikku teavet. Kui kasutajatunnus oli lihtsalt juhuslik number, ei suutnud ründaja hõlpsasti teist kehtivat isikut välja selgitada. Kuna (enamasti järjestikused) numbrid antakse tavaliselt välja automaatse primaarvõtme abil, on see tühine.

Kui soovite säilitada lihtsat kasutamisvõimalust, võite kas muuta primaarvõtit või lisada teisese võtme. väikesed numbrid sisekasutuseks. See uus võti peaks tavaliselt olema GUID.

^{‡: Muidugi see on xkcd link.}

Te ei anna rakenduse kohta piisavalt teavet, et teada saada, kas peaksite selle varjama või mitte. Sellisena ei saa teie küsimusele seda osa vastata. Kui peate siiski küsima, on vastus ilmselt jaatav ja isegi kui see ei ületa, pakub see rohkem kohustusi kui alternatiiv.

Kaaluge esmase võtme peitmise või varjamise asemel selle muutmist. Pole vaja, et see oleks järjestikune. Uue kasutaja loomisel tehke juhuslik 32-bitine number, tehke kiire valik, veendumaks, et seda ei kasutata, ja kasutage seda oma peamise võtmena.

Kui keegi muudab kasutajat, võitis ta ei saa kasutajanumbrilt teavet hankida ja numbrite proovimine kohe selle numbri kõrval, millele neil on juurdepääs, annab tõenäoliselt olematu kirje.

Selle süsteemi üldkulud / koormus on minimaalne. See nõuab konto loomisel veel ühte valikut, mis on tõenäoliselt haruldane ja ei kehtesta täiendavaid üldisi järelsõnu - URL-is esitate endiselt peamise võtme, nii et DB-i otsingud on endiselt kiired, kuid võtmel pole teavet.