Speciális karakter

Imádom, mikor sírnak az oldalak, hogy legyen a jelszóba mindenképp speciális karakter, mert attól lesz jó...

Most éppen uniqa ügyfélportál volt.

Benyomtam amit a firefox generált, végigmegy a regisztrációs folyamat, majd szopok, hogy miért nem lép be. Belépés gombra semmi nem történik. Mivel nem az első ilyen, máshol is futottam már ilyenbe, sejtettem ám, hogy túl speciális lett a jelszó: EsU2+)%V*V*%Pz"

Úgyhogy elfelejtett jelszó, új jelszó, generáltattam egy kevésbé speciálisat, megette, beléptem. Micsoda csoda. Csudaweb 3.0.

Hozzászólások

Én mit szeretnél ezzel mondani?

cat /dev/urandom | tr -dc 'a-zA-Z0-9$#<>!?=&@{}[]-_*+' | fold -w 12 | head -n 3

Tudok én is 10 féle képpen/helyen jelszót generálni, nem az a kérdés, ez ráadásul mindig megy, nem kell hozzá semmilyen tool.

"Sose a gép a hülye."

Én valójában sohasem értettem, hogy miért nem lehet bármilyen karakter egy jelszóban, akár szóköz vagy ékezetes vagy bármi. A végén úgy is egy hash lesz belőle, az megy az adatbázisba, lehet base64 is, semmi bajt nem okoz. Ugyan így rejtély számomra, hogy a maximum hossza miért van sok helyen korlátozva durván, mondjuk 20 karakterre. Ebbe egy rendes 3 szavas kifejezés sem fér bele, angol szavakból sem. De növelni akarjuk a biztonságot...

A programozók kényelme, hogy ne kelljen azzal foglalkozni, hogy a jelszónak átvett stringben van-e a nyelv számára vezérlő karakter? Vagy mi az oka? Esetleg 25 évvel ezelőtt 7 bites ASCII-re megírt password library van még használatban mindenhol?

A legjobb, mikor megköveteli a speciális karaktert, és mellé van írva 3 db speciális karakter, amit valójában elfogad... Az is szintén jó amit írsz, hogy elfogadja a jelszót mikor beállítod, de aztán nem tudsz vele belépni, és nem tudod, hogy a jelszóval van baja, vagy tényleg elírod folyamatosan (mert van, ahol meg sem lehet nézni, mit írtam be...).

Tudod hány helyen van még plaintextben tárolva a jelszó? Rohadtul meglepődnél.

Pl. az óvodai étkeztetési rendszerbe most regisztráltak be, kaptam emailben, hogy az ön jelszava a belépéshez: XYZ654

Vagy ott van például a yettel felület, ahol fixen 6 szám lehet csak... Apropó, OTP-nél lehet már 8 karakternél hosszabb jelszó?

"Sose a gép a hülye."

Attól, hogy emailben elküldenek egy kezdeti jelszót még nem feltétlenül van ez plaintextben tárolva.

Mondjuk attól még nem szép hogy így műdködik, ha nem is magában a webalkalamzásban, de máshol lehet hogy így eltárolódik. Pl. akár az smtp szervernél.

Max egy limitált ideig érvényes kódot kellene küldeniük.

Az ékezetes karakterekkel csak óvatosan... Egy UTF karakter a jelszócserénél=/bevitelnél, és máris gondban vagy ott, ahol nem utf -ben "gondolkodik" a kliensed. De a több bájtos karakterek a jelszóerősséget vizsgáló cuccokon is képesek érdekes eredményt produkálni, mert utf esetén nagyon nem mindegy, hogy bájtban vagy karakterben mérik a hosszát a jelszónak...

2024 ide, vagy oda, a multibyte-os karakterek kezelése még nincs mindenütt jól és egységesen megoldva. És ha a jelszóban "а" látszik, akkor az vajon milyen karakter valójában?

Ha meg ügyfél oldali interakció is van, akkor ott a jelszókezelést bizony a legnagyobb közös halmazra kell kialakítani, az meg nem az UTF-8, sajnos.
 

Szerintem sincs sok értelme, de én értem, hogy mi a logika mögötte. Nem a speciális karakterek a lényeg, hanem hogy az ilyen "password", "12345", "asdfghjkl", "qwertyuiop", "marika1963" és egyéb elmés jelszavakat használó lusta felhasználókat rászorítsák egy kis kreativitásra. Hogy ha a túl egyszerű jelszót nem engedik, meg speciális jeleznek, akkor az már elgondolkodtatja a felhasználót, meg megnöveli az esélyét, hogy valami egyedibbet talál ki.

