RSA SecureID helyett?

Linux-security

Keresek megoldast '2 factor authentication'-ra a sajat kis halozatunkba. Korabban (mashol) hasznaltam RSA SecureID-t, az tetszett is, sott azota van belole szoftveres valtozat is, ugyhogy meg extra kutyut venni/cipelni sem kell(ene). Viszont az jutott az eszembe, hogy ha ez szoftverrel megoldhato, akkor valaki nem csinalta-e mar meg ezt nyilt alapon.

Szoval kellene nekem egy alkalmazas ami telefonon (ebbol sajnos minden van nalunk, Android, iPhone, Blackberry) general egy one time passwordot azt meg valahogy hasznalom auth-ra...

Ki mit hasznal ilyesmire? SecureID-vel kapcsolatos tapasztalatok is johetnek.

https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

N.B According to a "disclaimer" on the website, the Current Version of the Android app is now proprietary and it isn't clear whether the source code repository will be getting any more updates.

http://motp.sourceforge.net/

http://packages.debian.org/source/sid/dynalogin
http://packages.debian.org/unstable/libs/libpam-opie

https://f-droid.org/repository/browse/?fdfilter=otp

ps: s/key, md5, sima yubi-t, és hotp-t szerintem nem akarsz (mitm replay!). Sima yubihoz van kliens (úgyis USB-n lóg), ami ad egy időbélyeget amit a yubi lepecsétel és lesz belőle TOTP.

http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf

A "sima yubi"-n és "(mitm replay)"-en nem tudom egészen pontosan mit értesz, de YubiKey-jel természetesen nem működik a replay attack, hiszen a már felhasznált kódot érvényteleníti a szerver (kipróbáltam). Ha az a gond, hogy a Yubico a shared secret birtokában képes önmaga is valid jelszavakat generálni (vagy még ez sem kell, mert - elvileg - pl. az cccccfffffnsansansansansansa karaktersorozatra mondhatja a Yubico szervere mindig, hogy valid) akkor arra a megoldás a saját hittelesítő szerver felállítása (GPL-es, forráskóddal együtt adja a Yubico) + saját shared secret rakása a kulcsokba, amire van API és támogatott módszer. Ha az internetes szolgáltatások, mint pl. a LastPass igénybevétele nem szempont, hanem csak belső hálóra kell, akkor én így csinálnám.

"Sima yubihoz van kliens (úgyis USB-n lóg), ami ad egy időbélyeget amit a yubi lepecsétel és lesz belőle TOTP."

Emlékeim szerint ez úgy működik, hogy a yubikey második rekeszében tárolhatsz OTP-t tokent és sima passwordöt is. A Yubico gyakorlatilag semmi mást nem csinált, mint a Google Autneticator-t levédte egy sima passworddel (ami persze random meg hosszú meg minden), és ezt eltárolja a kulcson második jelszóként. Semmivel sem biztonságosabb, mint a sima yubikey használata. Pecsételni biztosan nem pecsétel a YubiKey, mert nincs benne ehhez szükséges aszimetrikus kulcsú kriptó.

A sima yubi pont a hotp és a totp között van: számlálót növel és van benne egy oszcillátor is. Viszont a 8Mhz-es oszcillátor nem valós időt ad, akár át is fordulhat. A szerverek egy ablakot is elviselnek, pl. véletlen megnyomás, óramászás stb. A sok részlet most mindegy, de innen kezdődik a lejtmenet. Ugyanazt kétszer persze nem veszi be, de ha lenyúlsz egyet (pl. adsz egy login errort) amit később bemutatsz, akkor azt bizonyos körülmények között el lehet fogadtatni.

RFC-s totp-ként használva az időbélyeg pecsétet OCRA-s HMAC biztosítja, (adott) kriptográfiai erősségű hash függvénnyel. Ahhoz nem kell semmilyen aszimmetrikus kulcs. Egyéként a GA közönséges totp.

