Trei răspunsuri și o mulțime de plăceri.
Ce este caracteristic, dacă aceiași oameni întreabă dacă este necesar să ștergeți parolele pe server - toate împreună, construiți și răspundeți la cor - NECESITATE!
În același timp, niciunul dintre ei nu vine cu ideea de a combina ambele tehnologii. Și nu se potrivesc împreună. În cazul în care "serverul pentru partea sa, de asemenea salinesază parola și ia în considerare hash", atunci înseamnă. că parolele sunt stocate în clar!
Aceasta este chintesența acestor site-uri. Răspunsul este din anumite motive dat întotdeauna cel mai literal. În același timp, întrebarea nu este niciodată pusă sub semnul întrebării sau chiar testată în mod minim pentru semnificație. Se pare că respondenții percep întrebarea ca un examen sau ce? Sau ca o poartă - să răspundă cu orice preț, chiar dacă perversiuni incredibile și rake GUARANTEED în viitor. Sau - ca acum - cu prețul de reducere a securității! Dar răspunsul este literal. Și nu numai aici - deci practic în orice răspuns. Ei bine, niciodată nimeni nu are timp să se gândească la întrebare - toată lumea se grăbește să răspundă.
Nu știu ce să fac. Această abordare este foarte dăunătoare atât pentru site-ul în sine, cât și pentru cei care pun întrebări. În loc să arate apropierea corectă, el, cu sârguință, suge și înăbușând rămășițele giruselor, ajută să se împuște în picioare.
Înainte de a răspunde, trebuie să vă gândiți mai întâi. Conteazati de progresul urmator - "si ce se va intampla daca va fi facut, dupa cum va sfatuiesc?" Conteaza-te pe cursul din spate - "dar de ce are nevoie de asta? Nu este aceasta intrebare pe cont propriu, pe care am cerut-o odata din lipsa de cunostinte?" Și încercați să răspundeți pentru a ajuta cu adevărat pe întrebător și nu doar să dați un răspuns ciupit.
Mă uit la tine, lățimea gândirii depășește toate nivelurile imaginabile.
Ce are de-a face cu hashing-ul pe server, când vine vorba de transferul de parole securizat la el?
De ce nu este posibilă implementarea unui canal asimetric criptat la nivelul ajax pentru a oferi aceeași fiabilitate a transmisiei de date ca SSL?
Pe scurt, nu trebuie să conta pe mișcări inutile dacă nu știți ce direcție este "înainte".
FanatPHP. și dracu ar fi cu el.
Problema în sine este, de asemenea, destul de a decide. Apropo, „un server de pe partea sa ca parola de săruri“ poate fi ușor înlocuită cu „un server de pe partea sa ca săruri hash“ și, voila, avem din nou un antrenor. Adevărul este că încă nu poți edita, dar asta e altă poveste.
În orice caz, este posibilă organizarea unei transmisii sigure și acest lucru nu interferează cu stocarea hash-ului.
FanatPHP. Nu, nu este. Nu este necesar. Pentru că dacă transferați sarea, aceasta își pierde semnificația pentru utilizare. Toată plăcerea sării este aceea că este stocată pe server și nu este disponibilă. Va fi necesar să refuzați utilizarea de sare. Nu este la fel de înfricoșător ca și obiceiurile de gândire, mai ales că există metode alternative.
Cum de obicei stocăm parola? hash (pass + sold)
Și ceea ce ne împiedică să îl stocăm în schimb: criptează (hash (pass), vândut), unde criptează funcția de criptare simetrică folosind ca cheie este vândută.
Este posibil chiar mai brusc: criptat (hash (pass) + rand (), vândut)
Sper că este clar.
Întotdeauna frumos, tupanuv el însuși, a se vedea mote în ochii interlocutor :) 1. Semnificația de sare nu este deloc în acest lucru. Sarea este considerată a fi compromisă în avans și, prin urmare, este stocată în aer liber. Sarcina sarei este protecția față de căutarea precomplicată a meselor de curcubeu AKA. Principalul lucru este că este întotdeauna diferit. Și dacă este cunoscut sau nu - nu contează. 2. Stocarea unei parole într-o formă reversibil cusută este un nou cuvânt în securitate. Adevărat, mi-e teamă, prea nou. Ei nu vor înțelege - cu :) (în acest caz, mergem din nou la Deribasovskaya, în care cenușa (pass) acționează ca o parolă deschisă stocată)
1) Ei bine, da, este logic. Sunt un prost. Poate transfera.
2) Nu, nu în reversibil. Nu criptăm parola, ci hash-ul. Nu este inversibil prin definiție. Dar da - tabelele pre-calculate ne vor răni - sunt de acord.
Nu plecăm pentru Deribasovskaya. Apoi ați făcut o greșeală - nu trecem hash-ul!