Egyes mentett jelszavait megtaláltuk az interneten

"Mán h a fullskilles elgondodolásod szerint a hash-elt jelszó a különzö oldalakon pl. Drupal és egyéb oldalak ugyan az lenne, és így a jelszó ismerete nélkül is megállapítható az azonosság?"

Nagyon remélem, hogy salt nélkül már senki nem tárol jelszavakat. Persze az egyedi jelszó is alap lenne, szóval ki tudja.

Részemről arra tippelek, hogy sokévtizedes jelszó, ami valamikor mégis elkerült a Google-höz.

-Regisztrálsz és/vagy bejelentkezel gmail szolgáltatásokkal a Részeges karatemester és társa Bt. webshopjába. A webshop hanyag és a begépelt jelszavad eltárolja, esetleg plain textbe :D ahogy kell. Felnyomják a webshopot, viszik a jelszavakat amik bekerülnek egy közkézen forgó jelszólistába. Az utolsó amit láttam valami 3giga körüli plaintext volt. A G kétsoros programja pedig egész sűrűn végigszkenneli ezt a rengeteg sztringet és ha egyezést talál, akkor jelez neked.

-Nem gmail accoddal jelentkezel be, de a gmail címeddel regisztrálsz. Sajnos ipari mennyiségben látni olyat, hogy a mailcím jelszavát gépeli a delikvens.

-Ha egyik sem ilyen ^^ felállás, akkor az is lehet, hogy a Köcsög és társa bt. valójában G tartományban van, honlappal mindennel. Ha ugyanazt a jelszót adtad meg náluk mint a saját mailcímedét, elsőként a G fog tudni róla.

-A Vivaldiban nem tudom hogyan van, de fixme a megnyitott tabok simán átláthatnak egymáshoz.

-Nagyon hasznos szolgáltatása a G-nek ez a warning, de csak akkor ha a figyelmeztetett tag nem szefós. Nekem legutóbb a feleségem volt figyelmetlen, de a warning valós egyezést mutatott. Megtettük a szükséges jelszócserét ill. amit lehetett két faktorra állítottam. A szefósokat viszont nem igazán érdekli az ilyesmi. A leginkább fárasztó válaszok a "és akkor mi van", "nekem nincs semmi dugdosnivalóm", "a bankhoz úgysem férhetnek hozzá", "vigyék ami kell nekem nincs semmi olyanom", "leszarom akkor majd megyek a rendőrségre ha baj lesz belőle" stb.

Bónusz: ha ghecchi lennék, megvenném a gmail.hu levelezési tartományát és begyűjteném a gmail.com accokat, majd eladnám kilóra. Vinném a hozzá kapcsolt facebook fiókokat mindent. A világért sem akarok tippeket adni a khm.. "kockázati befektetőknek" :D, sokkal inkább figyelmeztetést a lehetséges áldozatoknak. Annyi hülyét láttam, aki gmail.hu-ra gépeli a fióknevet és jelszót, vagy kapkodásában a levélkliensben ezt állítja IMAP címhez. Tehát a lehetőség egészen valós. 

Bárhogyan is, az ilyen jelszómizériában mindig az emberi tényező a ludas. Jó esetben az áldozat figyelmetlenségéből adódóan, rossz esetben a csalók szándékából.

Számomra a password reusage a rémisztő.
Soha ne használd ugyanazt a jelszót különböző helyeken.
Üdvözlendő, hogy elkezdődött az erre való figyelemfelhívás.

Nálam ez úgy van, hogy külön random generált jelszó van mindenhová. Ezeket egy password manager (Bitwarden rulz) tárolja.

Nem amatőr lámerek a Logmein-es fiúk, ma már goto. Dolgoztam velük, szerencsére pont nem lastpass-on :)

A Chrome beépített jelszókezelője a legbiztonságosabb megoldás. Biztonságban a Google mindig kiemelkedett. De tervezem én is elhagyni a Chrome-ot mint elsődleges böngészőt. Ennek oka elsősorban az API változtatás miatt ellehetetlenített uBlock origin. De a jelszókezelés eszközök közötti szinkronizálását nem adom át egy kisebb társaságnak a kezelésébe. 

Az a baj ezzel, hogy a "balfaszok voltak" csak utólag fog kiderülni, addigra meg már megtörtént a baj.

