Hurrá, Firefox megjegyezte a jelszavamat!

Az alapprobléma: a nagyon éber https://www.nejegyezzmegjelszot.hu tiltja a Firefoxnak a jelszó megjegyzését (olyan HTML-technikával, amit nem értek, és nem is akarok megérteni, van benne autocomplete=off is, meg más is, nem fontos.)

Nagyon egyszerű lesz az egész, gondoltam: csak telepítek egy "Saved Password Editor" nevű addont, és már tudok is userid+password párokat tárolni/szerkeszteni/törölni.

Vagy nem? Az az addon már régen megszűnt működni, részletek itt.

Szóval a következő egyszerű megoldást választottam: meghaxoltam a /etc/hosts fájlt, hogy a www.nejegyezzmegjelszot.hu a 127.0.0.1-re mutasson.

Meghaxoltam a lokálhost tanúsítványát, hogy tartalmazza a www.nejegyezzmegjelszot.hu-t mint 'Subject Alternative Name'.

Ráirányítottam a browsert a https://www.nejegyezzmegjelszot.hu/tesztforms/loginform.php-ra. Beírtam a userid+jelszót, Firefox megkérdezte, hogy mentse-e, mondtam neki mentse.

Végül /etc/hosts-ot visszaállítom, tanúsítványt visszaállítom, örülök.

De ha a Firefox piaci részesedése esetleg tovább csökken, az nem a véletlen műve lesz.

[Utolsó szerkesztés: 2018.12.21. 17:44 Értelmesebb fogalmazás]

( uid_4263 v | 2018. 12. 21., p – 10:52 )

Csak én nem értem?

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

( ricsip v | 2018. 12. 21., p – 10:55 )

weboldalak tudják mondani ffox-nak, h. "ne engedd a gazdádnak elmenteni ezen az oldalon a jelszót?"
--

Kevésbé aggasztó amit 10 emberből 9 csinál: felrakja a chrome-ot, bejelentkezik a google-höz, majd elkezdi a jelszavait a chrome local profilba ÉS felhőbe pakolni (nem titkosítva tudomásom szerint).

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Anno ezt js-ből trükköztem meg: az onsubmit()-ra rá lett akasztva egy függvény, ami a jelszómező tartalmára ráhúzott egy sha1/md5/akármi egyirányú kódolást. A böngésző meg bután az onsubmit() futása _utáni_ értéket jegyezte meg, ergo a következő alkalommal az elmentett jelszóval nem lehetett belépni...

Persze voltmég más trükk is, de ez volt az alap. (A js-t kikapcsolva más okból nem volt elérhető az oldal...)

Azt, hogy a böngészőben elmentett valamivel később be lehessen lépni. Közösen használt kliens oldali user esetén (erre ugyanis nem volt a "másik oldalnak" semmiféle ráhatása, még szabályozási oldalról sem) a böngészőben megjegyeztetett jelszóval egymás accountjához simán hozzá tudtak volna férni, ami erősen nemkívánatos dolog volt. Emiatt (is) adódott a feladat, hogy a jelszó elmentését akadályozzuk meg valamilyen módon.

Közösen használt kliens oldali user esetén (erre ugyanis nem volt a "másik oldalnak" semmiféle ráhatása, még szabályozási oldalról sem) a böngészőben megjegyeztetett jelszóval egymás accountjához simán hozzá tudtak volna férni, ami erősen nemkívánatos dolog volt.

about:config sanitizeOnClose erre szép megoldás (és az még a sütiket, előzményeket és minden egyéb szemetet kipakol - de úgy rémlik egyesével lekapcsolhatók). Chrome-on passz, hogy group policy nélkül hogy lehet beállítani, IE-n szintén, de mindhárom browsernél megoldható.

(rejtett subscribe)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Tizensok évvel ezelőtt volt, a kliens oldalra semmiféle ráhatással nem bírtunk - már az is nagy előrelépés volt, hogy a "szakmai vezetés"-en át lehetett nyomni azt, hogy a régi IE-only vackot kidobva böngészőfüggetlen felületet csináljunk, aminek az "ára" az volt, hogy js kellett hozzá. A bejelentkezéskor onsubmit()-ra elkódolt password mező meg ezért _is_ kellett: ha nem működött a JavaScript a böngészőben, akkor nem lehetett bejelentkezni.

