Illetéktelenek fértek hozzá a Mozilla hibakövető rendszerének privát részéhez; érzékeny sérülékenységi adatok szivárogtak ki

 ( trey | 2015. szeptember 5., szombat - 20:39 )

A Mozilla tegnap bejelentette, hogy illetéktelen(ek) fért(ek) hozzá Bugzilla hibakövető rendszere korlátozott hozzáféréssel rendelkező részéhez. Noha a hibakövető rendszer nagy része publikus, bizonyos, biztonsággal kapcsolatos, érzékeny információkat tartalmazó részéhez csak megfelelő jogosultsággal rendelkező felhasználók férhetnek hozzá. Ezen a területen tartotta a Mozilla a nem publikus, éppen javított, vagy javításra váró Firefox sebezhetőségek leírásait, részleteit. Ezekhez az információkhoz fért hozzá illetéktelen személy (vagy személyek).

A Mozilla szerint az illetéktelen hozzáférés egy megfelelő privilégiumokkal rendelkező felhasználó jelszavának kompromittálódása során vált lehetségessé. A Mozilla szerint a felhasználó egy másik oldalon is ugyanazt a jelszót használta amelyet a Bugzillában és az a másik oldal betörés/adatlopás áldozata lett. Így kerülhetett a jelszó illetéktelen kezekbe, amellyel aztán Firefoxszal és más Mozilla termékekkel kapcsolatos érzékeny információkat tudott a támadó letölteni a Bugzillából.

A Mozilla szerint a támadó 185 nem publikus hiba leírásához fért hozzá. Ezek közül 10 nem volt még akkor javítva, a többire viszont már volt javítás a Firefox akkori legfrissebb verzióiban. A támadó legelőször 2014 szeptemberében fért hozzá az adatokhoz, de vannak arra utaló jelek, hogy már 2013 szeptemberében lehetett hozzáférése.

A behatolás legsúlyosabb következménye a felhasználókra nézve az augusztus elején bejelentett szabadon keringő exploit felbukkanása lehetett.

Részletek a Mozilla bejelentésében és az általa kiadott FAQ-ban.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Na, akkor most ki a hanyag? Az oké, hogy az illetőnek kompromitálódott a jelszava (bár azért neki se kellett volna ugyanazt a jelszót kétszer használnia), de hogy a támadó 1 vagy esetleg 2 évig gond nélkül hozzáfért az adatokhoz, azért nem a jó biztonságra utal. Hol volt pl. a rendszeres jelszó csere? "Vicces" amikor pont azok nem követik ezeket az irányelveket, akiknek a biztonság a munkájuk.

Ismét bebizonyítódott, hogy a szűk keresztmetszet mindig az ember maga.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

> a rendszeres jelszó csere
-1, az egyik lehető, legrosszabb megoldás szerintem. ebből lesz tipikusan az, hogy felírom, mellé-mentem, etc.

akkor már inkább 2-factor-auth, vagy új-gép esetén 2-factor-auth, vagy valami más megoldás.
--
blogom

meg a cicamica1, cicamica2, cicamicaN jelszavak :D

--
NetBSD - Simplicity is prerequisite for reliability

honnan tudod a jelszavam???

erdekes. az van itt feljebb a FAQ-ban, hogy 53 nem publikalt hiba, ebbol 10 nem volt javitva. ez szerintem azt jelenti, hogy 43 nem publikus de javitott hibahoz fertek hozza. 43 javitott de nem publikalt hiba? miert nem publikalt? hogy is van ez a nyilt forras elharcosanal? nem csak az ms-nel javitanak csendben hibakat? ejnye, no.

Gyanítom, hogy a megoldás a feladványra az, hogy nem mindenki használja a legfrissebb firefoxot. És az ilyen embereket sem akarták kitenni a támadásoknak.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

"43 javitott de nem publikalt hiba?"

Az egy dolog... na de mit írnak a commit logba a hibák javításánál? Vagy az sem publikus?

Olyan leirast ami alapjan nem tunik olyan veszelyesnek. :)

A WebKit-nel (volt?) szokas azt csinalni, hogy keresel olyan commitot ami olyan hibajegyre mutat amit nem tudsz megnyitni. Utana mar csak at kell nezned a kodot hatha talalsz benne valami kihasznalhato sebezhetoseget. Ez asztali gepek ellen nem a leghasznosabb dolog, mert a modern bongeszok gyakran frissulnek. Azonban a WebKit nagyon elterjedt beagyazott eszkozokben amiken gyakran lehetoseg sincs frissiteni.

Gyanítom, hogy a kiadásig nem publikált. Bevett szokás az iparban, hogy embargó alá helyeznek egy sebezhetőséget, amíg azt ki nem javítják, illetve a javítást tartalmazó kiadást ki nem adták. Utána az infót elérhetővé teszik.

--
trey @ gépház

Le a jelszavakkal, eljárt felettük az idő rég.
De minimum legyen MFA ilyen fontos helyeken!
Felhasználónként, havonta kb. 1.20€ a költsége.
Össze sem mérhető a most keletkezett károkkal.

Üdv.
Marci

+1

> másik oldalon is ugyanazt a jelszót használta
> 2015

:)

Az vesse rá az első követ, akinek minden jelszava különbözik, nem használja fel újra és nem is kikövetkeztethető valahogy és biztonságosan tárolja (lehetőleg megjegyzi) őket.

Üdv,
Marci

Legalább 10 különböző jelszót használok és változtatom is őket.Továbbá csak a fejemben vannak.
Épp a minap este félálmomban váltottam egy jelszót,másnap eszembejutott belépésnél,hogy előző este változtattam.De mire?Aztán beugrott.

Kővel nem dobálózok.

Gratulálok, jó a memóriád. Nekem kb. 130 helyre van jelszavam. Le velük, eljárt felettük az idő.

Üdv,
Marci

Nagyjából pedig stimmel, minden jelszavam LastPass-ban van, kivéve a privát email címemé, a corp account jelszava és a netbanké. :)

Az, hogy megjegyzi, nem biztonságos. Egy-két ujjtörés után (brute force, ehe), erősen gyengül a védelem.

Ha jól értem, a jelszó nem a fizikai réteg védelmének eszköze és nem is helyettesíti azt...
Amit írtál, az ellen nem véd semmi.

Üdv,
Marci

Hát ezaz :D

Na de - hál'Istennek - ez nincs is a gyakori támadási felületek közt!

Üdv,
Marci

minden fontos jelszavam kulonbozik

--
bohocmasni

Én is kérek követ, állszakáll nem kell, van valódi :)

Hihetetlen ha valaki így használja a jelszavait?

☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

Ajjaj ezt benéztem rendesen! :)
Bár azt gondolom, hogy az itt átírt mondat eredetijének szerzője sem arra gondolt, hogy Mária kezdje... :)

Üdv,
Marci

"De minimum legyen MFA ilyen fontos helyeken! Felhasználónként, havonta kb. 1.20€ a költsége."

Attól, hogy az Azure-ban [$1.4|1.2€]/user/month az MFA, attól még van ingyen is MFA, nem is egy... :/

...és egyszer élném meg, hogy nem MS technológiát ajánlasz... :)

Már meg is élted, ideje új vágyak után nézni: http://hup.hu/node/142533#comment-1903598 :)
Egyébként segíts inkább: milyen ingyenes MFA-kra gondolsz - tényleg érdekel, nem ismerem ezeket.
Amúgy csak Te beszéltél az Azure-ról: rossz, aki rosszra gondol! :)

Üdv,
Marci

"Már meg is élted, ideje új vágyak után nézni: http://hup.hu/node/142533#comment-1903598 :)"

Ahja, szóval a Microsoft is forgalmaz paraffint, de inkább IKEA gyertyából javasoltad beszerezni? Hm...

"Amúgy csak Te beszéltél az Azure-ról: rossz, aki rosszra gondol! :)"

Szabad a gazda: mire másra gondoltál ami 1.2€/user/month?

"Egyébként segíts inkább: milyen ingyenes MFA-kra gondolsz - tényleg érdekel, nem ismerem ezeket."

Amiket használtam vagy használok: Google Authenticator, OpenOTP, mOTP és LinOTP; amiket néztem pár éve és ingyenesnek tűntek, de nem próbáltam: VeriSign Identity Protection, RSA SecureID Software Token és MobilePASS.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Ahja, szóval a Microsoft is forgalmaz paraffint, de inkább IKEA gyertyából javasoltad beszerezni? Hm..."

Tetszenek a kifogásaid! Erre vajon mit mondasz?
http://hup.hu/node/142530#comment-1903556

Üdv,
Marci

"Tetszenek a kifogásaid!"

Nem kifogások, csak próbálom a szövegkörnyezetben lévő értelméhez kötni a kérdésem, tehát nyilván nem azok az esetek érdekelnek, amikor paraffint keres valaki vagy olyan problémára egy megoldást, amire nincs Microsoft válasz.