Mondjuk böngészőbe én se mentek jelszavakat, egyikben sem. Bár nem bizalmi oka van, csak szerintem nem elég generális. A webes jelszavak csak egy részhalmazát adják az összes jelszónak. Valamint cross-browser sem szinkronizálódnak. Ezért részesítem előnyben inkább a password managert.
(Bele lehet kötni persze mindenbe, de szerintem egy pw manager még mindig nagyságrendekkel jobb, mint a password re-usage.)

Nem így kell felfogni. Nem kémkednek utánad. Téged az zavar, hogy szembesítenek vele, ha balfasz voltál.
Pszichológiailag nehéz helyzet, amikor lebukás van és elkerülhetetlen, hogy az ember szembenézzen saját magával. Ugyanakkor ez egyben lehetőség is: nem a múlt hibáin kell pörögni, helyette jövőorientáltan kell hozzáállni, és fejlődni, tanulni belőle.

Inkább örülni kellene, hogy valaki figyelmeztet, ha egy egyszerű kereséssel megtalálható a neten a jelszavad.

Gmail-en van a teljes levelezésem. Soha nem éreztem még, hogy bármivel traktálna a google.
A security alert-jeik (új bejelentkezés történt dömdöröm ípécímről...) szerintem rendben vannak a mai világban. Nem esik nehezemre nyomni rájuk egy Del-t.
Azt valóban érezni néha, hogy tolnak valami fele. Pl. a TOTP felől a notification-alapú 2FA-ra. Ezekben a dolgokban azonban nem ,,érdeket" vélek felfedezni. Szerintem inkább a faszuk van tele a sok balfasz júzer bénázásával. Arrafele tolnak, amiből a legkevesebb kérdés, baszakodás fog születni.

Nem lehet, hogy nálad valamiféle tünet ez a paranoia?

csak ugye ezeket a kommunikációs csatornákat nem egyedül használja az ember... szóval bően elég ha másik fél haszálja az általad nem preferált céget/szolgáltatást, és máris a Te adataid is a kezében vannak. Jó, lehet a jelszavaid épp nem, csak minden más ;)

szóval, attól hogy neked nincs facebook/google/apple/akármi accountod, attól még ~mindent tud(hat)nak rólad, az 'ismerőseiden' kesztül.

Mert úgy múködik. A fentebb linkelt wikin is írják.

However, this presents a problem for many (but not all) challenge-response algorithms, which require both the client and the server to have a shared secret. Since the password itself is not stored, a challenge-response algorithm will usually have to use the hash of the password as the secret instead of the password itself. In this case, an intruder can use the actual hash, rather than the password, which makes the stored hashes just as sensitive as the actual passwords. SCRAM is a challenge-response algorithm that avoids this problem.

Az Apache oldaláról (https://httpd.apache.org/docs/2.4/mod/mod_auth_digest.html):

This module implements HTTP Digest Authentication (RFC2617), and provides an alternative to mod_auth_basic where the password is not transmitted as cleartext. However, this does not lead to a significant security advantage over basic authentication. On the other hand, the password storage on the server is much less secure with digest authentication than with basic authentication. Therefore, using basic auth and encrypting the whole connection using mod_ssl is a much better alternative.

Nem pontosan így működik (nagyon nem), de a logika talán érthető:

• A szerver elküld neked egy egyedi challenge-et, egy random stringet és küldd vissza a hash( challenge + password ) eredményét.
• Te megcsinálod, a neten csak ez a hash megy át amiből a jelszó nem található ki.
• A szerver kap egy bithalmazt, amiről el kell döntenie hogy jó-e. A challenge értékét ismeri, ahogy a hash algoritmust is, de kell neki még a jelszavad is hogy elő tudja állítani az eredményt. Mivel a neten nem megy át a jelszavad még titkosítva sem, ezért helyileg kell tudnia előkotornia.

A SCRAM ezt bonyolítja el egy kissé hogy a jelszó mégse legyen letárolva, de Digest auth az még RFC2617, míg a SCRAM RFC5802, jóval későbbi.

Akkor ponrtosítom: a szerveren clear textben kell tárolni azt a karaktersorozatot, amit a kliens felől érkező adat helyességének vizsgálatához szükséges. Teljesen mindegy, hogy a P megy át a dróton, és a szerver oldalon is a P van tárolva, vagy S=f(P,s) megy át, és a szerver oldalon is az S=f(P,s) van tárolva.