Miért minimum 8 karakter a jelszó?

Fórumok

Üdv!

Ezt a kérdést "$SUBJECT" tette fel nekem egy ismerősöm, de nem tudtam válaszolni rá. Elvileg van valami speciális vagy hagyományőrző oka...

Tudja valaki?

Z.

Hozzászólások

Ki mondta h 8? Van ahol 6, van ahol 12 ;)

Minel hosszabb, annal nehezebb bruteforceolni. Kb ennyi a titka.

Az ismerősöd hülyeséget butaságot beszél. Nincs ilyen általános szabály.
Másrészt engem nem az érdekel, hogy mennyi a minimum, mert mindig igyekszem maximális hosszúságúg jelszót használni. Paranoia forever!

-----
Innen most töltsünk tiszta vizet a nyílt kártyákba: ...

"NIST SP 800-63 (2) provides further discussion of password quality, and suggests, for example, that an 8 character user-chosen password may provide somewhere between 18 and 30 bits of entropy (randomness), depending on how it is chosen."

http://en.wikipedia.org/wiki/Password_cracking

Tudtommal - a jelenlegi ismeretek és hardver feltételek szerint - a BruteForce támadások ellen ez nyújt elegendő védelmet.
Ha jól tudom minden egyes karakter exponenciálisan növeli a törés idejét.

Gondolom anno 8biten kódolták a jelszót, ezért volt 8 karakter. De valszeg hülyeség xD...

127.0.0.1 SWEET 127.0.0.1

Szerintem zavar van az erőben: "Allowing passwords of adequate length (some legacy operating systems, including early versions of Unix and Windows, limited passwords to an 8 character maximum."

http://en.wikipedia.org/wiki/Password

Megvan a válasz is. A windóz úgy tárolta a jelszavakat, hogy 7 karakter + 7 karakter. Ezért mondták azt, hogy legyen 8, mert így gyakorlatilag 2 jelszót kell feltörni.

(Ez nem is volt olyan régen, rosszul tette fel a kérdést... :-( )

Erre a jelszótárolásra tudsz valami linket adni?
Másrészt a miniumum azt jelenti, aminél rövidebbet nem lehet megadni. Helyesebb lett volna azt kérdezni: Miért célszerű legalább 8 karakteres jelszót használni windows esetén?

-----
Innen most töltsünk tiszta vizet a nyílt kártyákba: ...

Az oldal elvileg xhtml, uft-8 kódolással. Szerinem hibás konverzióról van szó. ű helyett ő, és ő helyett ı van. Pl.:
"– A Windows XP és Server 2003 operációs rendszerek beépített
tőzfalprogramja, amely az Internetre kapcsolódó számítógépeket
tőzfalprogramja,
védi a külsı támadások ellen."

-----
Innen most töltsünk tiszta vizet a nyílt kártyákba: ...

lanman, vagy mi, jó régen.
7-ees blokk(+1 byte salt), külön kódolva ugyanazzal. azert kellett jo hosszu jelszot valasztani, mert akkor tobb 7 byteos blokk volt. ha 8-10 karakteres volt a jelszo, akkor a veget konnyu volt felnyomni, s abbal lehetett kovetkeztetni az elejere.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

A DES szabvány szerint 56 bites, azaz 8 karakter.
Szerintem ezért.

S.

Nem jó a 8 karakteres jelszó, mert a 8 bites WGA-n ezt e a legkönnyebb törni (a mértilleszkedés miatt ugyanis kisebb a surlódás a vezetékekben).

Én inkább 7, vagy 9 bites jelszót javasolnék, mert azok prímek, és nehéz rá jól illeszkedő áramkört tervezni.

a mai korban talán megmosolyogtató ez az elgondolás, de a Pentiumok előtti korszakban bizony fontos volt minden egyes kis sebesség-"nyerés" az igen lassú technológia miatt...
nem mindegy hogy Mancika beüti a kódot reggel, elmegy kávézni és mire visszajön, még mindig tart a bejelentkeztetési procedúra az esetleg rosszul megválasztott jelszó-hossz miatt...

persze ez mind hülyeség, de ma nagyon kipihent vagyok...

imho azert illik min. 8 karakteres jelszot valasztani, mert a sima des crypt algoritmus max. ennyit* tud kezelni.

*: ill. tud tobbet is, de a 8. karakter utani reszek mar nem effektivek a jelszo hash eloallitasara.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Szerintem meg a bruteforce törés ellen hatásos a minimum 8 karakteres jelszó. Tegyük fel, hogy csupán 100 lehetséges karakterrel számolunk, akkor is a lehetséges variációk száma 100^8... Kiszámolja valaki, vagy számoljam ki, mennyi időbe telne végigpörgetni az összes lehetőséget?
--
Coding for fun. ;)