Annak az oka érdekel, hogy ha valamire van Microsoft termék és/vagy szolgáltatás, akkor miért van vakfoltod az összes többi termékre és/vagy szolgáltatásra, ami a piacon amúgy elérhető és adott esetben jobb.

"Erre vajon mit mondasz?"

Szóval milyen Microsoft terméket javasolnál arra a problémára, ha PDF-ből szeretnék oldalanként egy PNG képet készíteni? :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Fent nem ezt írtad még: "...és egyszer élném meg, hogy nem MS technológiát ajánlasz... :)"

Persze, elhiszem, hogy közben másra gondoltál. Azért ne kifogásold, ha arra válaszolok, amit írtál.

Ráadásul ott figyelt egy smiley. Poén volt a paraffin...

Üdv,
Marci

"Persze, elhiszem, hogy közben másra gondoltál."

Egyszerűen szövegkörnyezetben szoktam értelmezni a mondatokat, különben sokkal többet kellene gépelni.

"Azért ne kifogásold, ha arra válaszolok, amit írtál."

Komolyan erre a szintre kellene lemenni? Ennél ezért értelmesebbnek gondoltalak... :/

"Ráadásul ott figyelt egy smiley."

Nézd csak vissza, hogy honnan indultunk és milyen jel volt a mondat végén. Hm?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Szóval milyen Microsoft terméket javasolnál arra a problémára, ha PDF-ből szeretnék oldalanként egy PNG képet készíteni? :)"

A kérdés az volt, hogy PDF-et hogyan lehetne képpé konvertálva oldalanként LibreOffice Writer-be tenni.
Én így csinálnám Windows-on:
-Megnyitom a .PDF-et
-OneNote-ba nyomtatom
-az adott OneNote lapról a képeket kopipésztelem a LibreOffice Writerbe.

Üdv,
Marci

Ezzel a megoldással hol állnak elő a sorszámozott PNG képek? :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Ezzel a megoldással hol állnak elő a sorszámozott PNG képek? :)"

Jobb kifogást kérek! :)

Ez volt a feladat:

"Üdv! Nemrég olvastam szerintem itt a hup-on, hogy valamilyen szoftverrel lehet egy PDF dokumentumot (oldalait) image (kép) formátumba konvertálni, amit Libreoffice-ba be tudom importálni majd. Tökéletesen működött is a dolog korábban, mert használtam is.
Most megint épp erre lenne szükségem. De nem találom, hogy mi volt az a grafikus app. :)

Szóval, van ötlete valakinek, mivel lehet ezt megoldani? Pl. adott egy 10 oldalas PDF, aminek az oldalait valamilyen image formátumba lehet konvertál. Ezeket a képeket szépen a LO doksiba pedig beilleszteném egyenként."

Hang nem volt sorszámozott képekről, az általam itt javasolt Microsoft alapú megoldás pedig a fenti specifikációnak megfelel. Én mégis opensource parancssorit javasoltam abban a topikban!

Szóval: jobb kifogást kérek! Vagy ismerd el, hogy új vágyak után kell nézz, hisz íme egy eset, ahol nem Microsoft megoldást javasoltam! :)

Üdv,
Marci

Ok, igazad van.

Köszönöm, respekt!

Üdv,
Marci

"miért van vakfoltod az összes többi termékre és/vagy szolgáltatásra, ami a piacon amúgy elérhető és adott esetben jobb."

Talán azért az összesre nincs vakfoltom, legalábbis merem remélni.
Nem ismerem az összes többi terméket és szolgáltatást. Sőt, jó pár Microsoft terméket és szolgáltatást sem ismerek! (Kevés embert ismerek amúgy, aki minden Microsofttal versengő terméket és szolgáltatást ismer.) Mindig örülök, hogy ha mások hozzászólásából bővíthetem picit a látóteremet.
Most például köszönöm, hogy MFA soron adtál néhány példát, ugyanis rájuk néztem és megerősítettél abban a véleményemben, hogy versenyképes az Azure MFA szolgáltatás.

Üdv,
Marci

Nem, nem az. Például 99,9%-os rendelkezésre állást vállal rá a Microsoft. Ez azt jelenti, hogy évente egy napra akár be is zárhatsz emiatt.

Fogalmam sincs, miért kéne bezárni egy MFA kiesés miatt!

A versenyképesség nem azt jelenti, hogy egy szolgáltatás mindig, minden célra megfelel.
Ahol ez a szolgáltatási szint kevés, ott más megoldást vagy hibrid megoldást kell alkalmazni.

A versenyképesség csak összehasonlításban értelmes fogalom.
Tudsz mondani magasabb SLA-jú, összemérhető képességű szolgáltatást hasonló áron?

Üdv,
Marci

Azért kell bezárni, mert a felhasználóid nem tudnak bejelentkezni vagy feloldani a lockolt számítógépüket.

Ha már van valakinek saját megoldása, amit hibrid megoldásban tud használni, akkor miért is használja még pluszban a Microsoftét?

A versenyképesség, mint fogalom pedig éppen nem összehasonlításban értelmes. Arra utal ugyanis, hogy egy adott termék adott áron kell-e a piacnak vagy sem. Teljesen mindegy, hogy mennyi az ára, ha alapvető hiányosságai vannak - például kisebb a rendelkezésre állása, mint ami az autentikációt igénybe vevő rendszereknél elvárt.

"Azért kell bezárni, mert a felhasználóid nem tudnak bejelentkezni vagy feloldani a lockolt számítógépüket."

Ha valaki így alakítja ki a rendszert, akkor az úgy rossz!
A Microsoftnál kötelező az MFA. Ha nem működne, bizonyos dolgokat nem tudnék okostelefonon vagy netkávézóban elérni. A céges gépen minden menne, bárhol legyek is.

Hibrid alatt a menedzselt gépeken virtual Smart Card alapú második faktort értek, például.

Az egyszemélyes verseny nekem továbbra is képzavar.
Én inkább a megfelelőség fogalmát használnám itt.
Az meg csak egy adott követelmény-lista birtokában értelmezhető.
Részben továbbra is egyetértve Veled, tudok olyan valós követelményeket, aminek megfelel az Azure MFA, és olyat is, amire nem.

Egyébként tudsz mondani magasabb SLA-jú, összemérhető képességű szolgáltatást hasonló áron?

Üdv,
Marci

"Ha valaki így alakítja ki a rendszert, akkor az úgy rossz!

A Microsoftnál kötelező az MFA."

??? Ez rendszerkritika volt?

Egyebkent en sem ertem a dolgot. Miert lenne rossz, ha en ugy alakitom ki a rendszert, hogy a zarolt szamitogep csak MFA-val legyen feloldhato? Kerlek, ne szedjuk mar elo a "You holding it wrong" tipusu ervelest.
--
Blog | @hron84
Üzemeltető macik

"??? Ez rendszerkritika volt?"

Nem, pongyolán fogalmaztam, ezért félreérhető voltam. MFA alatt itt az Azure MFA-ra gondoltam és (Virtual) Smart Card-dal hibrid megoldásról beszéltem.

"Egyebkent en sem ertem a dolgot."

Ha az e hozzászólásbeli értelmezést nézzük, akkor gondolom világos.
Nem alakítanék ki olyan rendszert, amiben a bejelentkeztetés/zárolás feloldása minden alkalommal függ a hálózat vagy méginkább egy hálózaton keresztül működő szolgátatás elérhetőségétől.

Üdv,
Marci

"Nem alakítanék ki olyan rendszert, amiben a bejelentkeztetés/zárolás feloldása minden alkalommal függ a hálózat vagy méginkább egy hálózaton keresztül működő szolgátatás elérhetőségétől."

A temaban lasd meg: MS AD, raadasul az egyszerre tobb szolgaltatastol is fugg. Tudom, cachelt login, de az is csak 30 napig segit.

Bocs, hogy kotozkodok, de IT szemszogbol alig van ertelm annak, amit irsz. Tomegesen alakitunk ki olyan halozatokat (MS-es es mas fajta rendszereket is), ahol a bejelentkeztetes igy vagy ugy fugg a halozat uzemkepessegetol.
--
Blog | @hron84
Üzemeltető macik

"Nem alakítanék ki olyan rendszert, amiben a bejelentkeztetés/zárolás feloldása minden alkalommal függ a hálózat vagy méginkább egy hálózaton keresztül működő szolgátatás elérhetőségétől."

Kiemeltem a lényeget.

Ha _harminc_napig_ nem érhető el a lokális hálózat, vagy rajta a DC, akkor aligha a bejelentkezés hiánya lesz a legnagyobb probléma a cégnél.