Egyébként egyetértek, azzal, hogy a jelszót bonyolítják, és a felhasználó nem tudja megjegyezni meg fel kell írja valahová, azzal már nem hogy a biztonságot nem növelik, de egyenesen csökkentik is, így ez két élű fegyver.

The world runs on Excel spreadsheets. (Dylan Beattie)

Hogy ha a túl egyszerű jelszót nem engedik, meg speciális jeleznek, akkor az már elgondolkodtatja a felhasználót, meg megnöveli az esélyét, hogy valami egyedibbet talál ki.

Hat, max millióból egynek. A többi a végére basz még valamit, azt kész. (Nagy ritkán az elejére, esetlek kicserél egy s-t egy $-ra).

felhasználókat rászorítsák

Ilyen csodás rászorítós ötlet volt régebben a kötelező rotálás is, ugye? Nem véletlen antipattern mára, ezzel csak azt éred el, hogy megy egy postiten a monitor szélére...

Van olyan hazai csodarendszer, ahol a lastpass által generált 40 karakteres jelszó nemjó, mert nincs benne magyar ékezetes karakter. Azért az ilyen nyalhat sót. 

Elvileg modern rendszeren akkor is be tudod adagolni ASCII vagy Unicode kódokkal, de igen, mindenképp szívás lehet néhány ponton, nagyon egységsugarú felhasználónak én se ajánlanám, hogy túl spéci karakterekkel vitézkedjen.

The world runs on Excel spreadsheets. (Dylan Beattie)

Post az egységsugarú le van szarva... De amikor egy valami KVM konzolnon kell beverni egy root jelszót a Windows fizikai gépen futó linux VM-be, úgy hogy localban magyar, a kvm billentyűzete szerint német, a fizikai gép szerint angol, a virtuális gép szerint meg megint magyar billentyűzet van... Sok sikert a kisakkozásához, hogy egy '#' vagy akár csak egy 0-t hogy írsz be.

"Sose a gép a hülye."

Szerkesztve: 2024. 09. 18., sze – 12:45

Jobbat mondok: Magyar Bank. Jelszópolicy: 3 havonta meg kell változtatni, de különbözzön az előző 10-től.

Oké, jelszó begépel elfogad.

3 hónap eltelt, jelszót váltani kell. Megváltoztatom: erre írja, de hát nem lehet ugyanaz, mint az előző. De hát nem ugyanaz, mint az előző, hisz az utolsó 3 karakter különbözik!!!!

Várjunk csak!

Kilépek, belépek, de az utolsó karaktert kihagytam. -->÷ Beenged.

Ó, de jó, kilépek

belépek, de az utolsó két karaktert kihagytam. -->÷ Beenged.

Ó, de jó, kilépek

belépek, de az utolsó három karaktert kihagytam. -->÷ Beenged.

Ez így ment sokáig:

10 karakterig mentette el a jelszót. Na most melyik jobb, ha 3 havonta rövid jelszavaid vannak, vagy ritkán váltott, de hosszú? Az elfelejtett jelszavasokra is gondolni kell.

hup.hu##article[data-comment-user-id="16401"]

hup.hu##article[data-comment-user-id="4199"]

Zseniális az is.

Azt hiszem Konica Minolta MFP-k voltak régen olyanok, hogy pl. SMB passwordhöz bármit beírhattál, írta hogy elmentette... Ezt követően illetve by default "security" címszó alatt fixen talán 6 csillagot mutatott a jelszónál. És hetekig szoptunk vele (a mai napig szokásos MFP-scannelés szarakodás mellett), mire rájöttünk, hogy 8 karakternél lecsapja a jelszót. Jah, végül is az első 8 karaktert sikeresen elmentette.

Én azt szoktam javasolni, hogy nem kell 3 vagy akárhány havonta cserélni, mert annak úgyis az lesz a vége, hogy ott lesz a postiten a monitoron vagy a határidőnaplóba az asztalon felírva. Legyen inkább egy rendes jelszó, amit meg tud jegyezni, be tud írni, és kész. Annak több értelme van szerintem.

"Sose a gép a hülye."