Az mindig relatív, hogy mi a hatásos védelem. Papír és ceruza módszer ellen bőven elég. De egy megfelelő méretű cluster ellen semmit sem ér a 8 karakter. Itt gondolhatunk a 3 és 4 betűs szervezetek számítógépeire, vagy akár egy nagyobb egyetem gépparkjára is.

-----
Innen most töltsünk tiszta vizet a nyílt kártyákba: ...

Nem kell ehhez ukrán algoritmus. Ha valaki a 8 karakteres jelszavában csak az angol abc kis- és nagybetűit, illetve a számokat használja, akkor ~2*10^14 lehetőség van. A napokban volt blog HPC témakörben, ha jól emlékszem egy 44 node-os clusterről volt szó. Nem számoltam utána, de az a gyanúm, hogy belátható időn belül képes egy ilyen jelszót törni. (Belátható idő = amíg a user meg nem változtatja a jelszavát. Ilyen szempotból én fél évet még belátható időnek tekintek.)

-----
Innen most töltsünk tiszta vizet a nyílt kártyákba: ...

mert kerek szám, háromszor is hisz két körből áll

egyébként meg konkrétan azért mert a 6 karakter, feltéve mondjuk hogy 26 betűből választ az ember, irgalmatlan kevés (300millió), egyszerűen egyet azért tesz az ember hogy már legalább az int-ből kilépjünk, egyet meg azért hogy csökkentsük az emberek azon butaságát hogy nem véletlenül választ jelszót

a miért minimum 8 karakterre az a válasz, hogy:

"(some legacy operating systems, including early versions of Unix and Windows, limited passwords to an 8 character maximum)." ( http://en.wikipedia.org/wiki/Password )

A miért pont 8-ra nem tudom :)

Kérdezd meg a Wolfram Alpha-t :D

És nem lehet köze ahhoz hogy annak idején a DOS-ban is (max) 8 karakter volt a fájlnév?
Egyfajta hagyományként ezt vették át?

"Miért minimum 8 karakter a jelszó?"
Mert 8 karakterrel elég nagy lehet az entrópiája, amennyiben tartalmaz nagybetűt, számot és spec.karaktert is (@, %, &, -, _, '.', ...), és nem valamilyen trivialitást tartalmaz, amit szótárazással lehet törni.

Angol abc 26 karakterével szemben így 26(kisb)+26(nagyb)+10(számok)+legalább14(spec) az alap.

26^8(2,08e+11) és 76^8(1,11e+15) között nagy a különbség.

a jelszo tarolasara, es ellenorzesere ketfajta modszer van. Minden oprendszer valaszt a 2 modszerbol tetszes szerint, sot, minden alkalmazas is, emiatt a jelszokezelesnek es hasznalatnak tizezer vallfaja van.

emberi okokbol
Nagyon sok alkalmazas es oprendszer nem tud 8-nal hosszabb jelszot kezelni. Emiatt, ha egy sec. szaki azt mondja, hogy legyen 9 a minimum jelszo, kirohogik, mert egyszeruen nem lehet 9 nagyon sok helyen. Pedig kene.

Namarmost a security szakik paranoidak, es szeretnek a minel hosszabb jelszavakat. Ha 8 a max, es minel hosszabbat kell talalni, akkor ugye a min 8 a minel hosszabb.