> Emiatt (is) adódott a feladat, hogy a jelszó elmentését akadályozzuk meg valamilyen módon.

Szerintem erre (is) valo a token. A jelszo utan tokent es refresh tokent ad a szerver. Olyan rovid elettartamot is be lehet allitani, hogy 1-2 perc, vagy websocketen akar 10masodperc.

De ha a tokenezes ordogtol valo, akkor a jelszot le lehet taroltatni a sessionStorage-ban (nem a localStorageban), annak a tartalma torlodik minden kilepeskor.

Szerintem ha ezeket mind kiaknaztuk, es meg mindig megoldhatatlan a problema, akkor johet elo a group policy, de szerintem az egy lyukas koncepcio....

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( Carter | 2018. 12. 21., p – 11:02 )

Ez a gyönyörű megoldás majd 1000 év múlva is itt fog állni bizonyítékként, hogy az ember okosabb, mint a gép!
Mindenesetre erősebb...

Erről egy régi eset jutott eszembe mikor a kocsmában a DJ mondta büszkén:
- Jobb zenéket játszok, mint a zenegép!!
- Hháááááááát
- De olcsóbb vagyok, mint a zenegép!
- Háááááát
- De részegebb vagyok, mint a zenegép!
- Na, az biztos!

Van, amikor a webes felület a munkaeszköz, amihez a munkáltatódtól kapsz hozzáférést, ez az egyik. A másikmeg az, hogy az érintettek felelőssége abból a szempontból is vizsgálható egy biztonsági incidens esetén, hogy megtettek-e minden lehetséges és arányos intézkedést annak elkerülésére? Ilyen intézkedés a weboldal üzemeltetőjétől az oldal ssl-re rakása, valid, általánossan elfogadott CA által kibocsátott tanusítvány használata, jelszavak, hozzáférési tokenek kezelése a szerver-oldali alkalmazásban, adatbázisban, hozzáférési adatokat tartalmazó DB szeparálása, satöbbi, satöbbi, satöbbi. Ebbe a körbe tartozik az is, hogy lehetősége szerint a kliens-oldalon is korlátozza az érzékeny adatok tárolását.

Nem kell a munkáltatódnak lennie ahhoz, hogy az oldal üzemeltetője minden elvárható biztonsági intézkedést megtegyen a bejelentkezési adatok védelme érdekében - ezen intézkedések egyike (bár hogy sok esetben inkább kontraproduktív (sárga cetli...)) lehet a jelszó kliens-oldali rögzítésének a tiltása/megakadályozása.

A másolókrémet (kopipaszta) nem lehet értelmesen kivédeni (bár láttam már kísérletet rá), a böngésző általi tárolást igen. Ha pedig valamely védelmi intézkedést meg lehet tenni, azt elővigyázatosság céljából célszerű lehet megtenni.
Ha a böngészők a jelszótárat kötelezően erős jelszóval védetten kezelnék, akkor nem lenne értelme tiltani, illetve megakadályozni a jelszavak kliens-oldali, böngésző általi tárolását.

Nem garantálható a jelszavak védett tárolása a kliensen, ha azt a böngészőre bízzuk. Onnantól kezdve meg bármilyen technikával, egy fájl olvasásával kompromittálódhatnak a jelszavak. Mivel ez ellen lehet úgy védekezni, hogy a böngészővel történő jelszótárolást megakadályozza az oldal, így elővigyázatosság okán teljesen védhető álláspont, hogy a böngészővel ne tároltasd el a jelszavadat. Van rá megfelelően biztonságos, "hülyebiztos" (nem tudsz almafa123 jelszót adni a tár védelmére, memóriában is "ügyesen" tárolja a szenzitív infókat, etc.) alkalmazás is, tessék azt használni, ha szükséges, hogy automatikusan ki lehessen tölteni a jelszó mezőt.

