Jelszó
A következő két karakterlánc közül:
a.) "TQmfz:aVLzMJ6.*{"
b.) "Az nem lehet, hogy annyi szív hiába onta vért!"
melyik a jobb jelszó? Miért?
(Az elsőt a Strong Random Password Generator segítségével állítottam elő.)
■ a.) "TQmfz:aVLzMJ6.*{"
b.) "Az nem lehet, hogy annyi szív hiába onta vért!"
melyik a jobb jelszó? Miért?
(Az elsőt a Strong Random Password Generator segítségével állítottam elő.)
Beszélgetni akarsz róla? Vagy
Egyébként a második az ékezetek miatt annyira nem nyerő, szóval ebből a szempontból az első.
Ha azt nézed, hogy brute force segítségével mennyi idő visszafejteni egyiket vagy másikat, akkor a második.
A gond ott kezdődik, hogy állítólag lassan elkészülnek az első ú.n. kvantum számítógépek, amik az ilyen támadásokat (feltéve, hogy megvan a hashelt jelszófájl) alaposan meggyorsítják.
Bocs, nagyon reggel van még... :)
zmt,Yivaat,Sniu"1tg4t.
Ez hogy tetszik? Még meg is lehet jegyezni, ha nagyon akarom :)
Ékezet
Nekem anno azt tanították,
UTF8
Nem az a gond, hogy nincs
Lehetne mondani, hogy mostantól minden UTF-8, vagy bármi, csak akkor figyelemmel kell lenni a helyfoglalásra, azzal, hogy 1 karakter nem biztos, hogy elfér 1 byte-on stb. Így ha pl egy magyar kódolású DB-be szeretne valaki kínai karakterekkel regisztrálni, ott lesznek gondok... Oracle esetén meg pl megadható, hogy a szöveges mező mérete byte-ban, vagy karakterben értendő.
Amúgy valóban a hosszú, könnyen megjegyezhető jelszavakat szokás ajánlani. Szemben a legyen benne mindenféle kriksz-kraksz jelszavakkal.
Nem tudom, manapság mennyire
Billentyűzet
Jelenleg engem se. De vannak
Ma már: miért ne?
Tárolásba meg nem számít, feltéve ha nem plain/text mented a jelszavakat. :)
Tárolásba meg nem számít,
Ha szempont az is,
Mondjuk értelmes mondatoknál is jobb az, ami nem idézet, de talán az még nem annyira játszik.
Visszafejteni nyilván a hosszabbat nehezebb, de ha már kiderül, hogy van benne space, és közte szavak, akkor hamar el tud fogyni ez az előny.
Az elsőhöz viszont használni kell valami 3. féltől származó jelszókezelőt és / vagy fel kell lennie írva valahova - szóval abban is van plusz veszélyforrás a visszafejtésen kívül.
Ha lehet azt válaszolni, akkor leginkább ezekből mindegy, hogy melyik, de legyen utána egy 2nd factor is, ami mondjuk egy regisztrált auth mobil app, nem sms / email. :)
Hogy derülhet ki, hogy vannak
dictionary
Olyat olvastam - és nem tartom lehetetlennek -, hogy ha sok jelszó hash kerül az illetéktelen kezekbe (pl a db-t sikerült kidumpolni valahogy), akkor van valami szótárazós megoldás is, de konkrétumot nem írtak (gondolom nem véletlenül), és nem is igazán foglalkoztat engem annyira.
Ha jól emlékszem, valami olyasmi a lényege, hogy miközben gyártják a csilliónyi próba-hash-t, valamennyi eredményt mentenek is (ha van), és ez alapján okosodik tovább a találgató rendszer. De a konkrét matekra nem emlékszem, de valószínű, hogy nem is írták.
Én még mindig a másik oldalon állok, úgyhogy inkább arra igyekszem fejlődni, hogy olyan megoldásokat használjak, amikkel egy (vagy többezer) hash birtokában sem könnyű mit kezdeni, függetlenül attól, hogy mi a mögötte lévő jelszó. (Nyilván nem lehet teljesen független, de értsd jól.)
Lehet, hogy nem éri meg, de én ezen az oldalon alszom nyugodtan. :-D
A dictionary attack az kb.
Elvileg ez ellen véd valamelyest az ú.n. sózás, amikor a tárolás előtt még hozzácsapnak a tényleges jelszóhoz valami random stringet, akár jelszavanként mást. Ezt a "sót" olvasható formában szokás tárolni a jelszó hash mellett (lásd pl. crypt függvény paraméterei),.
Illetve amennyire tudom, a többszörös hash-elés (tehát amikor a már kész hash-t újra átküldöd a kódoló függvényen többször is) is ilyen céllal szokott történni.
Így a rendszer valamelyest védve van attól, hogy brute force nélkül hozzájusson illetéktelen a jelszavakhoz.
Olyanról nem tudok, hogy részeredmény is lenne pl. brute force próbálkozás közben, de lehet, hogy én tudom rosszul.
Nagy vonalakban. Persze a védelemhez az sem árt, ha x próbálkozás után egy időre vagy végleg letiltják a usert, hogy találgatással se lehessen bejutni.
Ezt így nem egészen értem
Jó, mondjuk ha feltételezzük, hogy nincs se sózás, se n > 1 -szeri hashelés, akkor akár én generáltam. De ez így még mindig túl egyszerűnek tűnik, plusz régen rossz, ha a fenti két feltételből egy is teljesül.
A gyakorlatban pedig inkább az szokott történni (pl yahoo pár éve ezt nyilatkozta), hogy valamilyen úton módon lenyúlják a user táblát, aztán ezzel próbálnak kezdeni valamit.
- Sózás: én ma azt mondanám, hogy több sót kell használni. Van olyan, ami valamilyen egyébként kötelező (NOT NULL) adat, aminek az oszlopneve nem feltétlenül "salt", hanem (mondjuk) username, nickname, stb, de valós adat (lehetőleg több is). Plusz mindenképp van legalább 1 fix só, ami nincs a db-ben, hanem valahol a forráskódban / configban, és csak az ismeri, aki a fájlokhoz hozzáférhet.
- Hash: mindenképp többszörös, közben is sózva, és véletlenül sem tartalmazhatja a db a kódolási technikát, darabszámokat, ez csak a szoftver része lehet. (És értelmes hash fv használni, pl ?crypt.)
- Védelem: amennyiben nem ismert keresőbot és nincs session-e ("új" látogató), akkor eleve a request-ek is időkorlátosak azonos IP-ről. Ha olyan az alkalmazás, hogy csak autentikált user használhatja, akkor további korlát, hogy amíg nincs auth, addig csak login kérés jöhet. Erre jön rá, hogy x időn belül csak y db login kérés jöhet ugyanonnan. Persze lehet ezt variálni a végtelenségig, de ez az alap. A túl sok próbálkozást user helyett én jobb szeretem IP címhez kötni, mert hamar megteheti, hogy userenként mondjuk csak 2-t postol, de többezer userrel..
Honnan? Darkweb... leginkább.
Rainbow table olvasnivaló: https://en.wikipedia.org/wiki/Rainbow_table
A többiről inkább kérdezz valaki hozzáértőt, mert én csak felszínesen foglalkoztam ezekkel a dolgokkal, de az általad felvetett dolgok egy része kb. felesleges (van rá valami szakkifejezés, hogy az eltitkolt dolgokat védelemnek hisszük, de most nem ugrik be)
A kódolási technika és a salt simán benne hagyható a hash-ben, eleve így is szokás tárolni pl. a crypt függvény használatakor:
$id$salt$encrypted - az id a kódoláshoz használt algoritmust jelzi.
Na ugye :)
De véletlenül sem azt írja le, hogy hányszor és hogyan lett sózva - hashelve. Ugyanilyen okból nem tesszük a fix sót se db-be, feltéve ha van.
Egy id vagy akár token semmit nem mond a hackernek ezekről, legfeljebb azt, hogy melyik hash fv volt az "elkövető" (pl bcrypt, sha_xxx, stb), de azt se feltétlenül.
Nem hiszem védelemnek az eltitkolt dolgokat, pusztán követem azt az ajánlást, hogy minél több felől kell összeszedni a szükséges információt a töréshez, annál több a munkaigénye..
Ha nem elég a db-t megszerezni, kell a storage is, máris két szervert kell kinyitni.
Persze ezt nem olyan egyszerű elérni, egyetlen fix só áthelyezése nem oldja meg.
Szerintem ennek fuss neki
Az id megmondja a hash algoritmust, mögött meg ott a "só", amit használtak az adott hash-hez. Az valóban nincs ott, hogy hányszor lett hashelve (aminek én sok értelmét egyébként sem látom, de ez az én bajom)
Ja igen, bocs
Mondjuk nem md5-öt kell
A komolyabbakat a mai eszközökkel elég reménytelen visszafejteni.
- Sózás: én ma azt mondanám,
A so akkor jo, ha egy teljesen random, hosszu, egyedi ertek. Nem kell rejtegetni, folosleges titkositani. Akar oda is adhatod a juzernek. Ha egy tamado hozzafer az adatbazisodhoz, nyugodtan feltetelezheted, hogy a teljes forraskodhoz, barmihez hozzaferese van, tok folosleges rejtegetni ezt az erteket, nem arra szolgal, hogy biztonsagosabb legyen a jelszo (a tamado nem fogja "nehezebben" kitalalni a jelszot). A so a szivarvanytablak ellen van, ami a tamadonak egy time-memory trade-off (szivarvanytablakkal szamitasi idot sporolsz meg tarhelyert cserebe)
Ne talald fel a kereket. Hasznalj
bcrypt
/scrypt
/pbkdf2
/stb-t, konfigurald ugy, hogy a hasheles kelloen lassu legyen (mar ha akar csak 1 szazad masodpercig tart egy hash eloallitasa, egy tamadonak eselye sincs kitalalni). Ne hasznalj gyors hasheket (md5
,sha1
,sha256
, stb), mert nem erre valoak.Én a másodikban számokra
Erősségre mindkettő elég erős, viszont a második dictionary attack-re lehet, hogy sebezhető. Mindkettőnél előfordulhat, hogy már bent van valamelyik jelszó adatbázisban, szóval bármelyik lehet törhető, ha már egyszer használtuk és ellopták. Ezért érdemes mindenhova egyedi jelszót csinálni és bizonyos időközönként cserélni őket. Nekem azt hiszem a LinkedIn jelszavamat lopták el, legalábbis talán 1 éve küldtek levelet, hogy cseréljem, mert kompromittálódott a rendszerük.
linkedin
Azért kemény, hogy itt a 21.
Eloszor definialni kene, mit
Mindket jelszoval lehetnek problemak:
Most nem celom itelkezni, hogy ezek kozul melyik teljesen idiota limitacio.
Alapvetoen a josag inkabb fugg attol, hogy hol akarod hasznalni a jelszot.
En speciel kb 12 karakteres random jelszavakat generalok, es jelszokezelo programmal managelem oket, igy a jelszavaim tobbsegevel sosem talalkozom, nem kell oket begepelnem.
Nekem ami kifejezetten
Én annyira nem bízok a jelszó kezelőkben, a tucat jelszókat jegyeztetem csak meg velük, pl a weblaborosat, ahol nem para, ha feltörik, mert max írnak a fórumba valami hülyeséget. Azok a jelszók meg kb. olyanok, hogy ráütök a billentyűzetre, aztán ami kijön. A fontosakat fejben tartom, és ahogy nézem olyan 15 és 35 karakter között szoktak lenni. Ezek ilyen egész vagy félmondatok, nem gyakori szólások vagy ilyesmik, úgyhogy megtippelni esélytelen őket. Van összesen fél tucat ilyen, úgyhogy nincs nehéz dolgom a megjegyzésükkel, begépelni pár másodperc alatt be tudom őket, úgyhogy nem vesztek sok időt vele, főleg amilyen lassúak a hivatalos, banki, stb. oldalak. Amit gyakran használok, az meg annyira beleégett már a kezembe, hogy a 20 karakter kevesebb mint 1 másodperc alatt megvan. Most mértem, hogy olyan 450 karakter per perccel gépelek, az több, mint 1000-nek felelne meg. Bár ahogy nézem még az sem egy világrekord sebesség. :D
Egyébként ha angol nyelvű oldalra regisztrálsz magyar szavakkal és angol szótárat használ a hacker, akkor máris elbukta a dictionary attack-jével. Ha meg vegyítesz több nyelvet is, akkor szintén, mert szerintem a legtöbbje nem is gondol ilyesmire. Még tovább lehet erősíteni rajta, ha hozzád kevésbé köthető, esetleg kitalált személynév, helységnév, irányítószám, ügyiratszám, telefonszám, ilyesmik is vannak benne. Ha ezeket kiejtés szerint és/vagy tájszólással, esetleg helytelenül írod, pl "A Macsupicsu lankás lejtőin" (27 karakter), akkor még erősebb lehet a jelszó. Ha a haverjaiddal gyerekkorodban kitalált szavak is belekerülnek, az meg kb. a feltörhetetlen kategória.
Viszont szerintem a fentinél gondolni kell arra is, hogy valaki egy ujjal gépel, maximum kettővel, és még úgy sem hibátlanul. Elég csak körülnézni a családban. Nekik kifejezetten kényelmetlen a hosszú jelszó...
Ami nekem kifejezetten tetszik jelszavakkal kapcsolatban az az RSA private key-nek adott passphrase. Mármint maga blokk titkosítás az gagyi rajta, de az elv szerintem tök jó, hogy jelszóval titkosítod a kulcsot, amit kódolásra használsz, és nem magából a jelszóból származtatod a kulcsot. Gondolom van néhány jelszó kezelő, ami ilyen elven generálja és tárolja le a jelszavakat és védi le mester jelszóval, de a legtöbbje gagyi, van/volt olyan is, ami plain text-ben tárolta le a jelszavakat.
Bank
A jelszó egy token, amit vagy egy plusz hardvereszköztől kapsz (ezt asszem már nem nagyon használják), vagy egy mobilapp-ból, amiből szintén egy számlához csak egy lehet.
Természetesen nem lehet a tokent másolni (ezzel valamennyire egyetértek), de:
- mindössze 6 jegyű szám a token
- a webes felületen ennek ellenére jelszó mezőben van, nehogy meglásd, ha elgépelted :-D
- nem tudom pontosan meddig, de több, mint 30 másodpercig érvényes(!).
- Érdekes lehet egy céges számlánál az egyetlen token generátort használni.
Összességében szerintem ez nagyon gagyi megoldás, elsőször is én normálisan string-eket használnék ott username és password gyanánt, és mintegy kötelező második faktorként kérném a tokent.
A kifizetésekhez pedig elég csak a (z új) token.
Mondjuk más gondom is van ezzel a bankkal, lehet váltok majd, de az már offtopkic.
Limitációk
Van...
Tudnék mesélni nem is olyan régi story-t, amiben még plain/text jelszó is volt, de nem publikus.
Mondjuk a BKK remek T-systems-es jegyeladós rendszere gondolom ismertebb, és ott is elsőre a felhasználó volt a hibás, hogy hogyan merte megmutatni a szarvashibát...
Fel sem merült bennük, hogy ha hackerkedni akarna, akkor nem 1 db bérletet vesz 50 Ft-ért és nem jelzi a hibát...
Az en velemenyem (illetve
password
,123456
, stb), ilyen listat az ember biztos tud szerezniEn tokre orulnek, ha a
tom-bumps-guts-juju-cyclops-lyricism
tipusu jelszavak mindenhol hasznalhatoak lennenek (ezt a jelszot az elobb generaltam).Én még annyit hozzátennék,