feltorhetetlensegi okokbol
Mint a bevezetoben emlitettem, ketfele jelszokezeles van.
Az egyik fele jelszokezelesnel a jelszo kodolt verzioja elerheto a tamado szamara. Nagyon sok ilyen rendszer van, ahol ezt meg lehet tenni, pl a tradicionalis unix /etc/passwd. De win es egyebb helyen is sok ilyen alkalmazas van. Az ilyen rendszerek gyengek, ugyanis a meglevo kodolt jelszot nezve egy feltoro program (pl john the rip) szepen elkezdi probalgatni a szavakat egymas utan, hogy melyiknek lesz pont ugyanaz a kodolt verzioja. Ezt nagyon gyorsan meg lehet tenni. 4 karakternel par ora alatt, 5 karakternel lassabban, 7 karakternel nagyon lassan, 8 karakternel mar kivarhatatlanul lassan.
Persze a "johnjohn" nevezetu 8 karaktert azonnal megtalalja a program.

A masik fajta jelszokezeles, amikor a jelszo kodolt verziojahoz sem fer hozza a program, hanem csak oprendszerfunkcion keresztul. Az oprendszerfunkcio meg letilthat/varhat 5-8 sikertelen probalkozas utan, ezzel lehetetlenne teve akar a 4 karakteres jelszavak feltoreset is. Azonban ebben nem lehet megbizni: sokszor lattam mar elvileg jo rendszert, ami valami alkalmazas miatt megiscsak publikalt egy kodolt jelszot, amit aztan meg lehetett etetni a probalkozoprogrammal.

A 8 karakter (kisbetu, nagybetu, szam, egyebek) ossz varianciaja 64^8 = 281 ezer milliard. Ha egy modern gep egy orajel alatt probal egy jelszot, akkor masodpercenkent 1 milliardot, tehat 78 ora alatt talalja meg az utolso jelszot is. vagy 78 gep 1 ora alatt. Vagy egy masszivabb internetes zombi botnet fel perc alatt. Szerencsere nem lehet leprobalni egy jelszot 1 orajel alatt, tehat van egy kis eselye a gyenge 8 karakteres rendszereknek is.

"...Az egyik fele jelszokezelesnel a jelszo kodolt verzioja elerheto a tamado szamara. Nagyon sok ilyen rendszer van, ahol ezt meg lehet tenni, pl a tradicionalis unix /etc/passwd..."

Ezt gondold újra. Gondold újra, mert csak akkor igaz, ha odaadod a root jelszót a támadónak, hogy root-ként tudja olvasni a passwd,passwd-,shadow,shadow- file-okat. Amíg ezt nem teszed, még kódoltan sem elérhető a jelszó. De ekkor nem kell törnie, hiszen odaadtad a root jelszót, azaz azt tesz a rendszeredben, amit akar. Azaz marad a loginon keresztül történő próbálkozás. Jó rendszergazdánál 3-5 rossz próbálkozás után a rendszer pár napra letilt. Az már másik kérdés az értekezéseddel kapcsolatban, hogy az ott nem a jelszó kódolva.

Ej-ej... egeresz egy szót nem szólt a shadow fájlokról.

http://tldp.org/HOWTO/Shadow-Password-HOWTO-2.html

"By default, most current Linux distributions do not contain the Shadow Suite installed."

"The /etc/passwd file also contains information like user ID's and group ID's that are used by many system programs. Therefore, the /etc/passwd file must remain world readable."

Vicces, hogy az írás mennyire elavult, '96 óta sok minden megváltozott. Na mindegy, ha hallgattál volna, bölcs maradtál volna.

Azért nem baj, ha nekem mindenhol fent van és működik ? Nem baj, hogy a jól idecitált cikkeddel ellentétben a rendes disztrók telepítéskor jelzik, hogy akarsz-e shadow-t avagy sem ? És az baj-e, hogy nem kis istván lakótelepi lakos next->next->finish installprocedúrájából indultam ki ? Szóval ha olyan okos kos vagy, várom a magyarázatot, mitől is okoz problémát a passwd file olvashatósága ? Mellesleg elrejthető.

Minden a password policy-n múlik. :) Annyi a minimum, ami abban foglaltatik. :D

Ahogy végigfutottam az oldalt nem láttam, hogy bárki leírta volna, hogy ez hülyeség, a jelszó lehet egy karakter is, sőt, még jelszó se mindig kell, van amikor elég egy enter vagy egy kattintás. Persze kérdés, hogy a nincs jelszó az jelszó-e, azaz a jelszó hiánya ám lehetősége tekinthető-e jelszónak.