Nálunk MFA csak akkor kell, ha külső hálózaton van a gép, ez eleve jócskán lecsökkenti a kérdéses időszakot, hiszen besegít a DirectAccess is. Annak az esélye, hogy az Azure MFA-ban pont akkor üssön be a 0,1%, amikor te pont nem az irodában dolgozol, ÉS DirectAccess sincs, nem túl jelentős.

"lokális hálózat"

A temaban lasd meg: home office.

"nem túl jelentős."

De ha lenne egy alternativ, idoalapu feloldasi metodus, akkor az a 0.1% se bantana senkit. Tudod, ez valahogy ugy van, hogy az a 0.1% csak addig nem tunik soknak, amig nem akkor ut be, amikor valami surgosfontos munkad van, amihez azonnal kellene.
--
Blog | @hron84
Üzemeltető macik

> A temaban lasd meg: home office.

Nem attól lesz egy hálózat lokális, hogy közel ülsz a routerhez. Én otthonról is tudok intraneten belül mozogni. :)

> Tudod, ez valahogy ugy van, hogy az a 0.1% csak addig nem tunik soknak, amig nem akkor ut be, amikor valami surgosfontos munkad van, amihez azonnal kellene.

Mintha megint a képrendezős threadet olvasnám. :) Igen, elméletileg igazad van. Gyakorlatilag ahhoz, hogy a 0.1% egyáltalán elvi kockázatot jelenthessen, már igaznak kell lenni, hogy
- fizikailag nem férsz hozzá az intranethez, és
- nem elérhető DirectAccess kapcsolat, és
- nem elérhető VPN

Ha ez mind teljesül (meg esetleg olyanok, amik hirtelen nem jutnak eszembe), akkor, és csak akkor lesz egyáltalán releváns az a 0.1%. Az MFA-t nem az OS loginhoz érdemes használni, és pláne nem érdemes mindig, minden körülmények között, a második faktort.

Technikailag, ha nincs interneted valamiert, akkor a harom problema elso korben teljesul, erre mondtam, hogy home office.

Egyebkent pedig kicsit ertetlenul allok a tovabbiak elott. Ha valamit igazan vedeni kell, az a lokalis gep, hiszen a legtobb esetben az emberek ohatatlanul lementenek ezt-azt a ceges halorol, dokumentumokat, rendszerterveket, effeleket, es ha mindezt csak egy pore jelszo vedi (amirol tudjuk, hogy mennyire tud eros lenni, ha emberekrol van szo), az eleg nagy problema szvsz. Ha e melle be tudna csatlakozni egy masodik faktor, akar csak egy telefonra telepitheto idoalapu cucc, az mar sokkal eloremutatobb lenne.
--
Blog | @hron84
Üzemeltető macik

> Technikailag, ha nincs interneted valamiert, akkor a harom problema elso korben teljesul, erre mondtam, hogy home office.

Persze ha nincs neted, akkor amúgy is teljesen mindegy, mert a védett rendszerekhez sem tudnál hozzáférni. :)

> Ha e melle be tudna csatlakozni egy masodik faktor, akar csak egy telefonra telepitheto idoalapu cucc, az mar sokkal eloremutatobb lenne.

Pont addig nyújtana védelmet, amíg át nem teszem a merevlemezt egy másik gépbe, vagy nem bootolok egy másik image-ről. Az efféle adatszivárgás ellen inkább a meghajtó titkosításával lehetne védekezni, amihez egyébként (Windows alatt, legalábbis) van (kvázi-)kétfaktoros autentikáció: TPM+PIN, vagy TPM+jelszó a BitLockerhez.

"TPM+PIN, vagy TPM+jelszó a BitLockerhez."

A TPM kompatibilis laptopokon... :-)
--
Blog | @hron84
Üzemeltető macik

When BitLocker is used without a TPM, the required encryption keys are stored on a USB flash drive that must be presented to unlock the data stored on a volume.

Üdv,
Marci

printscreen ;)
Volt aki igy kicsinyitett le pl egy képet!
Megnyitotta a képnézegetőben -> félképernyőre rakta -> printscreen -> beillesztette a paint-be -> elmentette
az egységsugaruak is tudnak kreativak lenni.. ;)

Ú, ez nagyon jó! Feleségem állandóan nyaggat, hogy kicsinyítsem le a fényképezőből kijövő képeket, és már valami wxPython-os progin kezdtem gondolkodni. Ráadásul Cinnamon-ban van Shift-PrtScrn, amivel ki lehet jelölni a mentendő területet.

Pl.:Gwenview>Szerkesztés>Átméretezés
Ezt szinte mindegyik fotómegjelenítő vagy szerkesztő program tudja.
Ne mondd már,hogy ezt még nem próbáltad.

imagemagick

$ for i in $( ls *.jpg); do convert -resize 50% $i re_$i; done

Az ilyenek miatt szoktak elszaladni a szálak a shellscriptelés rejtélyei felé :D

Sikerult elegansan elterelni a temat az OTP megoldasokrol. :-)
--
Blog | @hron84
Üzemeltető macik

"Felhasználónként, havonta kb. 1.20€ a költsége"

Helyesbitek, havonta kb. 0.0€ a koltsege. Google Authenticatornak hivjak, es teljes mertekben ingyenes, nyilt forraskodu cuccrol van szo, amibe csak azert keveredett bele a Google neve, mert o tette ismertte a klienst. A TOTP/HOTP alapu kliensekkel/authentikacios megoldasokkal azonban Dunat lehet rekeszteni.
--
Blog | @hron84
Üzemeltető macik

Köszönöm a megerősítést! Így még inkább igaz, amit írtam.

Üdv,
Marci

Azt lehet tudni, hogy a MS miert adja az MFA megoldast penzert? Komolyan, van barmi olyan biztosnagi megoldasa az MS-nek, ami nem kerul penzbe? Az MSE-t inkabb hanyagoljuk.
--
Blog | @hron84
Üzemeltető macik

Pénzbe került kialakítani és fenntartani, továbbá azt gondoljuk, hogy értéket ad a Felhasználóknak, amiért hajlandóak fizetni. Például nem látom be, miért kéne "lenyelnie" vagy máshonnan kereszt-finanszíroznia a Microsoftnak a telefonhívások indításának vagy a küldendő SMS-eknek a költségét.

"Komolyan, van barmi olyan biztosnagi megoldasa az MS-nek, ami nem kerul penzbe?"
Nehéz erre jól válaszolni, hiszen mindenre mondhatod, hogy Windows vagy más szolgáltatás kell hozzá, ami meg nincs ingyen.
De ha ettől eltekintünk, akkor - messze a teljesség igénye nélkül - íme pár példa:
-Biztonsági frissítések
-Családbiztonság
-Smart Screen filter
-MFA Microsoft Accounthoz és Office 365-höz
-OS-be épített tűzfal
-Malicious Software Removal Tool
-Microsoft Safety Scanner
-Enhanced Mitigation Experience Toolkit

Üdv,
Marci

"Például nem látom be, miért kéne "lenyelnie" vagy máshonnan kereszt-finanszíroznia a Microsoftnak a telefonhívások indításának vagy a küldendő SMS-eknek a költségét."

Ezek nyilván költségek, de ha már szőrszálhasogatunk, akkor miért kell felhasználók között fix havidíjért keresztfinanszírozni, amikor lehetne percre (telefonhívás) vagy darabra (SMS) is...

...és persze az idő alapú OTP esetén nincs se telefonhívás, se SMS költség nincs, ezért ingyenes a legtöbb ilyen megoldás...

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"amikor lehetne percre (telefonhívás) vagy darabra (SMS) is..."

Lehet is, van per user és per bejelentkeztetés alapú számlázási modell is:
http://azure.microsoft.com/en-us/pricing/details/multi-factor-authentication/
10 bejelentkeztetés díja = 1 user/hó korlátlan bejelentkeztetés díja

Üdv,
Marci

Nagyszerű...

...és persze az idő alapú OTP esetén nincs se telefonhívás, se SMS költség nincs, ezért ingyenes a legtöbb ilyen megoldás...

Amelyik cégnek nincs 1.2EUR/ho/felhasznalora penze az dogoljon meg.

Epp a napokban szamoltam ki, hogy egy 10 fos vallalkozas ha a levelezeset beteszi Excahnge Online Plan-ba (office365 ha ugy jobban beugrik), akkor pont 5 millio forint felett van egy picivel 10 ev tavlataban.

Es akkor elgondolkoztam, hogy az elozo (csereerett) rendszer szinte mindenhol 10+ evet kiszolgalt....

Persze akinek nincs 4USD-je havonta, az is dogoljon meg.

Osszessegeben a Microsoft rendszerei nem jok, csak elterjedtek. Es ez barmelyik random termekukre igaz. (hello 1.2MFt-os MSSQL :)

---
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....

Ha jól értem, te a levelezést számoltad ki. Nem tudom, milyen árfolyammal számoltál a következő évekre, én 1 EUR = 315,60 HUF-ot használtam. Nettó jelenérték számítást nem végeztem és a mai árat vettem figyelembe. Remélem, nem ezek okozzák a jelentős eltérést. :)

