De ce nu sunt acceptate unele caractere pentru parole?

Plecând de la articolul ăsta, mi-a sărit în ochi un citat:

Bank of America doesn’t allow passwords over 20 characters, disallowing correcthorsebatterystaple. Passwords can contain some symbols, but not & or !, disallowing the other two passwords. eBay doesn’t allow passwords over 20 characters either.

De asemenea, am observat că unele site-uri nu acceptă spații în parole.

Este vreo practică ce-mi scapă mie? Sau se rezumă la programatori semi-competenți?

eu inclin spre partea cu semi-competenti (la faza cu anumite caractere nepermise). dar daca exista vreo explicatie logica chiar as vrea s-o aud.

1 Like

Companie mare de… programare. Primesti username pentru Windows cu o parola default. Evident, schimbi parola. Cine stie, poate pui o parola complexa, care poate contine si #. Dar observi ca nu toate aplicatiile din companie functioneaza dupa autentificare cu parola cu #.

Dupa ce schimbi parola cu una fara #, totul merge brici. Hmmm, programator fiind, dai un view source, ca esti curios. Si vezi un iframe cu src de forma http://username:parola/etc. Parola necodata. Deci # era interpretat ca hash tag in url, iar link-ul respectiv nu mai era corect.

Deci e clar de ce nu e bine sa ai parole complexe.

Am mentionat ca vorbeam de o companie de… programare? Evident, totul e pur fictiv, ipotetic, nu exista asa ceva, doar am vrut sa subliniez ideea cat mai artistic.

3 Likes

LOL

Faptul ca nu accepta parole cu & sau ! ma face sa cred ca Bank Of America isi tine parolele in baza de date curat. Fara MD5 [sau un oarecare alt algoritm de cryptografie] etc. Este o practica gresita dar ganditi-va ca sunt batrani care isi uita parola si suna la banca sa le fie zisa.[imi imaginez]. Deci probabil deaceea se tin parolele curat. Si nu accepta & sau ! pentru a elimina posibilitatea de a crea SQL INJECT [imi imaginez]. Dar oricum este LOL faza. Adica un set de caractere care contine & sau ! in MD5 este harmless. Nu ar avea motiv sa nu accepte aceste caractere.

Nu este nici o practica dpmdv.Bad devs are bad.

1 Like

Deși ar putea fi și vina programatorilor, în cazul băncilor nu cred că se pune problema. Motivul pentru care anumite caractere sunt interzise este că aceste bănci folosesc pentru autentificare, sau undeva pe parcurs în cadrul procesului de autentificare, sisteme destul de vechi ce utilizează doar un set restrâns de caractere. Astfel, pentru a putea fi în conformitate cu acestea se restricționează setul de caractere pentru toate sistemele folosite în cadrul procesului de autentificare.

Mai sunt și alte motive invocate de unele bănci, de exemplu unele din aceste caractere speciale nu sunt vizibile din prima pe tastatura telefonului mobil. Ca să vină „în ajutorul” utilizatorilor decid să excludă aceste caractere.