Ide kapcsolodik de off: soha nem fogom megerteni azokat a paraszt rendszeruzemeltetoket, akik ilyen szabalyokat hoznak, hogy "minimum 6 de maximum 8 karakter, es nem lehet az elejen meg a vegen szam", "csak 4 betut tartalmazhat", es tarsai. Ugyis egy fajlban tarolodnok, ami parameterezheto, nem? A minimum jelszo karakterszam, es a "legyen benne kisbetu nagybetu szam" az jogos a feltorhetetelenseg miatt. De a maximum, es hogy valami lehet, de csak a kozepen az nem jogos, hanem kiszuras az r1 memoriaju userrel. Meg azt sem ertem, hogy miert kell bizonyos idokozonkent megvaltoztatni (30 naponta kotelezo pl). Aki feltorte, ugyis tudja, hogy csak a szamot emeltem meg benne, vagy akar o is megvaltoztathatja ido elott.
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

lejaro jelszavak:
a jelszo kompromittalodasa hosszu idon keresztul tekintheto valoszinusegnek. Ilyenek vannak benne, hogy a user veletlenul mashova azt irja be, lelesik a hata mogul, ejjel reszegen elkotyogja stb. Ezek az esetek egyenkent "igen-nem" tipusuak, soksok usernel soksok napon keresztul viszont nezheto ugy, hogy van egy kis valoszinusege, hogy a user jelszava az adott napon kompromittalodik.
Ezzel a szemlettel tekintve, ha soha nem valtoztatja meg a jelszavat, akkor a kompromittalas valoszinusege novekszik, megkozeliti a 100%-ot. Ha viszont rendszeres jelszocserere kotelezzuk a felhasznalot, akkor a kompromittalodas valoszinusege elfogadhato szinten tarthato.

A kerdes es a vita az, hogy hany naponta jarjon le.
Elterjedt nezet, hogy a penzintezeteknel 30 napos lejarast irnak elo. En ezt rossznak tartom, 180 napos realisabb lenne.

Ha tul picire vesszuk a jelszo lejarasi idotartamot, akkor megno annak az eselye, hogy a userek tomegevel felirjak, vagy algoritmukusan generalhatot valaszt, mert nem bir 30 naponta egy uj random sztringet memorizalni. Ez megnoveli a kompromittalodas valoszinuseget. Emiatt a tul kicsi lejarati intervallum nem optimalis az egesz szervezet szempontjabol.

Mellesleg penzintezetnel a felhasznaloi azonositokat (pontosabban: minden access rightsot) automatikusan lejaratnek, ha nem ismert a pontos lejarati ido, akkor evente.

a párom cégénél 30 napos jelszó élettartam van, az átlag dolgozó képtelen/lusta megtanulni és mindenki kis papírcetliken ragasztgatja a monitorokra :)
ergo sokkal nagyobb veszélyt rejt így magában a dolog, mintha fővesztés terhe mellett lenne kiadva egy jelszó, amire viszont úgy kell vigyázzon, mint a saját hitelkártyája pinkódjára...

a "kisbetu, nagybetu, szam, elejen kozepen vegen" jellegu jelszo hezirendnel jobbnak tartom, ha jelszovaltoztatas eseten a john mojol rajta 3 masodpercet, es ha ezalatt nem sikerult megfognia, akkor engedjuk a usernek a jelszocseret.

A valos jelszo alapu behatolasok (tehat a valos jelszoproblemak) cca ott tartanak, hogy {$userid,$realname,$birthdate,$wifename "password","secret",1,2,3,4,5,6,7,8,9,0}^3 szotarral minden sokfelhasznalos rendszerbe be lehet jutni, mert sok userbol par (a fele...) ilyen jelszot hasznal. Sot, ez a 4096 elemu szotar is tulzas a valos eletben, mintha olvastam volna egy kutatast, hogy egy jol megvalasztott 10 elemu szotarral szinte biztosan be lehet jutni barmi sokfelhasznalos rendszerbe.

vannak olyan fergek, amik jelszoprobalkozassl (is) terjednek tovabb. Most csak egy ilyen jut az eszembe:
http://www.cert.org/advisories/CA-1989-04.html
a kovetkezo modnatot emelnem ki:
It looks for passwords which are the same as that of the account or are blank.

Tehat ez a cucc 1989 -ben 2(!) elemu szotarral dolgozott. Az akkori (lokalis) halozat szinte osszes gepere bejutott.