Nézzük a fullos Exchange Online Plan 2-vel (https://products.office.com/hu-HU/exchange/compare-microsoft-exchange-online-plans?omkt=hu-HU)
10 fő * 120 hónap * 6,70 EUR/hónap/fő * 315,60 Ft/EUR = 2537424 Ft
A kisebbik csomaggal, ami egy 10 fős cégnek valószínűleg elég: 1287648 Ft
Említetted a 4USD-t, ami az USA ára a Plan 1-nek. Nálam: 10 * 120 * 4 * 280 = 1344000 Ft

Neked hogyan jött ki a több, mint 5 millió Ft?

Üdv,
Marci
A Microsoftnál dolgozom.

ott rontod el a matematikat, hogy ugyan 10 fo dolgozik a cegnel de 50-60 emailcim van, amit nem lehet email-aliaskent beallitani, tehat teljesen fuggetlen emailcimkent kell latszodnia a masik felnel.

Tekintve, hogy az exchange online plan-nal csak email alias-t lehet beallitani, full kulon emailt csak kulon accounttal, igy nem 10 fore valo 10 accountot kellene venni, hanem 40-et.

A fenti szamitas teljesen valos, amikor megneztem, de a konkret darabszamokra mar nem emlekszem. De az arak emiatt szallnak el, es nincs ra egyszeru megoldas. Az alias vonal (ami a gmail-nel is van) abszolut nem erdekel.

Elnezest a kesoi valaszert, valahogy ezt nem vettem eszre, es az emlekeztetot sem.

---
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....

"Tekintve, hogy az exchange online plan-nal csak email alias-t lehet beallitani, full kulon emailt csak kulon accounttal, igy nem 10 fore valo 10 accountot kellene venni, hanem 40-et."

Szerencsére ez nincs így, erre való a Shared Mailbox, ami külön licencet nem igényel (amíg 50GB-nál kisebb):
https://technet.microsoft.com/en-us/library/jj966275(v=exchg.150).aspx

Üdv,
Marci

Ha az a 10 fő 40 címe úgy áll össze, hogy különbözőek a domain nevek és a szerepkörök is, akkor fújhatod a shared mailbox koncepciót...

...és anélkül, hogy az előző hozzászólásban lévő konkrét igényt ismerném, a shared mailbox szerű megoldás nem jó, ha technikai email cím kell, például a

címre érkező üzeneteket a ticketing rendszer kiveszi IMAP protokollon és hibajegyet készít belőle... és még van sok ilyen megoldás, aminél az email csatorna része egy félig automatizált workflow-nak...

...igen, tudom, hogy van sok BPM megoldás hasonló célra, de egy 10 fős cég nem fogja megvenni a Halálcsillagot császári testőrséggel, klón gyalogosokkal, droid lépegetőkkel és szétrombolandó bolygókkal együtt, ha csak a hátsó kertet kell felásni.

projekt domainek vannak projekt emailcimekkel.
Egy-egy projekt elettartama 1-4 ev, emailcimet kb. 10 evig kell fenntartani, a domainnel egyutt.

---
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....

"Ha az a 10 fő 40 címe úgy áll össze, hogy különbözőek a domain nevek és a szerepkörök is, akkor fújhatod a shared mailbox koncepciót..."
Miért?

"a ticketing rendszer kiveszi IMAP protokollon és hibajegyet készít belőle"
Mi a probléma? Hadd vegye.

Üdv,
Marci

"Miért?"

Tud fogadni 40 darab shared mailbox 40 különböző domain alól levelet egy user account esetén?

"Mi a probléma? Hadd vegye."

Van külön IMAP hozzáférése mindegyik shared mailbox-nak? Amikor legutóbb néztem, nem lehetett önálló IMAP fiókként kezelni, kellett hozzá egy létező user account, amiből hozzá lehet férni.

"Tud fogadni 40 darab shared mailbox 40 különböző domain alól levelet egy user account esetén?"

Nem látok erre vonatkozó limitációt.

"Van külön IMAP hozzáférése mindegyik shared mailbox-nak?"
Van, így kell csinálni.
Valóban egy adott user jogosultságával kell bejelentkezni. Ha ez nem elfogadható (tízfős cégnél szerintem igen), akkor kell egy dedikált user a technikai hozzáférésekhez - de nem 40.

Üdv,
Marci

"Nem látok erre vonatkozó limitációt."

Nem mostanában néztem, de emlékeim szerint kell egy domain-hez lennie legalább egy user account-nak.

"Valóban egy adott user jogosultságával kell bejelentkezni. Ha ez nem elfogadható (tízfős cégnél szerintem igen), akkor kell egy dedikált user a technikai hozzáférésekhez."

Egyrészt _rendszerenként kell egy_, másrészt nem tartom jó implementációnak, hogy egy rendszer nem önálló technikai felhasználó, hanem valamelyik felhasználó nevében végez műveleteket, harmadrészt ez ebben a formában nem megoldás, csak egy jelentős workaround...

...és hány ilyet láttam (csak ez a kérdés-válasz menet közben jött elő hónapos csúszásokkal):
- Erre való a Shared Mailbox.
- A shared mailbox szerű megoldás nem jó, ha technikai email cím kell.
- Mi a probléma?
- Kell hozzá egy létező user account, amiből hozzá lehet férni.
- Valóban kell egy dedikált user a technikai hozzáférésekhez.
- Rendszerenként egy.

...és már követhetetlenül pörög a workaround és/vagy a TCO számláló, a projekt pedig harmadszor lépi át költségvetését, negyedszer a határidőt és már rég nem azok szívnak, akik kitalálták a megoldást.

Ha végigolvasod a szálat felfelé, az aktuálisan rendelkezésre álló információkra igyekeztem korrekt választ adni.
A szál eleje egy téves kalkulációból indult, annyival, hogy 10 userre az Exchange Online mennyibe kerül.
Ezt raktuk rendbe.

Te most ott tartasz, hogy mi a helyes architektúra egy 10 useres cégre, 40 különféle, biztonságilag is elkülönített IMAP-os service accountra, sok különféle domainnel.
Erre a követelményre megoldásként a Shared Mailboxot nem javasoltam, így nem a fenti "kérdés-válasz" játszódott le. Ne csúsztass, kérlek.

Üdv,
Marci

> hogy 10 userre az Exchange Online mennyibe kerül.
> Ezt raktuk rendbe.

Most atgondoltam, es nem lehet kijonni 10 accounttal egy 10 fos cegnel. A mi esetunkben semmikepp.

Tekintve, hogy nem lenne jo vegyiteni a kulonbozo projekthez tartozo leveleket, mivel az egyben archivalast is jelent. Kb. kulon cegkent kell oket kezelni.
Igy sehogyse lehet meguszni a tobb account (mint 10 fo) vasarlasat.
A 3.4EUR/ho/emailcim valoszinu egyebkent eleg lenne (es nem kell a 6.7EUR/ho/emailcim).
Raadasul vannak kulsos munkatarsak, akik valos munkat nem vegeznek, csak email aliasuk van. Ennek az arat nem tudom mennyibe kerul, es kell-e mailboxhoz kotni oket (semmi esetre se lenne jo belsos munkatars mailboxahoz kotni, mivel nem ugyanaz a szemely).

Szoval fenntartom az eredeti allitasom. A ceg meg mindig 10 aktiv munkatarssal rendelkezik, es 10 evre vetitve legalabb 5M forintba kerulne az exchange online.
De azert kosz, hogy jobban korbejartuk a temat, igy ha valaki egy ev mulva betamadna, reszletesebben tudnek neki valaszolni... :)

---
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....

"Ha végigolvasod a szálat felfelé, az aktuálisan rendelkezésre álló információkra igyekeztem korrekt választ adni."

Szerintem az az alapvető probléma, hogy ilyenkor nem visszakérdezel, hanem lekezelő hangvétellel kijelentesz dolgokat, mint például:
"Szerencsére ez nincs így, erre való a Shared Mailbox"
"Mi a probléma? Hadd vegye."
"Nem tudok itt bajról."

Aztán amikor jönnek a reakciók, akkor kénytelen vagy visszakozni:
"Valóban, ezt nem vettem észre a cikkben."
"Valóban egy adott user jogosultságával kell bejelentkezni."

Próbálj először kérdezni, tájékozódni, informálódni, aztán kijelenteni. És nézd át az apró betűs dolgokat is egy-egy szolgáltatásnál, ne csak a vastagon kiemelt feature lista alapján jelentsd ki, hogy pont az adott problémára való...

Köszönöm a visszajelzésedet.

Üdv,
Marci

félig off, különösen mert elég régi a thread, és már talán biztosan nem emlékszem minden részletre, de:

