( arpad | 2025. 01. 04., szo – 23:47 )

Igen, ez így működik, tudom, használtam és egyébként nem kötelező authentikátor alkalmazással beolvasni. Az csak fakultatív, nem kikényszeríthető technikailag.

De amit leírtál abban ugyanúgy benne van hogy a te klienseden kívül a szerveren is el van tárolva a secret és én arra mutattam rá, vagy csak akartam, hogy ha te mindent is megteszel akkor is van egy másik fél - a szerver illetve a szolgáltatás üzemeltetői - aki hozzáfér a secrethez.

A szerveren lehet titkosítani a secretet, akár felhasználónkénti egyedi kulccsal, de erre neked mint mezei usernek nincs rálátása, ráhatása. Pont mint egy jelszó esetén. Ott is csak elhiszed/reméled hogy egy salted hash algoritmus eredménye kerül a neved mellé mint jelszó és nem clear text.

A user - és egy támadó - szemszögéből a TOTP secret egy "második jelszó". A támadónak nem a generált kódot kell megszereznie, hanem a shared secretet. Emiatt én nem tartom igazi második faktornak, hiszen elég a monitorra ragasztott cetlire egy új sorba felírni a shared secretet - ami meglehetősen rövid - és ugyanott vagyunk mint ahonnan indultunk.

Az egyetlen előnyét abban látom hogy a felhasználók szeretik mindenhova ugyanazt a jelszót használni és a TOTP kikényszerít egy kötelező egyedi "második jelszót". Így ha egy szolgáltatás kompromittálódik, akkor más login nincs veszélyben. Azaz ha a felhasználók nem tanulnak meg egyedi jelszavakat használni akkor ezzel lényegében kényszerítve lesznek. Ha jobban belegondolsz ilyen esetben maga a jelszó akár el is hagyható, hiszen a TOTP generált kódnak is elég. Elvileg.

 

Szerk: Ha emlékszel még a Digest authentication-re HTTP felett akkor az is shared secret alapon ment, de sosem terjedt el.