A körülmények pontos részletezése nélkül kérdezném mindenkitől, hogy a következő szituban:
1) van-e értelmesebb megoldás és csak nem látom a fától az erdőt
2) láttok-e bármilyen gyenge pontot a rendszerben
3) mi legyen a kulcshossz
Alapfelállás: személyes kontakt nélkül, úgy, hogy nincs egyéni titkok cserélésére és ráadásul nem tárolhatok a leendő felhasználókról semmilyen adatot kellene egyéni hozzáférési adatokat (felhasználónév/jelszó) kiosztani viszonylag kis számú embernek. A csoporton belül megoldható a zárt kommunikáció, de azt a csoport összes tagja látja, az egyes emberekkel egyedül e-mailben lehet kommunikálni [ráadásul azt se mindenkivel, de ez az a pont, amikor nem érdekel, nem tudok vele mit kezdeni, szépen slattyogjon be az irodámba és igazolja magát].
Amit kitaláltam: a zárt csoportban terjesztek egy közös, osztott jelszót (ez lesz az authorizáció része a dolognak, nagyjából feltételezhető, hogy a zárt csoporthoz más nem fér hozzá és a felhasználók harmadik félnek nem fogják kiadni) és e-mailben kiküldök mindenkinek egy levelet, amiben egy url tartalmazza a szükséges adatait és egy digitális aláírást (ő az authentikáció). Ha a megadott adatokhoz érvényes aláírással küld, kap egy formot, megadja a kívánt jelszavát, az osztott jelszót és elfogadja, hogy tárolhatom róla a szükséges adatokat, elkészítem a felhasználói fiókját és megkapja a usernevét - itt már akkor tudom az e-mail címét tárolni [adott rá engedélyt], az alapján az újrapróbálkozókat tudom követni.
Ha ezt még megfejelem egy időbélyegzővel, és egy link mondjuk csak 24 órán át érhető el, akkor már akár biztonságosnak is lehetne tekinteni - ahhoz, hogy valaki illetéktelenül szerezzen hozzáférést benne kell lennie a zárt csoportban és hozzá kell férnie egy a szintén a csoportban levő másik user postájához; és még ebben az esetben is legfeljebb 24 órára szerez ugyanolyan szintű hozzáférést, mint amivel eleve rendelkeznie kellene, mondjuk megszemélyesítve valaki mást. Ennek az esélye viszont vállalhatónak tűnik.
Vélemények? Milyen hosszú legyen a kulcs? Elég az 1024 bit (azzal viszonylag vállalható hosszú az aláírás - base64 kódolva 172 karakter), vagy 2048 (344 karakter)/4096 (684 karakter) legyen inkább?
Az ötleteket, tippeket, javaslatokat előre is kösz.
- 2205 megtekintés
Hozzászólások
3x olvastam el :) de tiszta
1. szerintem nem, fura szitu, egy teljesen vállalható megoldással
2. gyenge pont mindig a kétlábon járó ;-)
3. itt szvsz teljesen "mindegy" a kulcshossz, mivel nem az a gyengepont && csak ideiglenesen kell
- A hozzászóláshoz be kell jelentkezni
az lehetseges, hogy a usernev az email cimmel megegyezzen?
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
Egy AD-be kerülnek a userek, úgyhogy a 20 karakteres SAMAccountName limit meg van. Az miben segítene?
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
ez uj info :-) Akkor feltetelezem, az osszes email cim ugyanabban a domainben van (ezt force-olni kell a form-ban). Az egesz arra ment ki, hogy a usernev ugyanaz legyen, mint az email cim lokal resze, igy kivedheto a masik user megszemelyesitese, ha az account csak az email cimre erkezo confirm levelben erkezo megerosites elvegzesekor aktivalodik.
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
Sajnos nem, mindenkinek csak privát e-mail címe van és csak azt ismerem :( [de az legalább egy elvileg biztos pont]
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Több, mint 25 fő?
Üdv,
Marci
- A hozzászóláshoz be kell jelentkezni
Nagyságrenddel biztosan nem több, viszont folyamatosan ismétlődő feladat lesz, ezért kellene az automatizálás.
Szerk.: azért a <25 főre működőnek tűnő megoldás is érdekel, hátha közelebb visz (gondolom azért kérdezted így, mert arra van ötleted)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Leginkább mindenkinek be kellene "slattyogni" az irodába, mert egyébként sehogy nem fogod tudni őket egyértelműen és kétséget kizáróan azonosítani/regisztrálni. Esetleg külső azonosítás szolgáltatást lehetne még igénybe venni, ahol van viszont-azonosítás.
- A hozzászóláshoz be kell jelentkezni
+1
PGP vagy S/Mime?
A helyedben generálnék egy publikus kulcsot (titkosításhoz), a felhasználók szépen importálják a levelezőprogramjukba, titkosítva küldjék el az adataikat (a jelszavukkal együtt), te pedig visszafejted, mented az adatokat, és kész.
Vagy átírányítod őket egy https oldalra, ahol kitöltik a kitöltenivalót, megadják a jelszavukat, kész. Ha kicsit kifinomultabbat akarsz, mindenki névre szóló URL-t kap (beleteszel egy GUID-ot / UUID-t az URL-be), ami 24 óra múlva lejár.
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
a felhasználók szépen importálják a levelezőprogramjukba
Nincs biztonságos csatornám, amin keresztül el tudnám küldeni nekik a nyilvános kulcsot, és (felhasználókról beszélünk, ugyebár) nem szeretnék plaintext találkozni a mindenhol használt kiskutya11 jelszavaikkal. (és felhasználók, fogalmuk sincs, hogy mi az a titkosítás, kulcs stb.) :(
Vagy átírányítod őket egy https oldalra, ahol kitöltik a kitöltenivalót, megadják a jelszavukat, kész.
Itt meg ugye az a gond, hogy így nincs hitelesítve, hogy amit kitöltöttek, az fedi a valóságot.
Ha kicsit kifinomultabbat akarsz, mindenki névre szóló URL-t kap (beleteszel egy GUID-ot / UUID-t az URL-be), ami 24 óra múlva lejár.
Az egyéni és lejárós url a fentiben meg van.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
ha fogalmuk nincs a pki-rol, akkor felejtos, de csak a tornetirok kedveert jegyzem meg, hogy a publikus kulcsot nyugodtan kuldheted nem biztonsagos csatornan is...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
... ha egy megbízható harmadik fél aláírta (mondjuk tényleg ezt a legegyszerűbb megoldani) és a túlsó fél meg tud győzödni a hitelességéről.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Ez ma már nem űrtechnika...
Egyébként ha csak emailen lehet velük kommunikálni, te sem tudsz meggyőződni arról, hogy tényleg azzal kommunikálsz, akivel akarsz.
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
Jaja, tudom, több ízben érveltem már ugyanez mellett a topicban :)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Persze, ez lenne a legjobb megoldás (és ez volt az én első javaslatom is), de van, akinek az ezer km-es utat jelentene :(
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Akkor megereszt egy telefont (hangos, képes chat) - amit te elfogadsz azonosításnak (vagy fax aláírással).
A többi már játék a pki-val.
- A hozzászóláshoz be kell jelentkezni
Lehet nem jól értem mit szeretnél, de szeritem erre egy kis saját PKI tökéletes.
- user kreál magának kulcsot + cert requestet,
- neked elküldi (vagy személyesen beviszi),
- Te aláírod,
=> lesz érvényes tanúsítványa.
Ezt aztán lehet titkos levelezre, és/vagy webes authentikációra is használni.
A hozzáféréseket és a tanúsítványok érvényességét és használhatóságát is Te kontorlálod, és mindent a user kezdeményez.
hmm?
Persze nem mindegy hogy a csoport tagjaitól milyen szintű IT tudás várható el. De a leírásod alapjn feltételezem, hogy minimum tisztában kell lenniük a privacy és security alapelvekkel.
--
zrubi.hu
- A hozzászóláshoz be kell jelentkezni
De a leírásod alapjn feltételezem, hogy minimum tisztában kell lenniük a privacy és security alapelvekkel.
Sajnos nem :(
- neked elküldi (vagy személyesen beviszi),
A személyes behozatallal együtt ez rendben is lenne, az elküldinél meg megint visszajött a probléma, hogy én az előzetes engedélyük nélkül nem tárolhatom a nevüket/e-mail címüket (de feldolgozhatom... no comment, jogász pajtásék dolgoznak...), vagyis az eleve kétes azonossága (bárki küldhet e-mailt) alapján se tudnék jogosultságot ellenőrizni.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
az elküldinél meg megint visszajött a probléma, hogy én az előzetes engedélyük nélkül nem tárolhatom a nevüket/e-mail címüket (de feldolgozhatom.
Egy tanúsítvány kiállításakor neked nem kell tárolnod semmit a felhasználókról.
Azt mondtad van egy zárt csoport. Ha csak onnan fogadsz el tanúsítvány requesteket, akkor mi a gond? (és/vagy mitől rosszabb ez mint a Te megoldási javaslatod?)
maga a tanúsítvány request, és a kiállított tanúsítvány is publikus, nyugodtan mehet a közösbe (zárt csoport) vagy akár bármilyen publikus csatornán keresztül is...
--
zrubi.hu
- A hozzászóláshoz be kell jelentkezni
Ja, hogy a csr is mehet a zárt csoportban (megbízható/hitelesített csatornán). Jogos! (ez a fától az erdőt eset, amit írtam a bevezetőben :) )
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni