Puncte:7

Trebuie să dezinfectez intrarea utilizatorului pentru a cripta sau a PBKDF-urilor în general?

drapel tr

Aș dori să permit utilizatorului să furnizeze o parolă ca intrare pentru unii PBKDF, pe care îl voi folosi pentru a construi o cheie pentru criptarea fișierelor (folosind în prezent aes-256-ctr. Se poate schimba pe măsură ce aflu mai multe).

Mă gândesc să folosesc scrypt. Trebuie să fac vreo scăpare, igienizare sau alte verificări asupra intrării utilizatorului pe care o voi transmite la scrypt?

În general, PBKDF-urile necesită în general verificări de siguranță asupra intrărilor furnizate de utilizator?

drapel jp
În general, *nu* trebuie să igienizați sau să verificați siguranța *nimic* decât dacă există un motiv anume...dar *o mulțime* dintre aceste motive specifice există, așa că este bine să presupunem că o faci până când se arată altfel.
Puncte:19
drapel fr

Nu, nu trebuie să faceți evadare sau dezinfectare a datelor pe care le transmiteți ca intrare de utilizator pentru aceste funcții. Acceptă secvențe arbitrare de octeți, astfel încât orice secvență de octeți arbitrară pe care o treceți este acceptabilă și nu ar trebui să existe riscuri de securitate ca urmare a acesteia. În general, algoritmii criptografici operează pe secvențe de octeți arbitrare (posibil de dimensiuni specifice) și nu necesită evadare standard sau dezinfectare pentru securitate (deși pot necesita umplutură, interval sau alte tipuri de verificări), iar sistemele care utilizează datele pot necesita acest.

Cu toate acestea, dacă acceptați parole care conțin caractere non-ASCII, probabil că doriți să faceți un fel de normalizare Unicode pe șir (probabil NFC), deoarece există adesea mai multe moduri de a exprima același caracter logic. De exemplu, puteți exprima „é” ca un singur punct de cod (U+00E9) sau ca două puncte de cod (U+0065 U+0301), iar normalizarea le va rescrie în același șir. Din nou, nu există probleme de securitate cu acest lucru, dar deoarece utilizatorii vor considera aceste două parole ca fiind aceleași atunci când au secvențe de octeți diferite, efectuarea normalizării permite sistemului dvs. să se gândească la ele ca fiind aceeași parolă.

phoenixdown avatar
drapel tr
oh foarte tare, nu m-am gandit la normalizare multumesc! Există o modalitate simplă de a face normalizarea NFC Unicode în javascript (nodejs) pe care o preferați? Voi avea si eu un google despre asta, multumesc
Aman Grewal avatar
drapel gb
@phoenixdown javascript are o modalitate încorporată de a normaliza https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize
drapel jp
@phoenixdown: Rețineți că există și alte tipuri de „normalizare” care pot avea sens sau nu. Este mai mult o chestiune de utilizare decât de securitate. De exemplu, cred că Facebook reduce parolele pentru a preveni problemele din cauza tastelor shift blocate/blocarea majusculelor involuntare. Apoi este întrebarea homoglifelor, adică personaje diferite care arată la fel. Asta poate depinde chiar de font, de ex. unele fonturi folosesc simboluri diferite pentru litera greacă my și semnul micro, unele folosesc același glif. Deci, cineva poate crede că a tastat un my, dar de fapt a tastat un micro sau invers.
bk2204 avatar
drapel fr
Parolele de pliere a carcasei înrăutățesc semnificativ securitatea și nu ar trebui să o faceți. În plus, este imposibil să îndoiți corect majusculele textului Unicode într-un mod insensibil la localitate. IETF are alte tipuri de normalizare Unicode care pot fi aplicate parolelor dacă NFC nu satisface nevoile dvs. care abordează unele dintre aceste probleme.
drapel in
Atenție la normalizare. Pe de o parte, este posibil ca utilizatorul să nu știe ce versiune a lui a introdus. Pe de altă parte, ei pot fi *foarte* conștienți și presupun că gestionarea parolei nu va face modificări la intrarea lor. Cel puțin documentați care normalizare va fi aplicată.
phoenixdown avatar
drapel tr
@bk2204 - la ce RFC vă gândiți pentru normalizarea Unicode aplicată parolelor? Este https://datatracker.ietf.org/doc/html/rfc8265?
bk2204 avatar
drapel fr
Da, acesta este RFC.
Puncte:5
drapel gh

Acest lucru va depinde de implementarea specifică a KDF-ului pe care îl utilizați. Nu sunt conștient de probleme cunoscute cu scrypt (deși asta nu înseamnă că nu există), dar cu siguranță au existat probleme cu implementarea PHP a Bcrypt unde prezența octeților nuli în intrare ar cauza probleme.

drapel ar
Aș dori să dau vina pentru asta mai ales pe PHP, dar o privire rapidă pe Wikipedia [sugerează](https://en.wikipedia.org/wiki/Bcrypt#Versioning_history) că gestionarea octeților nuli în bcrypt a fost într-adevăr prost specificat, și nu aș fi surprins dacă implementarea de referință C originală ar avea și ea aceeași eroare. (În orice caz, bcrypt nu este într-adevăr un KDF, ci o funcție de hashing a parolei și una destul de veche și depășită. Nu îl puteți folosi pentru derivarea cheii – cel puțin nu ușor – și având în vedere că există alternative mai bune, chiar nu ar trebui să-l folosiți nici pentru hashing parole în zilele noastre.)
phoenixdown avatar
drapel tr
Mulțumesc @Gh0stFish, observ că în postarea de blog autorul spune că „scrypt” și „PBKDFv2” nu sunt afectate de problemă.Ce ai recomanda? Verificați intrarea pentru orice octeți nuli și eliminați-i înainte de a trece la `scrypt`? @bk2204 este ceva ce l-ați recomanda și?
Gh0stFish avatar
drapel gh
@phoenixdown Nu cred că trebuie neapărat să eliminați octeții nuli, trebuie doar să verificați dacă *implementarea* specifică pe care o utilizați îi gestionează corect. De exemplu, dacă comparați două șiruri precum `foo` și `foo\0bar` (cu o sare fixă) și ajungeți la același rezultat, asta sugerează că biblioteca pe care o utilizați nu gestionează în mod corespunzător octeții nuli - caz în care ar trebui să le eliminați.
phoenixdown avatar
drapel tr
Mulțumesc, este o idee grozavă - pot adăuga un test pentru a mă asigura că `foo` și `foo\0bar` nu evaluează la același rezultat și eșuează dacă o fac.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.