Egyébként az újabb yubik már akár kulcsokat is használhatnának, ha valaki bízik benne (lásd mifare előző köre, a linkelt pdf és tajvani személyi RNG hitelesítése)

"A sima yubi pont a hotp és a totp között van: számlálót növel és van benne egy oszcillátor is."

Az oszcillátor csak a crypto előtti állapot 9-14. byte-ok generálásához kell, ahol egy bedugás utáni timestamp + egy bedugás utáni session number + 2 byte pseudo random szám szerepel. Ezek tudomásom szerint csak azért vannak, hogy adjanak némi entrópiát a sorozatszám + számlálóhoz. Ellenőrzésre viszont csak a számláló + sorozatszám kerül.

"Ugyanazt kétszer persze nem veszi be, de ha lenyúlsz egyet (pl. adsz egy login errort) amit később bemutatsz, akkor azt bizonyos körülmények között el lehet fogadtatni."

Ezt ugye minden OTP-s rendszerre igaz, ha a GA kódját nyúlod le és adsz egy login errort, azzal is be tudsz jelentkezni 1-2 percig (beállítástól függően) illetve addig, amíg a user egy helyes bejelentkezéssel magasabb szekvenciával nem érvényteleníti az előzőt. Ez a Yubikeynél is igaz, egy helyes bejelentkezés után már nem lesz elfogadva az alacsonyabb szekvencia. Különbség csak ott van, hogy az egyik esetben a sebezhetőség 1-2 percig áll fenn maximum, a másikban meg amíg be nem lépsz megint - gyakorlati szempontból mindegy.

Szerk:
Átgondolva még egyszer, a számláló 2 byte-os a Yubikey-ben, azaz mondjuk napi átlag 10 használatot feltételezve ~20 év alatt fordul át. Na akkor be tudod mutatni újra az elfogott sorozatot, csak győzd kivárni ;)

"2 byte pseudo random szám" ...háát

"Különbség csak ott van, hogy az egyik esetben a sebezhetőség 1-2 percig áll fenn maximum, a másikban meg amíg be nem lépsz megint - gyakorlati szempontból mindegy."

To prevent such a race-for-the-last-key attack, any login attempt that is taking place concurrently with another attempt will require three one-time passwords to be entered...
http://www.cl.cam.ac.uk/~mgk25/otpw.html

ui: Nem azt mondom, hogy rossz a yubi, csak érdemes ismerni a hátrányait (arm, usb stack stb?). A többi termék sem garantáltan jobb...
http://smartfacts.cr.yp.to/cert.html
https://en.wikipedia.org/wiki/Mifare#Security_of_MIFARE_Classic.2C_MIFA…

ui: ne csak 1 kulcsban/tokenben/kártyában gondolkodj

"2 byte pseudo random szám" ...háát
Az a "háát" mire vonatkozik? A szabályozatlan oszcillátor által előállított pseudo random számokra, amik entrópia növelés miatt kerülnek a 16 byte-os titkosítatlan csomagba? Jobb lenne statikus adatokkal kitölteni azt a 8 byte-ot, ami marad a 16 byte-os blokkból (ugye az AES128-nak ekkora a blokkmérete)?

"To prevent such a race-for-the-last-key attack..." Annyit ír le, hogy abban az esetben, ha egyszerre több bejelentkezési próbálkozás is jön (gyakorlatilag replay attack van épp) akkor mindkét próbálkozótónak küld még 3 challenge-et (gondolom különbözőket, de erre nem tér ki), hogy eldöntse, kinél van az OTP generátor valójában. Nincs túl nagy jelentősége a dolognak, mert az a legritkább, hogy ha valaki hozzáfér a kommunikációs csatornához, akkor nem tudja módosítani azt (ez pedig csak ez ellen az eset ellen véd, hiszen mindkét bejelentkezési kérés eljutott a fogadóig - a valóságban sokkal gyakoribb, hogy az eredeti feladó adatfolyama eltérítésre kerül), másrészt ez módszer bármilyen OTP rendszeren alkalmazható: nyomd meg 5x a yubikey-ed egy text editorban, vagy írd fel a GA következő 5 számát. Az egyik próbálkozó küldje el ebből mondjuk a másodikat meg az ötödiket, a másik meg a negyediket meg az ötödiket.

