Működhet / Használja valaki az F-Droidon elérhető FreeOTP alkalmazással?
Hozzászólások
Az Ügyfélkapu plusz bármilyen TOTP authentikátorral használható.
Maga a TOTP nem egy űrtechnológia, nekem sikerült kb. húsz-harminc sor programkódban implementálnom. A FreeOTP-t nem ismerem, de mivel azt mondják magukról, hogy tudnak TOTP-t, ezért igen erősen merem feltételezni azt, hogy működni fog.
Olyannyira nem, hogy RFC6238, és az "A" melléklete tartalmaz egy referencia implementációt is. Egyébként a TOTP-s alkalmazásokban nem az időfüggő kód generálása a trükkös/problémás, hanem a generáláshoz használt secret tárolása, illetve védelme - amit az alap totp motyók az OS-re/szoftverkörnyezetre bíznak - azaz semmi sem garantálja, hogy 3. fél nem fér hozzá/nem tudja lemásolni...
Működik, csak fikázza a tokent (valószínűleg jogosan :)):
Token is unsafe!
The token you are attempting to add contains
weak cryptographic parameters.
Use of this token is strongly discouraged!
Please alert your token provider.
Cancel
Add anyway
Google: A FreeOTP akkor mondja ezt, ha 128 bitesnél gyengébb (esetünkben: 80 bites) tokent adsz neki. Kompatibilitás: a régebbi authenticator programok nem tudtak 80 bitesnél nagyobbat.
Az algoritmusnak erős megosztott titkot KELL használnia. A hossza a megosztott titoknak legalább 128 bitesnek KELL lennie. -írja [RFC4226](https://datatracker.ietf.org/doc/html/rfc4226#section-4 ) 2005 decemberében. Ugyan ez 2005-ben készült a dokumentum 160 bites megosztott titok hosszt ajánl.
oauthtool csinál ilyen tokeneket Linuxon parancssorból. A lényege az, hogy egy kiinduló kulcstól és a pontos időtől függ, hogy mit ad, és a szerver ellenőrizni tudja, hogy tudtad a kulcsot, de a token az idő lejárta után nem lesz használható. Csak a privát kulcs, az idő és számolási képesség kell hozzá (Esetleg random source? Nem tudom.), bármire meg lehet írni és van is 1000 féle implementáció.
Az oauthtool-t szerintem valahogy lehet a jelszókezelőkbe is integrálni, talán úgy a legegyszerűbb használni. Valaki biztos csinált belőle online alkalmazást is, bepasztázod a kulcsot és ad egy aktuális tokent. Ezzel adhatunk egy nagy pofont a biztonságnak.
> Csak a privát kulcs, az idő és számolási képesség kell hozzá (Esetleg random source? Nem tudom.)
csak a shared secret (sajnos nem asszimetrikus, nincs privat es publikus kulcs kulon) es a timestamp kell neki, semmi mas. szamolni se kell sokat, nem attol lesz biztonsagos, hanem kell DoS vedelem az oldalon, hogy percenkent max 3-5 probalkozast engedjen ugyanazzal az userrel. igy a 6 szamjegyu otp-t kitallani 3 probalkozasa van (ez kb ugyanannyira biztonsagos mint a telefon feloldo pin kodja) utana valtozik a kod es kezdheti elolrol a probalgatast.
> Valaki biztos csinált belőle online alkalmazást is
mindenhol a totp.app websiteot ajanlgatjak hozza, en meg nem probaltam, nem biznek ilyet senki masra
Sőt, az idő lejáratot se mutatja. Valamint nem találtam meg, hogy hogyan lehet kinyerni belőle az egyes kódok paramétereit - elsősorban a shared secret érdekel persze. (Hasonlóan a Google Autentikátorból sem.) Ellenben az Aegis-szel.
Az F-Droidos sima QR és Barcode Scanner is tud ilyen one time passwordot/tokent generálni. Van egy oldal, ahonnan a céges fizetéscetliket töltöm le. Persze MS Authenticator ajánlott de én ilyesmit nem telepítek a telefonomra. Bescanneltem a QR kódot a fentebb említett app-al és lám, működik, időközönként generál egy újabb számot.
Telefon cserekor elég volt a régi telón megnyitni a QR kódot, az újjal meg bescanneltem és migrálva is volt. Ha ez a lehetőség nincs akkor az oldal által első belépés után generált valamelyik egyedi, egyszer használatos kódot kellett volna használni, amiket már el is felejtettem, hova mentettem el.
Minden hulla a Mount Everesten valamikor egy nagyon motivált ember volt.
A kétfaktoros azonosítás január második felében tovább egyszerűsödik: a hitelesítő alkalmazások mellett már e-mailes visszaigazoló kódot is használhat.
Hatalmas biztonsági előrelépés ez (ja nem), de legalább így a könyvelők megint nyertek akik a könyvelőiroda e-mail címével regisztráltatták be az ügyfeleket.
Ha már itt tartunk, valaki meg tudja mondani, hogy miért lett divat bankoknál és sok más helyen (mondjuk az ügyfélkapun pont nem) a user acc. helyett az email cím?
pl. az otp régi netbankja felhasználó név és jelszó volt, az új email cím + jelszó. Miért hiszik, hogy az ember nem változtat a default email címén. (mondjuk mert feltörték, kikerültek jelszavak, vagy egyszerűen csak a "fejlesztés" során kényelmetlenné változott.) Arról nem beszélve, hogy a email címet elég könnyű kitalálni (minimális kutakodással a neten), a account nevet meg nehezebb.
Ezt nem értem pontosan, mert pl. nekem nem a gmail-es email-em volt megadva az Otp-hez, mégis bajban vagyok ezzel a váltással, mert több account-hoz van ugyanaz az email-cím.
Kicsit kellene ismerni az elméleti alapokat. Valójában a "usernév" mező mindössze néhány bit plusz "titkosságot" ad a jelszóhoz. Legyen elég jó a jelszavad és más már nem is kell.
Kettővel több karakter nagyjából, igen. Lehet hogy nem voltam elég egyértelmű: teljesen mindegy hogy adott komplexitású "titkot" egy vagy két mezőbe írsz bele összesen, az a lényeg hogy a szükséges komplexitás meglegyen.
Ezt nem teljesen értem. A titokból az emailcím, mint írtam az esetek többségében nem titok. Szemben a user névvel ami viszont az. Így a 8 elemű user név meg a 8 elemű jelszó képez egy 16 elemű titkot. Míg emailcím esetén csak 8 elemű a titok. Igaz, ha az emailcímhez 16 elemű jelszót generálsz akkor .... egál. Persze a usernévben ritkán vannak spec karakterek.
Bocs elem helyett a pontosságra kényesek, értsenek karaktert.
Nem csak az otp, de ha kutyakaját, piát veszel, emagot, bármilyen netes boltot használsz. Mindenhol ez van. A gmailes kapcsolat, hát....kéne ide egy PR manager, hogy megértsem. :)
Az OTP azért gáz, mert
1 Azért az durvább ha azt törik fel, mint a zooplust.
2. Ott volt egy másik rendszer, és a fejlődés hozta email címet.
Ebben a szívatás inkább az, hogy a legtöbb olyan rendszerben, amely email címmel azonosít, nem módosítható az email cím. Így ha bármi okból a címet meg kell változtatni, sokszor nincs más mód, mint új userként regisztrálni, és a régit törölni. Ahol bármi okból fontos a history, ott így jártál. Nagy élmény volt, amikor a cégnél átszervezés (külön leánycég, stb) átmozgattak minket az anyacég domainjébe.
Az otp-és biztonsági gondom mellett, ez volt az oka a postomnak. A webshopoknál ez volt a gondom, hogy azért kell fenntartanom már -szívem- szerint rég bezárandó emailcímet, mert historyt, meg összegyűjtött kedvezménykulcsot buknék.
Hozzászólások
Az Ügyfélkapu plusz bármilyen TOTP authentikátorral használható.
Maga a TOTP nem egy űrtechnológia, nekem sikerült kb. húsz-harminc sor programkódban implementálnom. A FreeOTP-t nem ismerem, de mivel azt mondják magukról, hogy tudnak TOTP-t, ezért igen erősen merem feltételezni azt, hogy működni fog.
"Maga a TOTP nem egy űrtechnológia"
Olyannyira nem, hogy RFC6238, és az "A" melléklete tartalmaz egy referencia implementációt is. Egyébként a TOTP-s alkalmazásokban nem az időfüggő kód generálása a trükkös/problémás, hanem a generáláshoz használt secret tárolása, illetve védelme - amit az alap totp motyók az OS-re/szoftverkörnyezetre bíznak - azaz semmi sem garantálja, hogy 3. fél nem fér hozzá/nem tudja lemásolni...
Aegis-szel használom, szintén F-Droidról. Működik, és a FreeOTP-nek is kell, ahogy minden IETF RFC 6238 képes alkalmazásnak.
Az Aegis a legjobb totp app androidra.
Működik, csak fikázza a tokent (valószínűleg jogosan :)):
De tovább lehet nyomni és megy.
Wut, az ügyfélkapu gyenge tokent ad? (Még nem álltam neki, hol van még a határidő?)
Google: A FreeOTP akkor mondja ezt, ha 128 bitesnél gyengébb (esetünkben: 80 bites) tokent adsz neki. Kompatibilitás: a régebbi authenticator programok nem tudtak 80 bitesnél nagyobbat.
Az SHA1 sem segít rajta szerintem :)
Egy 80 bites hash-en, amit második faktorhoz használsz?
Az algoritmusnak erős megosztott titkot KELL használnia. A hossza a megosztott titoknak legalább 128 bitesnek KELL lennie. -írja [RFC4226](https://datatracker.ietf.org/doc/html/rfc4226#section-4 ) 2005 decemberében. Ugyan ez 2005-ben készült a dokumentum 160 bites megosztott titok hosszt ajánl.
Miből látod, hogy 80 bites?
QR kódban: otpauth://totp/Kicsi+Peter@ugyfelkapu.gov.hu?secret=ABCDEFGIJKLMNOPQ
Ahol a ABCDEFGIJKLMNOPQ a 16 karakter base32 secret -> 16*5=80 bit
Köszönöm
oauthtool csinál ilyen tokeneket Linuxon parancssorból. A lényege az, hogy egy kiinduló kulcstól és a pontos időtől függ, hogy mit ad, és a szerver ellenőrizni tudja, hogy tudtad a kulcsot, de a token az idő lejárta után nem lesz használható. Csak a privát kulcs, az idő és számolási képesség kell hozzá (Esetleg random source? Nem tudom.), bármire meg lehet írni és van is 1000 féle implementáció.
Az oauthtool-t szerintem valahogy lehet a jelszókezelőkbe is integrálni, talán úgy a legegyszerűbb használni. Valaki biztos csinált belőle online alkalmazást is, bepasztázod a kulcsot és ad egy aktuális tokent. Ezzel adhatunk egy nagy pofont a biztonságnak.
KeePass tudja. 2 factor, minek is az...
> Csak a privát kulcs, az idő és számolási képesség kell hozzá (Esetleg random source? Nem tudom.)
csak a shared secret (sajnos nem asszimetrikus, nincs privat es publikus kulcs kulon) es a timestamp kell neki, semmi mas. szamolni se kell sokat, nem attol lesz biztonsagos, hanem kell DoS vedelem az oldalon, hogy percenkent max 3-5 probalkozast engedjen ugyanazzal az userrel. igy a 6 szamjegyu otp-t kitallani 3 probalkozasa van (ez kb ugyanannyira biztonsagos mint a telefon feloldo pin kodja) utana valtozik a kod es kezdheti elolrol a probalgatast.
> Valaki biztos csinált belőle online alkalmazást is
mindenhol a totp.app websiteot ajanlgatjak hozza, en meg nem probaltam, nem biznek ilyet senki masra
A FreeOTP-vel vigyázz, mert visszaállíthatatlan mentést csinál. A fejlesztőket nem érdekli.
https://forum.f-droid.org/t/freeotp-ignores-a-critical-known-issue-with-backup-and-restore/2723
https://github.com/freeotp/freeotp-android/issues/410
A FreeOTP helyett a FreeOTP+ fork az ajánlott, ez karban van tartva.
https://f-droid.org/packages/org.liberty.android.freeotpplus/
Köszi az infót! Idáig nem kellett ez a funkció, de most át akartam vinni másik eszközre is. Valóban nem ment.
Lecseréltem Aegis-re, amit fentebb is javasoltak.
Sőt, az idő lejáratot se mutatja. Valamint nem találtam meg, hogy hogyan lehet kinyerni belőle az egyes kódok paramétereit - elsősorban a shared secret érdekel persze. (Hasonlóan a Google Autentikátorból sem.) Ellenben az Aegis-szel.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
gauth-ban van export, ami qr kodot mutat, a pontos formatumra mar nem emlekszem, de onnan kibanyaszhato a secret kod.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Én Enpass-t használok, de próbáltam már a totp nevű Firefox kiegészítővel is ...
Ha már lehet kérdezni, akkor én is ezt teszem:
A jelzett ,,Ügyfélkapu+''-t -- ha már van sima Ügyfélkapus azonosítóm -- pontosan milyen alkalmazásokkal is lehet elérni?
Hint: nem csak mobil applikációk, de akár webes megoldások is érdekelnének, az jelzett megoldásokon kívül.
"Share what you know. Learn what you don't."
google://TOTP
https://en.m.wikipedia.org/wiki/Top_of_the_Pops
?
https://en.wikipedia.org/wiki/Time-based_one-time_password
Az F-Droidos sima QR és Barcode Scanner is tud ilyen one time passwordot/tokent generálni. Van egy oldal, ahonnan a céges fizetéscetliket töltöm le. Persze MS Authenticator ajánlott de én ilyesmit nem telepítek a telefonomra. Bescanneltem a QR kódot a fentebb említett app-al és lám, működik, időközönként generál egy újabb számot.
Telefon cserekor elég volt a régi telón megnyitni a QR kódot, az újjal meg bescanneltem és migrálva is volt. Ha ez a lehetőség nincs akkor az oldal által első belépés után generált valamelyik egyedi, egyszer használatos kódot kellett volna használni, amiket már el is felejtettem, hova mentettem el.
Minden hulla a Mount Everesten valamikor egy nagyon motivált ember volt.
Hatalmas biztonsági előrelépés ez (ja nem), de legalább így a könyvelők megint nyertek akik a könyvelőiroda e-mail címével regisztráltatták be az ügyfeleket.
(M)agyarországelőremegynemhátra! Na! Feldereng a jól ismert párbeszéd...
-Itt mindenki hülye?
-Itt? Mindenki!
Ha már itt tartunk, valaki meg tudja mondani, hogy miért lett divat bankoknál és sok más helyen (mondjuk az ügyfélkapun pont nem) a user acc. helyett az email cím?
pl. az otp régi netbankja felhasználó név és jelszó volt, az új email cím + jelszó. Miért hiszik, hogy az ember nem változtat a default email címén. (mondjuk mert feltörték, kikerültek jelszavak, vagy egyszerűen csak a "fejlesztés" során kényelmetlenné változott.) Arról nem beszélve, hogy a email címet elég könnyű kitalálni (minimális kutakodással a neten), a account nevet meg nehezebb.
A gmail a válasz.
Kezdetekben semmit nem kellett megadni, így ők kezdték el az email cím + jelszó alkalmazását a belépéshez.
Az email cím ráadásul egyedi azonosító is kellett hogy legyen, mivel csak az azonosított egy felhasználót.
Elterjedt, így jártunk. A usernév eltűnte gyengítette a rendszereket.
Ezt nem értem pontosan, mert pl. nekem nem a gmail-es email-em volt megadva az Otp-hez, mégis bajban vagyok ezzel a váltással, mert több account-hoz van ugyanaz az email-cím.
Amikor a gmail elindult, nem kellet semmi aznositas.
Csináltál egy e-mail címet, meg egy jelszót. Ennyi volt kötelező.
Ezért csak az email cím volt megadható a belépésnél, és kellett a jelszó, hogy te vagy.
Ez elterjedt, és kikoptak a bejelentkező nevek. Ez gyengítette a rendszerek biztonságát.
Mostmár ez van
Kicsit kellene ismerni az elméleti alapokat. Valójában a "usernév" mező mindössze néhány bit plusz "titkosságot" ad a jelszóhoz. Legyen elég jó a jelszavad és más már nem is kell.
Gábriel Ákos
Azt azért fel kéne ismerni, hogy a + néhány bit az több, mintha nem lenne.
Kettővel több karakter nagyjából, igen. Lehet hogy nem voltam elég egyértelmű: teljesen mindegy hogy adott komplexitású "titkot" egy vagy két mezőbe írsz bele összesen, az a lényeg hogy a szükséges komplexitás meglegyen.
Gábriel Ákos
Ezt nem teljesen értem. A titokból az emailcím, mint írtam az esetek többségében nem titok. Szemben a user névvel ami viszont az. Így a 8 elemű user név meg a 8 elemű jelszó képez egy 16 elemű titkot. Míg emailcím esetén csak 8 elemű a titok. Igaz, ha az emailcímhez 16 elemű jelszót generálsz akkor .... egál. Persze a usernévben ritkán vannak spec karakterek.
Bocs elem helyett a pontosságra kényesek, értsenek karaktert.
(Vessetek meg, de én még mindig nem értem, mi köze az OTP-banknak a gmail-hez.)
Nem csak az otp, de ha kutyakaját, piát veszel, emagot, bármilyen netes boltot használsz. Mindenhol ez van. A gmailes kapcsolat, hát....kéne ide egy PR manager, hogy megértsem. :)
Az OTP azért gáz, mert
1 Azért az durvább ha azt törik fel, mint a zooplust.
2. Ott volt egy másik rendszer, és a fejlődés hozta email címet.
OTP: Pár hónapja írtam nekik egy kérdést erről az key=account => key=emailcím változásról, de még gondolkoznak a válaszon.
Ebben a szívatás inkább az, hogy a legtöbb olyan rendszerben, amely email címmel azonosít, nem módosítható az email cím. Így ha bármi okból a címet meg kell változtatni, sokszor nincs más mód, mint új userként regisztrálni, és a régit törölni. Ahol bármi okból fontos a history, ott így jártál. Nagy élmény volt, amikor a cégnél átszervezés (külön leánycég, stb) átmozgattak minket az anyacég domainjébe.
jobb helyeket ilyenkor a regi emailcim megmarad mint alias.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Az otp-és biztonsági gondom mellett, ez volt az oka a postomnak. A webshopoknál ez volt a gondom, hogy azért kell fenntartanom már -szívem- szerint rég bezárandó emailcímet, mert historyt, meg összegyűjtött kedvezménykulcsot buknék.
Én is keepassxc-vel használom, minden TOTP kompatibilis szoftverrel működnie kell, legfeljebb plusz kör kinyerni a QR kódból a tokent.
[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS
Igen, én használom. FreeOTP+