Ezeket a háromhavonkénti cseréket úgy oldottam meg (szerencsére már elmúlt), hogy volt egy viszonylag erős és számomra jól megjegyezhető jelszó, amit a legutolsó változtatáskori dátumból származtatott karakterekkel toldalékoltam. Nyilván szar megoldás abból a szempontból, hogy ha valaki megszerzi az alapjelszót, akkor már nincs nehéz dolga, viszont azt nem volt egyszerű megszerezni.

Az egyik rendszerhez ehhez hasonló a jelszavam: &z2j&q8UQen5D85a^qiD&GQ3 24 karakter, kisbetű, nagybetű szám, különleges karakterek véletlenszerű sorozata. Szerinted megjegyeztem, vagy txt-ben az asztalon van azzal a névvel elmentve, aminek a jelszava? :D Gratuláltam a rendszergazdának az átgondolt jelszópolicyért.

hup.hu##article[data-comment-user-id="16401"]

hup.hu##article[data-comment-user-id="4199"]

Anno security architect koromban kaptam a product managertől olyan feature request-et, hogy lehessen olyan password policy, hogy a korábbi jelszavaktól legalább X karakterben különbözzön. Nyilván mondtam, hogy ezt ugye nem gondolja komolyan. Nevetett, de aztán mondta, ez halál komoly ügyfélkérés, és valahogy mégiscsak meg kéne oldani, mert nagy ügyfél, a termékünk emiatt nem felel meg a policy-jüknek. Kb fejből felsoroltam az összes formális requirement-et, azonosítószámmal, melyik excel táblában van, melyik tabon, amikre hirtelen non-compliantek leszünk ha leimplementáljuk nekik.

Régóta vágyok én, az androidok mezonkincsére már!

Hát, ha ez a kérés, meg kell csinálni... csak ugye nem árt megmondani, hogy ezért lett olyan marha lassú az alkalmazás... mert ugye ha nem akarjátok plaintextben tárolni a jelszót, akkor jelszó váltáskor gyakorilatilag az összes X karakterrrel eltérő jelszóval generált hash-el össze kell hasonlítani. Vagy volt valami jobb ötlet hogy lehet ezt gyorsabban kivitelezni?

Igen, eredetileg az volt a koncepció, hogy a korábbi X db jelszóhoz képest az új legyen legalább páronként Y db karakter eltérés (nem volt ennyire szépen specifikálva, de erre gondolt a költő). Vagyis tárolni kellett volna valahogy - szigorúan nem plaintextben, de mégis karakterenként összehasonlítható módon - a korábbi jelszavakat. És persze a korábbi jelszvakat encryptáló kulcs sem lehet plaintextben tárolva... és innentől "it's turtles all the way down" probléma van.

Sportszerű nehezítésként ezt lehetőleg a Keycloak nevű identity management és oauth provider szoftverrel, és lehetőleg anélkül, hogy el kéne forkolni és saját ágat kelljen karbantartanunk belőle.

Egyébként meg lehetne oldani, ha a korábbi jelszavak listáját nem hash-elve, hanem encryptálva tároljuk és a user aktuális jelszavából valami PBKDF-fel lehet decryptálni, de ez full custom fejlesztés rengeteg buktatóval, néhány másik compliance követelményt megsértve.

A megoldás egyébként az lett, hogy tényleg csak a legutóbbihoz képest hasonlította össze és - nem röhög! - ez a frontendben lett megoldva, a jelszóváltó formon mikor beírod a régi jelszót, majd az újat kétszer, mert itt még plaintextben elérhető mindkettő. Ugyanis arra volt lehetőség, hogy az ügyfél a saját kinézetére brand-elje a jelszóváltó oldalt és oda lehetett teljesen ügyfél-specifikus customizációként berakni ezt az ellenőrzést, így az upstream szoftverhez sem kellett hozzányúlni, nem borultak a compliance követelmények sem. Más kérdés, hogy egy trükkösebb felhasználó ugye ki tudja játszani ezt (és csak ezt) a követelményt, mert nincs backend-oldali ellenőrzés mögötte, de ez már nem érdekelt senkit. (Szerintem az ügyfél valójában nem is használta ezt a feature-t, csak az excel táblában ki kellett pipálni, hogy lehetséges).

Régóta vágyok én, az androidok mezonkincsére már!

a jelszóba mindenképp speciális karakter, mert attól lesz jó...

Es nem ertik, hogy ezzel praktikusan nem novelik, hanem csokkentik az ellenorizendo teret. Valojaban a nagy tobbseg nem fog emiatt tobb specialis karaktert, szamjegyet, nagybetut rakni, vagy hosszabb jelszot generalni, hanem a "kotelezo, tehat egy" es "minimum hossz = hossz" mintat koveti. Igy a ter valojaban lenyegesen kisebb lesz.