"ui: Nem azt mondom, hogy rossz a yubi, csak érdemes ismerni a hátrányait (arm, usb stack stb?). A többi termék sem garantáltan jobb..."
Úgy érzem nem volt még yubikey a kezedben. A yubikeyt billentyűzetként ismeri fel az oprendszer, szóval amelyik arm-es cuccra lehet billentyűzetet kötni (akár azért, mert van USB host adaptere, akár azért, mert OTG kábelen keresztül lehet USB-s billentyűzetet rákötni) azon működni fog. Nem kell semmit telepíteni és nincs driver probléma, egészen addig, amíg valamilyen latin billentyűzet beállítás van a gépen. Nekem androidos telefon + OTG kábellel működik. Usb stack szempontjából pont annyira biztonságos, mint bármelyik olyan token, aminek az eredményét a végén a billentyűzeten pötyögöd be, hiszen az usb csatitól "felfele" kutya közönséges 101 gombos billentyűzetnek látszik.

AES random inicializálást illetően belefuthatunk a Bullrun témába[1], hogy pontosan hány bit az annyi valójában.

"Különbség csak ott van, hogy az egyik esetben a sebezhetőség 1-2 percig áll fenn maximum, a másikban meg amíg be nem lépsz megint - gyakorlati szempontból mindegy." [..] " Annyit ír le, hogy abban az esetben, ha egyszerre több bejelentkezési próbálkozás is jön (gyakorlatilag replay attack van épp)"

Innen a preferenciám az "interaktív" (gyakorlatilag 1 percen belüli) visszajelzésre az egyidejű belépésnek a totp esetében.

Bocsánat, az ARM és USB stack yubi vektor[2] felvetése a YubiHSM-re vonatkozik, nem a standard kulcs Cypress(???) USB mikrokontrollerre vagy utódjára (netán armv3? nemtom, azt sem, hogy az min lógna). De a NEO kulcs tamperproofabb Mifare Classicja sem kelt bennem nagyobb bizalmat (az NXP Crypto-1 miatt láttam már tömeges kártyacserét).

[1] https://www.schneier.com/blog/archives/2013/09/surreptitiously.html#c17…

[2] maga Simon Josefsson is elismerte, hogy nem volt része az auditnak

ps: http://xkcd.com/386/
ps/2: http://jjshortcut.wordpress.com/2011/09/26/webkey-hack/

"Különbség csak ott van, hogy az egyik esetben a sebezhetőség 1-2 percig áll fenn maximum, a másikban meg amíg be nem lépsz megint - gyakorlati szempontból mindegy." [..] " Annyit ír le, hogy abban az esetben, ha egyszerre több bejelentkezési próbálkozás is jön (gyakorlatilag replay attack van épp)"

Innen a preferenciám az "interaktív" (gyakorlatilag 1 percen belüli) visszajelzésre az egyidejű belépésnek a totp setében.

Két dolgot keversz össze.

(1) Ha a támadónak lehetősége van eltéríteni a user streamet, és ő terminálja azt (például úgy, hogy feldob egy hibás bejelentkezés ablakot), akkor a támadó mindenképpen be tud lépni - totp esetén néhány percig vagy a user következő bejelentkezéséig, yubikey esetén a user következő bejelentkezésééig. Gyakorlati szempontból nincs különbség, mert 1x mindenképpen bejut, másodszor már nem tud, hacsak megint el nem tudja téríteni a streamet. Erre vonatkozott az első idézet. És nem, egyik eszközzel sem lesz visszajelzésed arról, hogy valaki a nevedben csinált valamit, mert a következő bejelentkezésed egy új tokennel történik, mert az előzőt már elhasználtad, nem fog replay attacknak látszani a dolog.