> és már követhetetlenül pörög a workaround és/vagy a TCO számláló, a projekt pedig harmadszor lépi át költségvetését, negyedszer a határidőt

Ha jól rémlik, az EXO Kiosk licenc erre bőven elég, és az pontosan havi kettő dollárral növeli a TCO-t - emiatt talán még nem kell háromszor refinanszírozni egy projektet. ;)

Tudtommal a Kiosk-hoz nincs IMAP, csak POP.
https://technet.microsoft.com/en-us/library/exchange-online-service-description.aspx

Üdv,
Marci

És tényleg. :)

> Miért?

Ha a ket domain shared mailbox neve megegyezik akkor kezdodnek a bajok:

,

De lehet, hogy ez is megoldhato, bar ezt anno ugy vettem ki, hogy annyi usert kellene vennem.

Lehet, hogy beneztem, de igy utolag orulok, hogy nem ebbe az iranyba mentem.

---
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....

ez nem erre valasz. Itt a ket domain @ elotti resze kulonbozik.
Amit en mondok ott meg megegyezik:

,

---
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....

Valóban, ezt nem vettem észre a cikkben.
Gyanúm, hogy megoldható valahogy.

Üdv,
Marci

Értettem én elsőre is! :)
Viszont almát körtével hasonlítunk, attól tartok.
Ha gondolod, vess erre egy pillantást: https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication/

Üdv,
Marci

"Viszont almát körtével hasonlítunk, attól tartok. Ha gondolod, vess erre egy pillantást:"

Ezzel nem magyaráztál meg semmit, hogy miért kellene pénzt kiadnom, illetve miért kellene jobban biztonságban éreznem magam egy SMS-ben kapott OTP-től, mint egy idő alapú OTP-től, ami például egy ujjlenyomatolvasóval ellátott telefonon van... de hallgatlak.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Reméltem, hogy összehasonlítod az Általad ismert OTP megoldásokkal.
Így, hogy tőlem várod, elég vékony jégre merészkedek, mert a nem Microsoftos megoldásokról nem sokat tudok.
Ez itt egy disclaimer akart lenni, ha a kelleténél több butaságot mondok. :)

Szerintem az SMS-ben megkapott OTP valóban nem véd jobban, de az SMS-ben visszaküldött igen (Ezt egyébként, többletköltsége miatt, kerülném.). Ugyancsak jobb a mobil app-ban megtett jóváhagyás és a telefonhívásban megadott PIN is erősebb: ezek ugyanis out-of-band védelmet adnak, míg az időalapú OTP MITM-nek kitett.
Továbbá:
-Az Azure MFA beépítve tartalmaz a visszaélések jelentésére szolgáló fraud jelentést, az IT-nak menő valós idejű riasztásokkal. Van részletes audit, amiből ütemezett riportokat készíttethetsz.
-Működik okostelefon nélkül is (akár vezetékes telefonnal is...).
-Fejlesztést nem igényel, hogy LDAP, Radius, IIS vagy Windows Authetication-be beillesszed.
-Testre szabhatók például a hangüzenetek, a Caller ID.

Üdv,
Marci

"Szerintem az SMS-ben megkapott OTP valóban nem véd jobban, de az SMS-ben visszaküldött igen. [...] Ugyancsak jobb a mobil app-ban megtett jóváhagyás és a telefonhívásban megadott PIN is erősebb: ezek ugyanis out-of-band védelmet adnak, míg az időalapú OTP MITM-nek kitett."

Egyrészt az általad átküldött leírásban annyi van, hogy jön egy bejövő hívás, amire # választ kell adni, illetve jön egy SMS egy OTP kóddal... szó nincs SMS-ben megválaszolt kóddal (ami miért is biztonságosabb, mint egy másik csatornán visszaírni a kódot?), illetve szó nincs telefonhívásban megadott PIN kóddal, ami egyébként nem a legbiztonságosabb módja az azonosításnak... szóval Te ezeket egészen pontosan hogy használod az Azure-ban? Vagy csak más leírást olvasunk?

"-Az Azure MFA beépítve tartalmaz a visszaélések jelentésére szolgáló fraud jelentést, az IT-nak menő valós idejű riasztásokkal. Van részletes audit, amiből ütemezett riportokat készíttethetsz."

Ez nem az MFA implementáció dolga, felesleges idekeverni VAGY fel kell tételezzem, hogy szimplán jelszóvédett account esetén nincs fraud detection a Microsoft megoldásoknál.

"-Működik okostelefon nélkül is (akár vezetékes telefonnal is...)."

Az összes idő alapú OTP megoldásnak van JavaME implementációja is, ami azért eléggé széleskörű eszközöket jelent.

"-Fejlesztést nem igényel, hogy LDAP, Radius, IIS vagy Windows Authetication-be beillesszed."

Hány esetben integráltad saját kezűleg például OpenLDAP-hoz vagy Linux rendszerekhez? Ugye onnan indultunk, hogy a Mozilla miért nem használ több faktoros azonosítást.

"-Testre szabhatók például a hangüzenetek, a Caller ID."

Nagyszerű... de térjünk vissza a kérdésre, mert konkrét kérdésekre úgy látom általában beindul a brossúra-felolvasó-terelő üzemmód és bullshit generátor... szóval: miért is biztonságosabb ez az egész egy ujjlenyomat olvasóval védett telefon időalapú OTP kódjától?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Vagy csak más leírást olvasunk?" - ott a teljes dokumentáció. Nézd csak kicsit lejjebb: "Two-way SMS as second factor", "PIN mode"...

Két dolgot kérdeztél, azokra válaszoltam:

1) "Ezzel nem magyaráztál meg semmit, hogy miért kellene pénzt kiadnom"
Felsoroltam, amit értékes különbségnek látok. Te: "beindul a brossúra-felolvasó-terelő üzemmód".

2) "miért kellene jobban biztonságban éreznem magam"
Válaszom ez volt: "Szerintem az SMS-ben megkapott OTP valóban nem véd jobban, de az SMS-ben visszaküldött igen (Ezt egyébként, többletköltsége miatt, kerülném.). Ugyancsak jobb a mobil app-ban megtett jóváhagyás és a telefonhívásban megadott PIN is erősebb: ezek ugyanis out-of-band védelmet adnak, míg az időalapú OTP MITM-nek kitett. "
Te: "Nagyszerű... de térjünk vissza a kérdésre, mert konkrét kérdésekre úgy látom általában beindul a brossúra-felolvasó-terelő üzemmód és bullshit generátor"

"miért is biztonságosabb ez az egész egy ujjlenyomat olvasóval védett telefon időalapú OTP kódjától?": megismétlem a válaszom másképp: azért, mert az időalapú OTP ugyanabban a csatornában közlekedik, mint a felhasználónév és jelszó, így a csatorna kompromittálódása ellen nem véd.

Üdv,
Marci

"...ott a teljes dokumentáció. Nézd csak kicsit lejjebb: "Two-way SMS as second factor", "PIN mode"..."

Ami így első ránézésre igényel egy külön MFA szervert, annak is benne van a licencköltsége a $1.4/1.2€ per user per month árban?

"Felsoroltam, amit értékes különbségnek látok."

És ezeket mind saját kezűleg próbáltad és/vagy integráltad már legalább egyszer valahol, illetve mind azon az áron kapom, amit írtál?

Mert láttam én évek alatt jó pár sales felsorolást doksiból, aztán amikor jött az implementáció, akkor mindig jött az is, hogy "ja, ez így nincs benne a licencdíjban", illetve az integrációnál valahogy mindig jött valami pár hónapos szopás, ami a demó videóban nem volt benne, a végén pedig már senki nem merte összeszámolni a TCO-t.

De tudod mit? Puding próbája az evés, szóval itt van egy CentOS 7 x64, tegyünk bele "two way SMS as two factor" MFA-t 1.2€ pénzért havonta az egyik felhasználó subversion account-jára. Mondd, mit kell tennem.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Ami így első ránézésre igényel egy külön MFA szervert, annak is benne van a licencköltsége a $1.4/1.2€ per user per month árban?"
Ingyenes.

"És ezeket mind saját kezűleg próbáltad és/vagy integráltad már legalább egyszer valahol, illetve mind azon az áron kapom, amit írtál?"
Igen. Ugyan nem saját kezűleg csináltam, mert nem ez a feladatom, de igencsak a közelében voltam. A bevezetési munkának is van költsége. A többi stimmel. (A valós nagyvállalati ár a listaár alatt lehet, a partner képzi a végfelhasználói árat.)

"Mondd, mit kell tennem." Legegyszerűbbnek tűnik nekem, ha az adott felhasználót eredetileg LDAP-ból jelentkezteted be SVN-be. Ekkor az MFA Servert LDAP proxyként konfigurálod, így: https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-get-started-server-ldap/
Természetesen megírhatod az SDK segítségével is, az biztosan munkásabb. Java, Perl, PHP és Ruby-ra van SDK az ASP.NET mellett. Bővebben: https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-sdk/