Igen, alapvetően igaz, legalábbis elméleti szinten. Ugyanakkor ha nincs a jelszóban kötelezően szám és speciális karakter, akkor a nagy többség nem is fog beletenni, tehát a gyakorlatban a jelszavak túlnyomó része így fog kisebb teret kezelni. Emiatt ha a brute-force jelszótörő először csak az ASCII karakterekkel kezd, várhatóan gyorsabban végez azokkal a jelszavakkal, ahol nem volt policy a szám/speciális karakter.

Egyik utolsó munkahelyemen minimum 14 karakteres jelszó kellett, betű, szám, speciális jel. 3 havonta cserélni.

ÉS nem volt engedélyezett jelszó manager telepítése.

Más helyeken legalább egy KeePasst hagytak feltenni.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Hú, az gáz. Mondjuk ha posix/unix/unixlike rendszeren vagy, akkor alap core util és shell megoldásokkal tudsz magadnak írni jelszókezelőt, vagy akár Windowson is be fogsz tudni valami titkosítós vagy PGP aláírós, vagy jelszóval tömörítős megoldáshoz folyamodni, és azt kvázi jelszókezelőként használni.

Sőt, vannak online jelszókezelők is, vagy feltelepíted a telefonodra. Ma már sok megoldás játszik.

The world runs on Excel spreadsheets. (Dylan Beattie)

https://pages.nist.gov/800-63-3/sp800-63b.html

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.

Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules. For example, a user that might have chosen "password" as their password would be relatively likely to choose "Password1" if required to include an uppercase letter and a number, or "Password1!" if a symbol is also required.

A csodálatos RePont app játszotta el velem múltkor: Legyen spec. karakter, de csak bizonyos felsoroltak, más még véletlenül se!

Mondanom sem kell, regisztrálnom amúgy ettől függetlenül sem sikerült, mert "a felhasználó már létezik", de beléni nem tud, jelszóemlékeztető kérésre pedig "a felhasználó nem létezik" :D

 

Kicsit olyan érzésem van, mint "Ezt a jelszót már bubuka felhasználó használja, válasszon másikat!"

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

jelszó módosításhoz kell a régi jelszó. ahhoz elég lenne akkor bekérni. a számlaszámhoz is lehetne ilyet, és akkor nem az lenne, hogy mikor hetente egyszer megyek visszaváltani, akkor jelentkeztet ki

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

ráadásul valami beágyazott böngészőbe dob át.

Ez mondjuk az aktuális best practice, múltkor kikerestem ide valakinek az RFCt is.

Itt is van https://hup.hu/comment/3101099#comment-3101099

A kiléptetés ettől függetlenül gáz, a francért nem élhet évekig a sessionöm a vacak QR kódhoz.

Szerk.: és az áll, amit ott is mondtam, hogy androidon lehetne ezt sokkal kulturáltabban csinálni, mint a repont. Ha jól csinálják, észre se veszed, hogy browser. 

Engem meg az zavar, hogy a mi a bánatos istenért kell egy Bar/QR kódhoz egy app? Auchan, LIDL, MOL stb. ugyanez.

Egyszer felteszed az appot, csinálsz róla egy screenshotot, aztán letörlöd a picsába. Galériában ott van, de amúgy nekem konkrétan ki van LIDL és MOL nyomtatva, és a régi ügyfélkártyára rá van ragasztva, mert ott a pénztárcában mindig kéznél van. Van pénztáros, aki simán csak mosolyog... Van amelyik csípőből mondja, hogy jajj az már nem fog működni... Mondom DE, FOG. :D

"Sose a gép a hülye."

Nekem a Catima lett a megoldás. Egyszer beszkenelem a kártyát és onnan mindent is kezel. Az összes ilyen bevásárlókártyám és qr kódom benne van. F-droidról is elérhető. És tud olyat is, hogy galériából vagy pdf-böl importál.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Szerkesztve: 2024. 09. 19., cs – 22:24

Mondok jobbat, van, ahol ma sem engednek akármilyen speciális karaktert a jelszóban, pl. OTP SZÉP kártya portálja, vagy MVM online ügyintézés. Persze a böngészőben futó validátor még megeszi. Az üres hibaüzenet meg nyilván azt akarja sugallni, hogy üresen hagytam a Jelenlegi jelszó mezőt.