(2) Ha a támadó csak "hallgatózni" tud és a user streamje és a támadó replay attackja is célba ér, akkor az ellen bármilyen OTP rendszer védetté tehető (nem azt jelenti, hogy védett is): a bejelentkezést késlelteted pár másodperccel, és ha ebben az időablakban jön egy második próbálkozás is ugyan azokkal a paraméterekkel (invalid tokennel, hiszen a tokent már elhasználta az első próbálkozó), akkor jéé, replay attack van. Döntsük el kinél van a generátor, kérjünk meg mindkét próbálkozót, hogy küldjön valami random (egymástól különböző) másik tokent is. Akinél a generátor van, az nyilván képes erre, aki meg csak hallgatózik, az nem tudja elküldeni a tőle kért új tokent. Erre vonatkozik a 2. idézet. Belátható, hogy a replay attackot a használt eszköztől függetlenül azonnal érzékelni lehet, és erre az egészre csak azért van szükség, mert előfordulhat, hogy a replay attack ér előbb célba mint a user stream, és akkor nem jó, ha a támadót engedjük be. Ha nem akarod túlbonyolítani a dolgot, akkor helyes megoldás ilyenkor az is, hogy ahelyett, hogy új tokent kérsz, egyáltalán nem engeded be az egyik streamet sem, hanem kiírod, hogy hívja fel a biztonsági osztályt és mondja be, hogy 504-es kód. Ennek az egésznek azért marginális a jelentősége, mert ha a (2)-es pontra képes vagy, akkor:
- megtörted azt az SSL/SSH csatornát, amiben a token utazik
- a user gépe általad ellenőrzött hálózati csomóponton keresztül forgalmaz
akkor már miért nem az (1)-es módszert használod?

szerk:
Ennek: https://www.schneier.com/blog/archives/2013/09/surreptitiously.html#c17… és ennek: http://jjshortcut.wordpress.com/2011/09/26/webkey-hack/ a linknek érintőlegesen sincs köze a témához. De az xkcd-s jó :)

A YubiHSM pedig HSM modul, szerverbe való, certificate biztonságos tárolására, semmi köze az otp-hez.

An One Time Password (rfc2289) implementation for the Android: a fork of http://android.f00d.nl/opiekey. It is used for logging into a (OTP enabled) system from an untrusted terminal by generating a password that is only valid for one login. Supports SHA1 and MD5.

https://f-droid.org/repository/browse/?fdfilter=otp&fdid=de.ub0r.androi…

A klasszikus yubikey egy OTP azonosításra képes (a NEO-ban van már smart card is). Egészen pontosan a következőképpen működik:
- bedugod az USB portba, a gép felismeri, mint USB-s billentyűzetet
- fókuszálod a megfelelő input mezőt
- megnyomod a rajta levő gombot, ami beírja a "következő sorszámot"
- A szerver ezt feldolgozza: elküldi az autentikációs szervernek, aki megnézi, hogy az adott sorszám valid-e (a sorszám eleje a yubikey saját sorszáma, csak a vége változik)
- Az authentikációs szerver visszaküld egy igen/nem választ

Szóval a válasz: ez egy autentikációs eszköz, minden olyan dologhoz illesztheted, ami támogatja ezt a fajta autentikációt.
- A Facebookról volt szó, hogy használni fogja a yubikeyt, de azt hiszem csak a facebook alklalmazottak + a fejlesztők használják, a "nép"-nek nincs engedélyezve
- A google nem támogatja*
- SSH-ban használhatod PAM modullal
- PAM modul van hozzá
- (szerk.) Radius integráció is van