Egy alapesetben nem titkosított fájlod van, mint jelszótár, és ezt az állományt a böngésző (meg bármelyik program, ami a nevedben, vagy emelt szintű jogosultsággal fut) képes olvasni. Innentől kezdve n+1 módja van, hogy a jelszavaid illetéktelen kezekbe/alkalmazáshoz kerüljenek.

> sárga cetli, a jelszavak.txt fájl
User ra van kenyszeritve YpuW5FTT bonyolultsagu jelszavak megjegyzesere. Ebbol azonnal sarga cetli lesz. Annal minden jobb, az is ha a bongeszo tarolja. Aki pedig eljut a password managerig, az egy master passwd-t is be tud allitani maganak.
____________________
echo crash > /dev/kmem

+1

Én is úgy érzem, hogy egy nem tökéletes biztonságú dolog ellen harcolva kikényszerítjük, hogy a felhasználók nagy része valami sokkal rosszabbat használjon.

Szerintem nem a weboldal feladata az, hogy megpróbálja a felhasználókat akármire rászorítani. Főleg úgy, hogy a legrosszabbat: a monitorra ragasztott post-itet nem tudja kivédeni.

Nomostan mennyibe tellene a böngészőnek azt mondani, hogy "ha a jelszókezelőt használni szeretnéd, állíts be hozzá egy master passwordot!"? Jaaaa, hogy az usereket a böngésző a saját hülyeségüktől (elfelejtett master pw) megvédi, de a másik hülyeségtől (ami sokkal problémásabb), hogy a jelszavaikat egy titkosítatlan fájlban tárolják, attól meg dafke nem.

Nem érzem óriási problémának.

Az átlag felhasználónak az eltárolt jelszavaihoz a másik átlag felhasználó nem fér hozzá. Nem azért, mert titkos meg minden, hanem mert azt se tudja, hol kell keresni.

Bezzeg ha nem jegyzi meg a böngésző, akkor majd felírja papírra, azt meg bárki látja, aki a szobába belép.

Ha a felhasználó valamivel haladóbb, akkor úgyis vagy használ mester jelszót, vagy titkosított jelszó kezelőt.

No mindegy, értem most már, hogy mi ellen "jó", csak éppen nem gondolom, hogy egy weboldalnak a dolga, hogy ez ellen próbáljon tenni.

Ha egy céges group policy azt mondaná, hogy tilos a böngészővel jelszavakat megjegyeztetni, ÉS az éjjeliőr minden munkaállomást végignézne esténként, hogy lát-e jelszavas cetlit ÉS mindenki gépén alapból lenne egy titkosított jelszókezelő alkalmazás ÉS a belépéskor az új embereknek megmutatnák, hogy kell azt használni, az egy jó védekezés.

Az, hogy egy egyébként semmi fontos adatot nem tároló weboldal úgy döntsön, hogy ebből a sokból egyet meglép, az nem jó semmire.

"azt se tudja, hol kell keresni" - Egy rosszindulatú program szépen végig tudja turkászni a megfelelő fájlokat, mert az tudja, hogy hol keresse, ez az egyik. A másik, hogy egy windows-os loginnal nem garantálható, hogy csak és kizárólag egy user fog dolgozni - egyszerűen azért, mert nem tudják, hogy kéne, és ha tudják is, akkor az a gond, hogy nem látják a közösen használandó fájlokat. Ne tudd meg, milyen konstruktívak ezügyben a felhasználók...
A sárga cetlit a böngészővel/OS-sel bezárólag nem lehet megakadályozni, azt adminisztratív úton kell tiltani - és a tiltásnak (akár megfelelő retorziókkal (v.ö.: a statuálás a fontos)) érvényt szerezni.

"Ha a felhasználó valamivel haladóbb, akkor úgyis vagy használ mester jelszót, vagy titkosított jelszó kezelőt." - vagy nem, a "ha a nagyanyámnak áramszedője lett volna..."-ra nem építhető biztonság.