Érdemes lehet ezzel az ingyenes tréninggel kezdeni: https://www.microsoftvirtualacademy.com/en-US/training-courses/azure-multi-factor-authentication-8909

Üdv,
Marci

"Ingyenes."

Ha ingyenes, akkor miért van tőle balra egy másik csomag, aminél sokkal kisebb a feature set? Ez nekem mindig gyanús. És - néhány ritka kivételtől eltekintve - ha az egyik ingyenes, akkor a másik csak "ingyenes" volt, mert valamit még meg kellett vegyek, amivel "ingyen" jön vagy működik.

"A bevezetési munkának is van költsége. A többi stimmel."

Csak egy észrevétel: kicsit fentebb (#comment-1905125) már 6$-t láttam per user per month... :)

"Ekkor az MFA Servert LDAP proxyként konfigurálod"

Hm, ez már jól hangzik... de... az MFA szervert valahova fel kell telepítenem? Meg egy MFA User portált is? Annak a szolgáltatásnak mi a költsége, amin ezek nem csak el tudnak indulni, de már jól is futnak? Amin ezek futnak, azokra milyen SLA van? Amin ezek futnak, azokat ki fogja felügyelni, üzemeltetni és frissíteni?

Ez kezd hasonlítani a Halálcsillag tervezési mintához, amikor egy egyszerű problémára (ne egyfaktoros legyen az azonosítás) már egy egész appliance kell felügyelettel és üzemeltetéssel... :/

"Természetesen megírhatod az SDK segítségével is, az biztosan munkásabb."

Nem akarok fejleszteni, integrálni akarok, a lehető legegyszerűbben, ami jelenleg nagyjából ennyi:

# sed -i '1s/^/auth required pam_google_authenticator.so\n/' /etc/pam.d/sshd

Egy ehhez hasonló megoldást szeretnék.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Ha ingyenes, akkor miért van tőle balra egy másik csomag, aminél sokkal kisebb a feature set? "

Gyanús! Szerencsére itt nem erről van szó: az Azure MFA-hoz kétféle megvalósítási architektúra tartozhat. Ezek funkcionalitása eltér. Ára nem.

"kicsit fentebb már 6$-t láttam"
Ott, ahol nem a Microsoft-féle MFA-ról volt szó?
Mi az észrevételed?

"Halálcsillag"
Ha egy akár desktop OS-re telepíthető minimális erőforrásigényű standalone szerver ide tartozik, akkor szeretném megkérdezni, milyen szót szoktál használni komplexebb megoldásokra?

"integrálni akarok"
Azure MFA bekapcsolás, MFA szerver telepítés, konfigurálás, SVN-ben LDAP URL csere.

Üdv,
Marci

"Ezek funkcionalitása eltér. Ára nem."

Aha.

"Ha egy akár desktop OS-re telepíthető minimális erőforrásigényű standalone szerver ide tartozik, akkor szeretném megkérdezni, milyen szót szoktál használni komplexebb megoldásokra?"

Hm... egy "akár desktop OS" fog visszahívni és fogadni a hívásokat vagy csak meghívja a megfelelő cloud szolgáltatást?

Az "akár desktop OS"-nek mennyi az éves/egyszer licencköltsége és a hardvernek vagy cloud szolgáltatásnak mennyi a havidíja, amin elfut az MFA és az User portál? És továbbra is kérdéses, hogy a desktop OS-re telepített MFA szerver kiesése esetén mi a teendő? Ki fogja felügyelni, üzemeltetni és frissíteni?

"Azure MFA bekapcsolás, MFA szerver telepítés, konfigurálás, SVN-ben LDAP URL csere."

Plusz üzemeltetés, annak minden bajával és kínjával, amiről a beszállítók mindig szeretnek elfeledkezni. Szóval mennyi is így a TCO? Számoljuk már ki, mert már messze nem $1.4 per user per month a TCO.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"csak meghívja a megfelelő cloud szolgáltatást?"
Igen.

"nem $1.4 per user per month a TCO."
Szerintem sem! Pont ahogy más megoldásé sem 0.

Üdv,
Marci

Tehát meghívja a megfelelő cloud szolgáltatást és egyébként egy proxy? Most komolyan: mi a fenének kell nekem egy komponenst üzemeltetnem egy "akár desktop OS"-en, ami tulajdonképpen semmit nem csinál? Adatokat se tárol?

"Szerintem sem!"

Pedig azt írtad, hogy 1.2€ per user per month. Akkor ez nem igaz? :O

"Pont ahogy más megoldásé sem 0."

Nyilván nincs nulla TCO, de van egy jelentős különbség aközött, hogy az idő alapú OTP bizony zero administration megoldás, nem kell hozzá üzemeltetés, monitoring rendszer, mentési stratégia, frissítési stratégia, licenckövetés, CAPEX és OPEX budget tervezés... szóval mindaz, amit elegánsan kihagytál a költségek közül, pedig ezek nélkül nem működik.

"Felhasználónként, havonta kb. 1.20€ a költsége"

Innen indultunk és a fentiek alapján én igazolva látom, a mondásom:

"Mert láttam én évek alatt jó pár sales felsorolást doksiból, aztán amikor jött az implementáció, akkor mindig jött az is, hogy "ja, ez így nincs benne a licencdíjban", illetve az integrációnál valahogy mindig jött valami pár hónapos szopás, ami a demó videóban nem volt benne, a végén pedig már senki nem merte összeszámolni a TCO-t."

Nem lennék meglepve, ha lenne valami szopás az LDAP proxy integrációnál, mondjuk az, hogy csak AD-hoz hasonló sémát képes kezelni, nem rugalmasan a konfigurációja vagy nem tud olyan hash algoritmust kezelni, amit használok, de ha egyszer lesz rá időm, akkor megpróbálom.

Vagy adok egy OpenLDAP URL-t, összekattintgatod (mert elmondásod szerint csináltál ilyet), adsz egy LDAP URL-t és tesztelnünk, aztán adok 1.2€, na? :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> az idő alapú OTP bizony zero administration megoldás

Zero administration? Mi történik, ha a szerencsétlen user elhagyja a mobilját, mi történik, ha telefont szeretne cserélni, mi történik, ha új dolgozó jön a céghez, vagy elmegy egy régi? Ezzel vagy foglalkoznia kell valakinek, vagy kell egy self-service megoldás, az viszont megint nem tud a semmiből létrejönni.

Hogy integrálsz külső vendor által szállított, vagy ne adj' Isten off-the-shelf alkalmazásba TOTP megoldást?

"Hogy integrálsz külső vendor által szállított, vagy ne adj' Isten off-the-shelf alkalmazásba TOTP megoldást?"

Ahogy bármilyen más MFA-t: irtózatos szopások árán, de hogy jön ez ide?

"Zero administration? Mi történik, ha a szerencsétlen user elhagyja a mobilját, mi történik, ha telefont szeretne cserélni, mi történik, ha új dolgozó jön a céghez, vagy elmegy egy régi?"

Ez kell mindegyik megoldásnál, nem? Vagy csak az idő alapú OTP jellemzője? Komolyan le kell menni még ennél is dedósabb szintre, hogy láthatóvá váljanak a jelentős TCO különbségek? :O

Jó, lemegyek dedós szintre: tudtok adni 1.2€ per user per month áron "two way SMS as two factor" MFA-t vagy nem? Eldöntendő kérdés.

Igen esetén szeretném tudni, hogy kinek kell fizetni pusztán ezt a díjat, aki legalább 99,9% SLA-val technikai szinten üzemelteti az ehhez szükséges infrastruktúrát; a saját rendszerek minimális integrációját (egyetlen egy URL cseréjéről van szó), a felhasználók támogatását és adminisztrációját elvégzem én.

Nem esetén elvárnék egy "bocs, igazad volt" üzenetet.

Amit én látok: napokon át győzködtök, hogy térjek át a jelenlegi ingyenesen üzemeltethető TOTP megoldásról egy alapból fizetős MFA megoldásra, ami 1.2€ per user per month áron mindössze ugyanazt a biztonsági szintet tudja, mint a TOTP, csak SMS-ben és telefonhívással is tud jönni egy OTP, ha tényleg többet akarok és külön csatornán szeretném megoldani az azonosítást, akkor az már nem 1.2€ per user per month a tényleges költségem, messze nem egyszerűen integrálható, de ezt harapófogóval kell kihúzni belőletek.

Az általam ismert összes ((technical) pre) sales ember így viselkedett cégtől függetlenül. Mire jó ez, miért mindig így kell nekifutni egy problémának?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> Ahogy bármilyen más MFA-t: irtózatos szopások árán, de hogy jön ez ide?

Úgy, hogy az Azure MFA tud out-of-channel autentikálni, így talán mégsem akkora szopás integrálni.

> Ez kell mindegyik megoldásnál, nem?

De, pontosan ezt mondtam én is, te állítottad, hogy "az idő alapú OTP bizony zero administration megoldás". Ez viszont butaság.

> Amit én látok: napokon át győzködtök, hogy térjek át a jelenlegi ingyenesen üzemeltethető TOTP megoldásról egy alapból fizetős MFA megoldásra

Aha, akkor valószínűleg emiatt van a félreértés. Nem győzködni próbálunk, te kapcsolódtál be a threadbe néhány olyan megjegyzéssel, ami ráadásul nem is igaz, például hogy nem lehet darabra fizetni az SMS-ért (de lehet, még ha annyira nem is éri meg), vagy hogy nem lehet PIN kóddal védeni a második faktort (de lehet).

> ha tényleg többet akarok és külön csatornán szeretném megoldani az azonosítást, akkor az már nem 1.2€ per user per month a tényleges költségem, messze nem egyszerűen integrálható, de ezt harapófogóval kell kihúzni belőletek.

Hogy érted? Felteszed az appot a mobilodra, jön egy notification, beírod a PIN kódot, autentikálva vagy. Az integráció módja nem változik, az MFA szervert használod az LDAP proxyzásához, tökmindegy, hogy SMS-ben válaszolsz, #-et nyomsz, vagy appot használsz. Teljesen transzparens.

"De, pontosan ezt mondtam én is, te állítottad, hogy "az idő alapú OTP bizony zero administration megoldás". Ez viszont butaság."

Üzemeltetés volt a kontextus, de köss bele apróságokba, az viszi előre a világot...

Vagy értsük még ide a könyvelési és ügyviteli költségeket is a szoftver és hardverkörnyezet amortizációjával és/vagy havi előfizetési díjával együtt, ami ingyenes szoftver esetén nem kell, vagy megállhatunk ott, hogy mibe kerül ténylegesen üzemeltetni?

"Felteszed az appot a mobilodra, jön egy notification, beírod a PIN kódot, autentikálva vagy. Az integráció módja nem változik, az MFA szervert használod az LDAP proxyzásához, tökmindegy, hogy SMS-ben válaszolsz, #-et nyomsz, vagy appot használsz. Teljesen transzparens."

...mint több más megoldás esetén, amiről ezek szerint fogalmatok nincs... :/

Megéltem már néhányszor, hogy jött például az IBM, az Oracle és a Microsoft is, mindegyik mondta, hogy az SSO megoldása a legeslegjobb, aztán kiderült, hogy - ugyan más-más ok miatt, de egyik se volt alkalmas a feladatra. A közös jellemző az volt, hogy egyik ((technical) pre) sales ember se volt képes ezt megérteni, továbbra is fényezte a sajátját és fikázta a többit. A licencköltség és TCO számolást pedig meg se merem említeni, hogy mennyire képtelenek voltak átgondolni, hogy mekkora tényleges költségbe kerül a megoldásuk. Sajnos ugyanezt látom rajtatok is... :/

A jelenlegi megoldásom egy TOTP (Google Authenticator) egy darab PAM modullal, ez a baseline, 0 forint üzemeltetési költséggel, ez a biztonsági szint nekem megfelelő és ezzel például a Mozilla se lett volna kompromittálva.

Jöttök, és ajánlani próbáljátok az MS-MFA-t, aminek "havonta kb. 1.20€ a költsége" per user. Aztán most már ott tartunk, hogy kell hozzá legalább egy VPS, arra egy "akár desktop OS", arra egy MFA szerver és egy User portál, aminek azért valljuk be, önmagában is van egy jelentős költsége és még csak nem is üzemeltettük. Ez kell ahhoz, hogy legyen egy fentiekkel azonos biztonsági szintem. Ha több kell - mondjuk az integrálandó két csatornás és kétfaktoros azonosítás, akkor jönnek hozzá a járulékos költségek is. Ha a fentiekkel azonos SLA-t szeretnék, akkor viszont kell egy komplett üzemeltetés is. Egyik sincs ingyen.

És közben ott vannak az olyan versenytársak, mint a https://www.duosecurity.com/pricing vagy a https://www.twilio.com/authy, hogy ha már nem én akarok szopni az üzemeltetéssel, akkor hasonló vagy olcsóbb áron tényleg kinyalják a seggem.

Nézzetek már kicsit körül a piacon. Mondjuk az ügyfél szemével.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> mint több más megoldás esetén, amiről ezek szerint fogalmatok nincs... :/

Lebuktam, Google Authenticatort is csak egy-két saját szerverre telepítettem, az SSH-t megvédeni, egyébként üzemeltetési ismereteim tényleg nincsenek a többiről. Bár azt hittem, miután ennyi kérdést feltettem, ez előbb lesz nyilvánvaló. :)