* Van olyan alkalmazás, ami a Google-ös OATH TOTP -s response-t generálja úgy, hogy az alkalmazás előtte yubikeyjel autentikál téged, hogy jogosult vagy-e látni ezt. Ez egy kicsit a körbeprogramozása a dolgoknak, ettől még a Google nem támogatja.

Az, hogy egy adott yubikeyt hány alkalmazásban használhatsz, nagyjából az dönti el, hogy privát autentikációs szervert üzemeltetsz, vagy a Yubico-ét használod. A szervernek ugyanis szinkronban kell lennie a yubikeyekkel, azaz nem akármilyen szekvenciát fogad el, hanem csak a következőt - pontosabban a következő N darab (talán 10?) valamelyikét. Ha felváltva akarnád két különböző privát, vagy egy privát és a Yubico publikus szerverét használni, akkor nagyon könnyen és gyorsan kikerül a szinkronból a yubikey.

Ugyan arra a privát autentikációs szerverre vagy a Yubico publikus autentikációs szerverére viszont tetszőleges
számú szolgáltatást fel lehet fűzni. Tehát ha például van egy yubikeyed, és úgy gondolod, hogy a Yubico maga nem jelent biztonsági kockázatot**, akkor azzal azonosíthatod magad SSH felé, LastPass-ban, Drupal-ban a yubikey modullal + bármi másban is, ami a Yubico autentikációs szervere felé küldi tovább az adataidat és onnan vár egy igen/nem választ.

** Könnyen elképzelhető olyan, hogy a Yubico publikus szerver - akár ideiglenesen - bizonyos szekvenciákat mindenképpen validnak fogad el, így egy harmadik fél (NSA meg a többi 3 betűs) ki tudja küszöbölni ezt az azonosítási faktort. Nincs olyan dokumentált eset, hogy ezt megtették volna, vagy hogy léteznének ilyen mesterkulcsok.

( traktor | 2013. 09. 13., p – 16:54 )

Ezek szerint RSA SecureID-t senki nem hasznal? Arra szamitottam, hogy ozonleni fognak a hozzaszolasok, hogy hasznaljak inkabb azt, ne keressek helyette mast, mert az annyira profi...

Használunk, a lentebb linkelt kompromittálódás után cserélték a tokeneket.

Szvsz semmivel nem jobb, mint a TOTP. Talán annyi , hogy egy csomó kereskedelmi termék támogatja alapból, vagy van hozzá integráció, szóval pl Cisco VPN klienssel, vagy Windows login esetében működni fog a Next Token mód, vagy a New PIN mód.

Igen, a SecureID-ban az volt nekem szimpatikus, hogy eleg regi es elterjedt ahhoz, hogy eleg sokminden tamogassa (a fentebb irt reszletek szamomra ujak, eddig csak gondoltam, hogy igy kell lennie). Persze jo esellyel erre nem lesz szuksegem, mert a _mostani_ problemakat sok mas eszkozzel is meg tudom oldani, csak ha egyszer megis bejon egy doboz a halozatba, amihez 2factor... kell, akkor az jo esellyel RSA SecureID-t fog ismerni... De ez csak egy szempont, es nem is igazan fontos.

Szia!

Azért a SecurID támogatása nem magától értetődő a különféle eszközökben/megoldásokban, a szabványos Radius-t sokkal több minden támogatja (szerintem ami a SecuID-t támogatja, az támogatja a Radius-t is, de ez fordítva nem igaz).
Egy csomó 2-faktoros authentikációs megoldás a Radius-t használja, ha egy ilyet választasz, akkor lehet, hogy több helyen tudod felhasználni.

Üdv.

Tapasztalatom szerint már több mint 5 éve nyugaton minden internetes számlához alapból felár nélkül adnak egy OCRA jellegű smartcard olvasót: olyan mint egy olcsó kínai számológép (lehet, hogy csak azért, mert az is).