"semmi fontos adatot nem tároló weboldal" - ay oldalon hasynált identitás és ay ahhoy kapcsolódó adatok, tevékenzségek nem fontosak - szerinted. A kérdés: "megtett-e az oldal üzemeltetője/fejlesztője minden tőle telhetőt azért, hogy a bejelentkezési adatok biztonságban legyenek?" A szerver-oldal igen, a böngésző oldal viszont NEM, mert semmilyen kikényszrített védelem nincs a jelszótárolásnál.

Nem a szerver oldalon kell azt managelni, hogy a kliens oldalon vélhetően nem tudja használni a számítógépet a felhasználó, s ezzel az őrületbe kergetni azokat, akik viszont tudják használni a gépüket.

Én saját profilt használok, s nekem jegyezze meg a jelszót, mert baromi idegesítő text file-ban titkosítatlanul tárolni, majd clipboard-on keresztül másolni mcview-ból az input mezőbe a jelszót, nemkülönben ráadásul kevésbé biztonságos is. Viszont rákényszerítenek azok a gyökerek, akik így csinálnak weboldalakat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

+1

Mi lesz a következő? A weboldal IT biztonsági tesztet végeztet a felhasználóval és kötelező tréningeket ír elő, hogy legyen biztonság?

Szerintem ez szereptévesztés.

Weboldal fejlesztőjeként az az elvárható, hogy a szerveroldal biztonságos legyen. Hogy a másik oldalon mi van, böngésző, valami program mint wget vagy curl, vagy egy telnet ablak előtt egy felhasználó aki a protokolnak megfelelően próbálja begépelni a dolgokat, az nem a weboldal felelőssége.

A bőngészők fejlesztőit kéne inkább ekézni: nem kerülne sokba a default nincs jelszó megváltoztatása az "egy erős jelszót tessék megadni, mielőtt helyben tárolod a jelszavaidat" állapotra. Igen, utána lenne sok f@sz user, aki elfelejti a master pw-t, és azzal megy a levesbe az összes jelszava, és ezt gondolom, nem szeretnék felvállalni...

De az legyen a user felelőssége, hogy a jelszavát kivel jegyezteti vagy épp nem jegyezteti meg, ne a site-é. Ugyanúgy ahogy az is a user felelőssége hogy milyen minőségű jelszót használ*. A password manager kiiktatásának negatív következménye lehet a gyengébb jelszó használata, ezért ez nekem eléggé kontraproduktív lépésnek tűnik.

* erről jut eszembe, soha nem értettem hogy bizonyos speciális karakterek használatát miért tiltják egyes oldalak, tipikusan olyanok ahol pénzügyi/személyes adatokat kezelnek. Kedvencem az OTP SZÉP kártya oldala, ahol miután megtagadja a jelszó használatát, még ki is írja az oldalra a jelszóban használt tiltott karaktereket, abban a sorrendben és annyiszor ahogyan a jelszóban használtad. https://snag.gy/k8m1oM.jpg

Egyébként nem értem miért jó az egy sitenak ha nem engedi a browser password managerét működni.

nagy +1

Persze, lehet ilyen paranoid őrültségeket csinálni, csak a user kényelmesebb. Ha nem megy a browserrel, megy textfile+copypaste-tel. Ha az sem megy, vagy nem elég kényelmes, akkor megy a monitor alsó élére ragasztott postittel. Kedves rendszergazdák, ugy-e hogy jobb lett volna a browser?

A futykömprötyköm.txt nagyjából ugyanazt a biztonságot (semmit) nyújt, mint a jelszavazatlan json fájl a böngésző által kezelve. Sőt picit többet is akár, hiszen ahhoz a böngészőnek nem kell rw joggal hozzáférnie, nem egy jól ismert helyen van. A postit meg csak helyben támadható, távolról nem :-P

( zeller | 2018. 12. 21., p – 12:30 )

Van egy logins.json fájlod a FF profilodban, azt is lehet szerkeszteni :-)

( NevemTeve | 2018. 12. 26., sze – 12:05 )

Off: adott esetben, mielőtt csodákat implementálunk html-ben és js-ben, olyasmire is lehetne gondolni, hogy szerveroldalon sosem tudhatjuk biztosan, hogy a kliens tényleg böngésző-e, vagy esetleg célprogram (vö: libcurl).