Sok dologban ráadásul igazat is adok neked, egy szóval nem mondtam, hogy a TOTP úgy általában rossz lenne, meg azt sem, hogy az Azure MFA az egyetlen megoldás.

Őszintén szólva nem értem, miért eszkalálódott ide a vita, amikor innen indultunk, nem szó szerint idézve:
A: - Van MFA megoldás 1.2 euróért
B: - Van ingyen is.
A: - Tényleg, akkor még inkább jár a fekete pont a Mozillának
B: - Te, egy for-profit cég miért adja pénzért a termékeit?

Nem az a baj, hogy egy for-profit ceg penzert adja a termekeit, hanem egy olyan megoldast ad penzert, aminel a fizetos resz gyakorlatilag ki van kenyszeritve, allitom, hogy a user portalt kompletten el lehetne adni SaaS formacioban is, nem kellene ezt on-premise eroltetni, csak nyilvan igy nem lehet az "akar desktop OS" licencdijat beszedni meg kulon a paraszttol. Kicsit is jobb helyeken ezt bujtatott arukapcsolasnak hivjak, de persze no problem, csak akkor legyunk oszintek.
--
Blog | @hron84
Üzemeltető macik

"Fejlesztést nem igényel, hogy LDAP, Radius, IIS vagy Windows Authetication-be beillesszed."

Tkp ez az MS-en mulik. Ha nem mindig mindent a sajat megoldasahoz fejlesztene ki, hanem ugy, hogy konnyu legyen providert irni hozza, akkor siman lehetne illeszteni Google Authenticatort is.
--
Blog | @hron84
Üzemeltető macik

> LDAP, Radius
> az MS saját megoldásai

Hát őő... :)

Mutasd meg, hogy hogyan lehet integralni a Google Authenticator-t az LDAP-ba, Radius-ba, ...-ba Windows platformon. Biztosan van ra valami fasza MSDN cikk, ahol megmutatjak, honnan kell letolteni a DLL-t.
--
Blog | @hron84
Üzemeltető macik

És ez azért releváns, mert...?

Azt írtad fentebb, hogy a MS mindig mindent a saját megoldásaihoz fejleszt ki. Például az MFA-t az LDAP-hoz. Ebből logikusan az következne, hogy az LDAP egy Microsoft termék, pedig nem. Bármilyen LDAP-ot használható alkalmazás használhat MFA-t, az MFA ugyanis tud LDAP proxyként viselkedni, így kb. csak a URL-t kell átírni az alkalmazásban. Linuxon is.

Hogy jön ide a Google Authenticator, és a DLL-ek? MFA-s LDAP-hoz nem kell az alkalmazásnak külső DLL. Az Authenticator esetében ezek szerint igen?

Az MFA alatt az Azure/Microsoft MFA-ra gondolsz (barmi is legyen a neve), ugye? Mert az MFA egyebkent egy mar foglalt kifejezes, tud felreertheto lenni, ahogy felre is ertettem azt, amit mondtal.

Egyebkent meg mindig arrol beszelgetunk, hogy a Microsoft feltalalta a spanyolviaszkot, letrehozott egy N+1-edik tobbfaktoros authentikacios szervert, amihez jol lehet illeszteni mindent, ennek orven rogton lett a Windowsokban is multifaktoros login - amely login kizarolag a Microsoft megoldasat tamogatja. Semmi egyeb mast. De persze, orvendezzunk, vigadjunk, mert a Microsoftos MFA szerverhez kivaloan lehet mindent passzitani, leginkabb a Windowsos cuccokat, nahat.

Egyebkent vannak ketelyeim a "kb. csak a URL-t kell átírni az alkalmazásban. Linuxon is." korul is, de ez mar privat velemeny. Mar az AD tamogatasa sem olyan egyszeru eset, pedig az meg csak nem is proxy, hanem elvben egy rendes LDAP.
--
Blog | @hron84
Üzemeltető macik

> Egyebkent vannak ketelyeim ...

Alkalmazásokról beszélünk, nem OS-ekről. Legalább az Overview részt olvasd el légyszi a termék leírásának, mert szerintem itt most keverjük a dolgokat.