Oricum, asta nu e nimic, există chiar și unele site-uri (puține, ce-i drept) care nu permit în cadrul parolelor literele „Q” și „Z”. Ciudat, nu ? Ei bine motivul este că în trecut exista posibilitatea ca parolele să fie introduse prin intermediul tastaturii telefonului. Unele dintre aceste tastaturi nu aveau literele Q și Z (https://farm1.staticflickr.com/51/148973427_a1c2567a67_z.jpg?zz=1 - sursă: http://www.flickriver.com/photos/mrbill/sets/72057594138809478/).

După cum ziceam mai sus, din cauza acestor sisteme vechi sau poate și din cauza comodității de a nu-și bate capul cu schimbările, mai există și azi aceste restricții.

Știu de asemenea că acum ceva vreme (n-am mai verificat recent) și Evernote avea o politică la modul ăsta, nepermițând folosirea spațiilor în cadrul parolelor. Întrebați de ce au recurs la această variantă au zis că din motive tehnice. Mai exact spus, în cadrul API-ului se folosesc expresii model, că spațiile la începutul și finalul parolelor reprezintă o problemă în modul în care sunt tratate de diverse framework-uri (de exemplu unele ar șterge spațiile de la început/final, altele nu). Iar ca să permite folosirea spațiilor în interiorul parolelor ar însemna să modifice expresiile folosite pentru validarea parolelor, lungimea lor crescând de 2-3 ori, iar entropia parolelor în cazul adăugării de spații ar crește cu maxim 1.5%. Înțelege fiecare ce vrea din acest răspuns.

p.s. de ce nu se pot încărca imagini pe sistemul ăsta de discuții ăsta ?

Păi mergând pe ideea ta înseamnă că parolele din bănci sunt stocate ori în clar ori într-un algoritm ce poate fi „spart” prin bruteforce/rainbow tables etc. Iar asta s-ar putea să fie un pic mai grav decât le-ar convine lor să recunoască :smile:

Care „idee” a mea ți-a dat ție concluzia că parolele sunt ținute în clar ?

Și altă chestie, când e vorba de bănci voi presupuneți multe lucruri în necunoștință de cauză. Cum să spui că o bancă ar ține minte parolele în clar ? Credeți că ar trece de un audit de securitate în cazul ăsta ? Credeți că ar mai fi în conformitate cu standardele PCI ca să primească autorizație de funcționare ? Nici vorbă.

Asta. Mă îndoiesc că există sisteme vechi pe parcurs dar stochează datele în SHA3 sau Bcrypt + salt.

Am colaborat la un moment dat cu o bancă multinațională unde autentificarea se făcea doar pe partea de client (adică deschideai debugger, puneai câteva breakpoints și puteai trece mai departe). Sigur, asta se întâmpla într-un sistem închis, inaccesibil publicului, dar asta doar ca să îți faci o idee despre cât de mult accent se pune pe securitate în unele bănci.

Fun fact: la ing te poți autentifica doar cu digipass sau cu parolă. Care parolă, la momentul lansării, putea avea 6-8 caractere numerice. Nu litere, nu simboluri. Cifre! Ia zi tu, ce audit de securitate e de acord minim șase și maxim opt cifre ca parolă pentru contul tău dintr-o bancă?

(nu poți atașa imagini dacă ai mai puțin de 1-2 posturi)

Keccak, este cunoscut abia din aprilie 2014 sub denumirea de SHA-3, în urma câștigării concursului organizat de NIST pentru alegerea următorului standard în materie de funcții de dispersie (hash functions), deci mă îndoiesc de folosirea lui într-un astfel de sistem la momentul actual. Nici bcrypt nu cred că se folosește (sau vreo altă funcție de dispersie), deși nu este atât de nou precum se crede, fiind lansat în 1999.

Cel mai probabil - și asta e o părere personală (nu am de unde să știu exact, nu sunt lucruri publice) formată în urma celor studiate și din ce am mai citit în ultimii ani - se folosește un algoritm simetric (deci reversibil) în combinație cu HSM-uri, unde ar trebui ținute cheile. Prin algoritm simetric mă refer la unul din AES, 3DES sau chiar DES. DES a fost introdus prin anii '80 (oficial) iar 3DES și AES în 1998.

Cred că un sistem informatic de prin anii 2000, care folosește astfel de algoritmi, poate fi considerat vechi, nu ? Însă algoritmii respectivi, nu. De exemplu, conform NIST, AES (cheie de minim 128biți) poate fi folosit până în 2030 și după.

Legat de ing, nu știu cum a fost la început, probabil a fost ceva temporar, habar n-am. Dar am citit și eu acum la ei pe site și văd că în momentul de față parola trebuie să conțină intre 8 și 32 caractere alfanumerice, cel puțin o literă mică, o literă mare și o cifră. Mai mult decât suficient, având în vedere că standardul PCI spune ca parolele să aibă o lungime de minim 7 caractere alfanumerice. Pe urmă, instituțiile respective pot îmbunătăți aceste cerințe în funcție de gradul de risc prezentat de sistem. Și tot din ce am mai citit pe site văd că se și trimite un cod pe telefonul mobil în momentul autentificării, deci two factor authentication. Astfel sunt îndeplinite două din cele trei elemente posibile ale unui proces de autentificare multifactor: ceea ce utilizatorul cunoaște - PIN în cazul de față și ceea ce utilizatorul deține - telefon personal în cazul de față. Al treilea element ar mai fi fost ceea ce utilizatorul este - aici se folosesc tehnici de autentificare biometrice cum ar fi scanări ale retinei, ale amprentelor etc. Evident, nu e cazul de față.

1 Like