Régen volt olyan bank, amelyik külön smartcardot adott hozzá (nem bankkártyaként -- pl. UBS), de már egy ideje csak olyanom volt, amelyik helyből magát a bankkártyát használja, ugyanazzal a PIN-el stb.

Nem is értem Magyarországon mi lesz a bankok nyereségéből -- valószínű a kártyacsalásos veszteségeket is az ügyfelekre hárítják.

Azért ezt a "nyugaton"-t szűkítsük kicsit. A legtöbb bank ad valamilyen tokent, de biztos vagyok benne, hogy a smartcard olvasó annyira azért nem elterjedt, mert sokkal drágább, mint pl. egy mobil app. A magyar bankok nyereségét meg az elmúlt három évben a kormány vitte el, előtte pár évig meg az anyabankot kellett jellemzően megmenteni a gazdasági válság miatt bedőlt hitelek miatt (magyar magyar bank meg nem sok van, nagyjából 8 a 40-ből, igazán nagy meg csak 1), de ez már jórészt politika, amit személy szerint nem preferálok egy szakmai portálon.

A kártyacsalásokat mindig az ügyfél fizeti ki, ha más nem úgy, hogy a kártya díja tartalmaz egy erre vonatkozó biztosítási összeget. Bankról beszélünk, nem jótékonysági intézményről.

Mennyire elterjedt az SMS-ben küldött egyszer használatos (adott tranzakcióra érvényes) kód használata? Milyen költsége van a tömeges SMS szolgáltatásoknak? Mekkora a fejlesztési/migrációs költsége (illetve a párhuzamos üzem miatti költségnövekedés) abban az esetben, ha nem használnak ilyet? Ezeket a kérdéseket is érdemes megvizsgálni akkor, amikor a token/kártyaolvasó kontra más megoldásokat vesszük szemügyre.
Az persze más kérdés, hogy nálunk az adott hívószámhoz rendelt SIM (oda megy az sms), náluk pedig egy, a bank által adott célhardver (illetve maga a chip-es bankkártya) birtoklása a számlához való hozzáférésnek.

Az elterjedés egy álkérdés: alapból adják, nélküle be sem lehet lépni. Ez nem igaz az SMS-re, főleg nem az elterjedtségére.

Nem tudom, hogy mire jó a bankkártya (pontosabban smartcard), ha nélküle is lehet bankozni (mármint nem az ügyfélablaknál). És az sem mindegy, hogy mekkora veszteséget hárítanak tovább...

Végül egy gondolatkísérletet csak megér: a menedzsment bónuszát leosztani az internetes ügyfelek számával meg egy számológép árával. Időarányosan.

A jobb netbankokba sms-en kapott egyszer használatos kód nélkül be sem tudsz lépni, ami nem ilyen, az erősen "le van maradva", hogy finoman fogalmazzak - a "birtoklás"-t mint feltételt ugyanis nem fedi le a bejelentkezési megoldása. A CNP (Card Not Present) tranzakciók mind kártya/pin kód nélkül zajlanak, és köszönik jól vannak, a neten nem is tudsz máshogy vásárolni :-P
Nem a management bónuszáról meg a bank által az üf.-re lőcsölt kárösszegről van szó, hanem arról, hogy milyen költséget jelentene az egyik módszerről a másikra történő migrálás, mennyi munka, eszköz, a párhuzamos működés miatt extra (azaz a teljes átállás után kidobandó) fejlesztés stb. Ha ez sok (az, nem is kicsit), akkor nem fogja egy bank meglépni. Ha viszont a kezdetektől -mert pl. adott területen/országban a mobilkommunikáció, illetve az SMS használata a netbank kialakításakor még nem volt jelentős mértékben elterjedve, akkor érthető, hogy nem arra építettek - Magyarszág későn kezdett "kártyázni" nagy tételben, így nem alakultak ki azok a ma már elavult/drága módszerek, amik más, a kártyás bankolást (jóval) hamarabb kezdő országokban igen.