Az Azure MFA arra jó, hogy ha a parasztja véletlenül átadja másnak a ticketing rendszer jelszavát, ne tudjon illetéktelen hozzáférni. Ha a ticketing rendszer történetesen LDAP-ból autentikál, akkor működik vele az Azure MFA. Pont. Ha valami teljesen egyedi megoldást használ, akkor is működhet, de arról a vendornak kell gondoskodnia.

Elvi szinten igazad van, mert tényleg nem támogatja a világ összes autentikációs megoldását OOTB (például támogathatná a hup accounttal való belépést is, nem?), de messze nem arról van szó, hogy MS-only technológiát támogat csak. Ellenpélda az LDAP és a Radius. Ne is pazaroljunk több szót a dologra.

"világ összes autentikációs megoldását OOTB"

Ez tereles, senki nem beszelt a vilag osszes authentikacios megoldasarol. Viszont vannak OTP szabvanyok (HOTP/TOTP) amiket a vilag nagyobbik fele tamogat. Nem random authentikacios megoldasok, hanem szabvanyok. En el tudnam viselni, ha a MS egy kicsit jobban odafigyelne arra, hogy mi tortenik a vilagban, es egy uj feature implementalasakor eloszor korbenezne, hogy milyen szabvanyok vannak forgalomban a temahoz, es ahhoz igazodna. Erre mondom azt, hogy tul sok a belsos megoldas, mert jelenleg ez nem igy van.
--
Blog | @hron84
Üzemeltető macik

Oké, van egy off-the-shelf alkalmazásod, ami LDAP-ból autentikál. Hogy oldod meg, hogy legyen benne TOTP? (Lehet, hogy meg lehet oldani, komoly a kérdés, nem provokáció.)

Mindeközben Azure MFA-val:
1. Felkonfigurálod az MFA-t
2. Az MFA szerver-t adod meg, az eredeti LDAP elérési út helyett
3. ...
4. PROFIT

Ugyan így, csak MFA helyett mondjuk FreeRadius van, de van még pár opció, attól függően, hogy mihez kell integrálni...

...a Microsoft MFA szerver nem A megoldás, hanem EGY megoldás a sok közül. Sok esetben nem is a legolcsóbb és még csak nem is a legjobb.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> Ugyan így, csak MFA helyett mondjuk FreeRadius van, de van még pár opció, attól függően, hogy mihez kell integrálni...

Biztos ez? Veszel egy alkalmazást a cégednek, ami tud LDAP-ból autentikálni. Hogy erőlteted bele a TOTP-t? Nem a vita kedvéért kérdezem, tényleg nem értek hozzá. Laikusként végiggondolva még egy textbox sincs a szoftverben, ahova beírhatnád az OTP-t, mert nem lett rá felkészítve.

> a Microsoft MFA szerver nem A megoldás, hanem EGY megoldás a sok közül

Ebben abszolút igazad van, eszembe nem jutna, hogy az ellenkezőjét állítsam. :)

""a Microsoft MFA szerver nem A megoldás, hanem EGY megoldás a sok közül""
"Ebben abszolút igazad van, eszembe nem jutna, hogy az ellenkezőjét állítsam. :)"

Pedig a kommunikációd és metakommunikációd erre irányul.

"Biztos ez? Veszel egy alkalmazást a cégednek, ami tud LDAP-ból autentikálni. Hogy erőlteted bele a TOTP-t?"

Az előbb leírtad, hogy mennyire egyszerűen lehet négy lépésben profitot elérni, most meg azt kérdezed, hogy biztos úgy van-e? :)

"Laikusként végiggondolva még egy textbox sincs a szoftverben, ahova beírhatnád az OTP-t, mert nem lett rá felkészítve."

A Microsoft féle MFA hogy működik ebben az esetben? Más szoftver nem tud úgy működni, ugye? :D

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> Más szoftver nem tud úgy működni, ugye? :D

Nem tudom, mert hiába kérdeztem, egyszer sem válaszoltál. Most is a metakommunikációval jössz (írásban?), ahelyett, hogy konkrét példát mondanál.

Oké, tfh vettél egy line-of-business alkalmazást, ami LDAP-ból autentikál, mint ahogy általában elég sok LOB alkalmazás teszi. Én leírtam, hogy az Azure MFA-t hogy lehet bekötni. Emlékeztetőül: MFA szerver telepítés --> LDAP proxyként beállítás --> alkalmazás beállítása, hogy a proxy-tól kérdezzen.

Hogyan lehet bekötni ebbe egy tetszőleges TOTP megoldást? Nyilván anélkül, hogy disassemblerrel nekiesnél a szoftvernek. Hasonlóan high-level leírás elég nekem, nem a konkrét technikai leírás érdekel, csak a folyamat. (Megint csak: nem a vita kedvéért kérdezem, tényleg nem láttam még ilyet, ezért érdekel.)

Az is lehet, hogy igazad van, de próbáld már meg légyszi, csak egyszer, egyetlen egyszer, hogy nem egy újabb kérdéssel, vagy éppen valami provokációval válaszolsz, hanem a saját véleményed (vagy még inkább a tapasztalatod) írod le!

Ez olvastad? "Ugyan így, csak MFA helyett mondjuk FreeRadius van."

"Hogyan lehet bekötni ebbe egy tetszőleges TOTP megoldást? Nyilván anélkül, hogy disassemblerrel nekiesnél a szoftvernek."

Én eddig háromféleképpen oldottam ezt meg, attól függően, hogy milyen módon használta a 3rd party szoftver az LDAP-ot és milyen biztonsági szintet vártak el, illetve mennyire számított a költség:
- csak TOTP jelszó van
- dupla azonosítás, az első esetben csak a jelszót kell beírni, utána a TOTP kódot, ha mind a kettő sikeres, akkor van azonosítva a felhasználó
- PIN + TOTP jelszó

Ezeknél nincs szükség extra szoftver telepítésére, üzemeltetésére és/vagy monitorozására. Egyéb esetre ott van például a FreeRadius, de sok egyéb lehetőség és megoldás van még erre a feladatra, csak körül kell nézni. És ismét leírom, hogy az MS-MFA egy a sok közül és nem a legjobb és/vagy legolcsóbb, a legtöbb use-case esetén "Halálcsillag design pattern" a bevezetése, a maradék esetben pedig vannak egészen jó versenytársak a piacon.

"Az is lehet, hogy igazad van, de próbáld már meg légyszi, csak egyszer, egyetlen egyszer, hogy nem egy újabb kérdéssel, vagy éppen valami provokációval válaszolsz, hanem a saját véleményed (vagy még inkább a tapasztalatod) írod le!"

Ezt azért Te (illetve Ti) is kipróbálhatnátok egyszer... :D

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Na, ilyesmire voltam kíváncsi!

Third party cucc esetén hogy írod be a TOTP jelszót? Sok appnál ugye újabban az a megoldás, hogy gyakorlatilag egy embedded böngészőablak autentikál, ahol lehetőség van több fázis megjelenítésére, igény szerint - ehhez viszont szükség van arra, hogy az app fel legyen készítve erre a lehetőségre.

Mi a megoldás, ha nincs? Életemben nem üzemeltettem még FreeRADIUS-t. Gondolom ott is valami olyasmi a trükk, hogy menet közben elkapod az autentikációs kérést, és bekéred a második(, harmadik, n-edik) faktort. Erre van valami SSO-szerű felület?

> És ismét leírom, hogy az MS-MFA egy a sok közül

Akkor én is leírom ismét: teljes mértékben igazad van! :)

> Ezt azért Te (illetve Ti) is kipróbálhatnátok egyszer... :D

Szerintem épp ez történik: nekem (technikai oldalról, userként nyilván láttam már elég sok dolgot) csak Azure MFA-s ismereteim vannak, ezért kérdezősködöm.

Könnyű providert írni, többféle SDK van.

Üdv,
Marci

Ezt jo hallani. Akkor talan elindulhat egy jo folyamat is.
--
Blog | @hron84
Üzemeltető macik

A munkahelyemen bizonyos szolgáltatások eléréséhez nem rég vezettek be MFA-t. Egyik kollégám nem volt hajlandó a saját telefonjára feltelepíteni az ehhez szükséges alkalmazást (hozzátenném, teljesen jogosan), ezért ő a telefonhívásos módszert választotta, ami nyilvánvalóan nincs ingyen. Megnéztem az árazást, csak per user lehet fizetni, és még a legnagyobb (6$/user/hó) csomagban sem áll korlátlan kredit rendelkezésre (amit a telefonhívások, sms-ek fogyasztanak). Egész biztos vagyok benne, hogy legalább a dupláját fizeti a cég annak, amennyibe a Microsoft szolgáltatása kerülne felhasználónként (persze ezért cserébe lehet, hogy több minden is jár).