Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Něco navíc v zeleném?
A proč ne...

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub Web [ŽP: neomezená] (kategorie Programování) moderuje Kdokoliv.
Archiv
Domovská stránka aktualizována 28.7.2019 17:46
  
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: acwgwpf
[ 4074 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
bredy 23.7.2010 21:56  7359
RiderOkaj dobrý. Já sám považuju ty zákony (po tom, co jsem si je zběžně přečetl) za jakési teoretické cvičení, něco jako desatero božích přikázání. Možná jsou ideálem, ale nikdy podle mne nebude možné je dodržet v plném rozsahu. Píšeš, že existují systémy, které je dokáží doržet ve větším rozsahu. Možná, otázkou je, za jakou cenu.

Kritizuješ nedodržení 3. zákonu, s poukazem, že někde se to dělá bez nutnosti mít 3. stranu. Je legrační kritizovat systém identifikace založené na ověření u 3. strany s tím, že identifikace přes 3. stranu není správná. To je to létání bez mávání křídel. Možná lze se vyhnout třetímu kanálu mezi SP a IdP. Opravdu? Co když ne. Co když ten kanál tam tedy přímo neexistuje, ale existuje tam virtuálně? I přesto, že tam namalovaný není, tak systémem redirectů se ve skutečností nějaká data mezi SP a IdP předávají, akorát, protože jdou přes UA, musí tam být dobré zabezpečené. Jsi si jist, že ani takový systém neporušuje 3. zákon? Opravdu? Akademická diskuze.

A stejně tak modla non-auditing IdP. Život je plný kompromisů. Můžeš mít maximální svobodu, ale budeš bojovat s podvodníky, nebo maximální ochranu, ale nebudeš svobodný. IdP ti dává ochranu, ale bere ti svobodu, umožňuje ti jí část sebrat (svobodu na určité soukromí). Ale nejsi úplně bez nástrojů, právě jedna svoboda ti zatím zůstává, vybrat si zvlastního uvážení IdP, případně se sám stát IdP a problém s non-auditing IdP jsi právě vyřešil. Problém není se identifikovat, problém je prokázat, že ta identifikace není podvržená.

Jak jsem napsal, je to teoretické cvičení, akademická diskuze, vhodná opravdu spíš do přednáškové síně vysoké školy. Praxe ale ukazuje, že dobrá a rychlá služba je drahá, že levná a rychlá služba není dobrá a že levná a dobrá služba není rychlá. Prostě tohle je systém, který by měl pomoci v rozšíření právě jednoduchou implementací za cenu nižší obecnosti. Jednou doufám, že už si nebudu muset pamatovat tisíce hesel na různé e-shopy, a že i na Lopuch se přihlásím jménem a heslem do Seznamu.

Konečně, i ono slavné OpenID porušuje značnou část těch zákonů. Dokonce bych řekl stejné množství jako moje řešení. Jen je navíc ještě komplikované.
rider Rider - Asociace chovatelů antropomorfních koní 23.7.2010 15:35  7358
No, mám pocit, že v této fázi už jakákoliv diskuze nemá smysl. Vymyslel jsi n+1 autentizační systém, který podle mého názoru nepřináší nic, co by tady už nebylo. Zároveň má problémy, které některé jiné systémy už nemají, protože je buďto považuješ za nedůležité (např. 3. zákon identity) a nebo je pokládáš za neřešitelné (např. non-auditing IdP).

Pokládat některé aspekty za nedůležité je tvé svaté právo (já zase pokládám za nedůležité jiné aspekty, jako například jednoduchost technické implementace), je možné, že se všichni ostatní mýlí a ty máš pravdu, v tom případě tvůj systém bude úspěšný.

Že pokládáš za neřešitelné jiné aspekty je trochu zarážející, vezmeme-li v úvahu že jiné systémy je rutinně řeší, ale je jistě tvou volbou nestudovat stávající situaci v oboru, do kterého ses rozhodl vstoupit.

Prostě to naprogramuj a zveřejni a uvidíš. IMHO po tom pes neštěkne, ale budu rád, když se budu mýlit.

bredy 23.7.2010 11:29  7357
Další problém tvého řešení je, že IdP je z principu vždycky Auditing IdP, neumožňuje implementovat Nonauditing IdP. Jinými slovy, můj identity provider ví, kam všude se s ním přihlašuju (protože je tady přímá komunikace mezi ním a SP). Což pro tyhle jednoduché věci taky není dobře.

IdP to bude vědět vždy. I když si budeme hrát na to, že nebude. Bude, minimálně proto, aby uživateli zobrazil informaci o tom, kdo po něm chce ověření. Protože uživatel musí mít jistotu, že to je tentýž kam se on chce přihlásit. Ze IdP ví, kam se nějaký uživatel přihlašuje je samořejmě pro někoho na škodu, otázkou je, zda IdP ví, kdo to je. Proti tomu mám tzv. aliasing, kdy uživatel má možnost si zřidit vlastní IdP delegováním procesu přihlášení na jiného IdP nebo podle SP i na různá IdP. Zřízení vlastního IdP pomocí delegování je jednoduché, protože na to není potřeba žádný skript, jen textový soubor na vhodné adrese.
bredy 23.7.2010 11:00  7356
RiderK slepému přihlášení. To ID nemusí být nutně stejné pro každého SP. Už proto, že SP se na IdP identifikuje nějakým svým jménem (většinou URL). Ano jistě, tato identifikace není ověřená, ale není jediná, další dodatečnou identifikací může být IP adresa požadavku (právě na tom druhém kanále), nebo klidně nějaká forma certifikátu (což může být rozšířený atribut akce login). Pokud jde o tu nejjednoduší identifikaci, tak ta se zobrazuje uživateli, takže si jí může zkontrolovat. Uživatel může každému SP poskytnout jiný profil s jinými osobními údaji a i s jiným profilem je spojeno jiné ID.

Požadavek třetího zákona je takový schizofremní. Asi jako kdyby řekl, že můžeš lítat, ale přitom se nesmíš mávat křídly. Budeme vymýšlet jak se drbat přes hlavu, abysme tomuto nesmyslnému požadavku vyhověli. Přitom IdP není jen tak "někdo třetí". Je to autorita, kterou si vybral uživatel, asi tak jako když si při obchodním jednání vybereš zástupce. Je to tvůj tajemník, někdo, komu věříš a kdo za tebe řeší věci, na které sám nestačíš. Původní požadavek je nesmyslný i z jiného důvodu. Jak SP tak UA potřebuje mít nějakou jistotu. SP musí mít jistotu, že nelžeš a UA musí mít jistotu, že SP tě správně identifikuje. A právě ten třetí IdP dává oběma stránám tuhle jistotu. Už proto má dost velký význam směr šipky v návrhu od SP do IdP, protože tím SP získává jistotu, že mu nelže ani UA ani IdP.

To že ví tvůj IdP, kam se přihlašuješ není na škodu. Protože IdP jsi si vybral ty. Pokud máš veřejnou IP adresu, není problém si zřídit IdP na svém počítači. A nebo prostě máš autoritu, která ti něco garantuje a svou identifikaci jí svěříš. Tohle není problém technologie, ale pouze důvěry mezi autoritami. Mimochodem myšlenka lokálního IdP je stará. Co taková služba IDENT, která se dnes z důvodů NATů a firewallů nepoužívá. Ale fungovala stejně. Po přihlášení se SP zpětným dotazem ověřoval, že jsi opravdu ten, za koho se vydáváš.

Ochrana proti phishinku: Ještě mám jeden nápad a to je využití cookies. Uživatel si na IdP nastaví kontrolní text, který se mu zobrazí při každém přihlašování. Tento text bude uložen buď přímo v cookie, nebo na serveru (v cookie bude hash). Podvržená stránka tuhle informaci nezíská, takže nebude moci zobrazit kontrolní text. Například jméno počítače, nebo nějaký pozdrav. Možností je i vlastní design stránky, nebo zvolený obrázek. Důležité je, aby tahle informace byla uložena v UA. Kontrolu pak provádí uživatel vizuálně. Jakákoliv jiná kontrola by vyžadovala spolupráci s UA, například že by prohlížeč mohl ověřit, že login stránka patří tomu IdP, do kterého se uživatel přes svoje ID přihlašoval. V tuto chvílí to zvládá jen člověk.

Nemohu říct "beru jakéhokoliv providera, který mi sdělí tenhle claim".

To samozřejmě jde. Při discovery fázi v bodě 2 může IdP dodat nějaké atributy, které SP může použít. Při té fázi totiž přímo komunikuje s IdP a může od něj požadovat prakticky cokoliv.
puschpull puschpull být nad věcí, pohoda a klid ... - AV-Com (Homepage) 23.7.2010 06:45 - Oblíbené kluby (08:51) 7355
co vy na toPískoviště pro programátory - Zdroják
:-)
rider Rider - Asociace chovatelů antropomorfních koní 23.7.2010 01:57  7354
Trochu moc nám to košatí, doufám že na nic nezapomenu...

Myslím si, že hlavní rozpor mezi námi je v tom, že ty jako hlavní překážku rozšíření OpenID a podobných technologií vidíš obtížnou implementaci na straně SP a IdP a jako takovou se ji snažíš řešit. Já tento názor nesdílím. Myslím si, že pokud jediná výhoda, kterou tvůj systém nabídne, bude jednodušší implementace, nemá šanci na úspěch.

Problém spočívá ve třetím zákoně identity, tedy v tom, že do procesu autentizace by neměl být zatažen nikdo, kdo tam nezbytně nutně nepatří. Důvod neúspěchu první generace identity systémů (nejzářnějším případem je Passport, ale je jich spousta) je právě to, že lidé nechtějí do své komunikace zatahovat třetí stranu - ani z pozice koncového uživatele, ani z pozice SP. Pro velkou většinu aplikací je IdP jako třetí strana v podstatě zbytečný. Možnost být sám svým IdP je v tvém systému tak komplikovaná, že ji většina uživatelů nemá šanci využít. Smysl má IdP jako třetí strana v několika specifických případech, kde je ale obvykle vyžadována mnohem vyšší úroveň zabezpečení a kde není problém dostatečně robustní mechanismus implementovat.

Z mého pohledu jediným zajímavým momentem tvého návrhu je "slepé přihlášení". Z toho co jsi napsal nicméně předpokládám, že onen "jakýsi jednoznačný identifikátor tebou vybraného profilu" bude pro všechny SP stejný. Čímž se podle mého názoru výhoda anonymity dost ztrácí. Ono je dost jedno, jestli SP bude mít jako můj handle přímo moje ID nebo nějaký blábol, důležité je, aby se dva různí SP nemohli za mými zády domluvit a spojit si ta data. Mnohem rozumnější mi přijde implementace Personal Information Card, kde se jako identifikátor používá hash z PPID (jednoznačný identifikátor uživatele) a identity SP (podle certifikátu nebo hostname). To elegantně řeší soukromí i problém phishingu, protože každý SP dostane přímo technologicky jiný identifikátor. Viz čtvrdý zýkon identity - directed identities).

Další problém tvého řešení je, že IdP je z principu vždycky Auditing IdP, neumožňuje implementovat Nonauditing IdP. Jinými slovy, můj identity provider ví, kam všude se s ním přihlašuju (protože je tady přímá komunikace mezi ním a SP). Což pro tyhle jednoduché věci taky není dobře.

Další problém je v omezení volby IdP. Protože celá tahle záležitost není claim-based, mohu z pozice SP omezit přijímané IdP jenom na základě jejich doménového jména. Nemohu říct "beru jakéhokoliv providera, který mi sdělí tenhle claim".

Prostě mi přijde, že tvůj systém nenabízí oproti existujícím nic nového, kromě (možné) technologické jednoduchosti, ovšem výměnou za podporu jenom jediného scénáře.

bredy 23.7.2010 01:14  7353
Z jakého důvodu jsi pro porovnání zvolil zrovna ten v podstatě nejsložitější profil
No ten jednodychý mi přišel velmi nebezpečný. Už proto, že tam chybí ta přímá komunikace a je třeba se spoléhat na kanál přes UA. Jistě, pokud ty data zašifruju, tak to přenést mohu... ale už to je složité, protože se obě strany musí domluvit na šifře a to se může těžko dělat v případě, že se šifry časem mění a stárnou. A sami víme, jak flexibilní jsou právě drobní SP.
bredy 23.7.2010 01:12  7352
RiderPřímá komunikace mezi SP a IdP je tam právě proto, aby se ověřil relativně nezabezpečený kanal SP->UA->IdP. Protože právě tam může sedět muž mezi. Zabezpečení dodatečným kanálem je právě ta krása v jednoduchosti... konečně, dneska se to běžně používá u bank, kdy validačním kanálem je třeba SMSka. (PS: ty zákony jsem tak nějak prošel, ale raději, když mi přímo ukážeš, ve kterém zákoně se to píše)

Komunikace mezi SP->IdP může být samozřejmě podle potřeby šifrována, o použití šifrování rozhoduje IdP na základě svých možností, které umí implementovat. Stejně tak může být zabezpečený kanál mezi UA a IdP.

Ochrana proti phishingu na Webu tařka neexistuje, protože jakákoliv služba tě nakonec může redirectnout někam, kde to vypadá podobně, jak tam, kde jsi zvyklý, ale je to jen podvrh. Jedinou ochranou jsou ony známé prvky v prohlížeči, jako jinak podbarvený URL řádek, zvýraznění adresy atd, případně nějaké blacklisty, které obsahují seznamy podvodných stránek. Nejlepší ochranou je pak lokální klient, kalkulačka, nebo další kanál, třeba ta SMS.

Jistě, heslo tuhle nevýhodu nemá, ale uživatel z lenosti zadává všude stejné heslo, pak je otázkou, kde je větší nebezpečí.

Oproti OpenID by měla být výhoda ta, že je mnohem jednodušeji řešení, nevyžaduje žádné další zabezpečovací prvky (kromě standardních, běžných na každým apachovi), z hlediska klienta (SP) je snadno nasaditelný a umožňuje přihlášení bez nutnosti sdělit SP své plné ID, "slepé přihlášení" @domena.cz, kde plné prozrazení svého ID provedeš až na IdP a SP obrží pouze jakýsi jednoznačný identifikátor tebou vybraného profilu (nikoliv Tvé ID).
rider Rider - Asociace chovatelů antropomorfních koní 23.7.2010 00:20  7351
Z jakého důvodu jsi pro porovnání zvolil zrovna ten v podstatě nejsložitější profil (Artifact Resolution na stranách IdP i SP)? Nepřipadá mi, že by tvůj protokol řešil to, proč tam artifact resolution je.

Myslím si, že tvůj protokol se víc blíží jinému profilu, a to Web Browser SSO. Ten má ovšem proti tvému jednu základní výhodu, a to že odpadá přímá komunikace mezi SP a IdP (proč je to dobře se dočteš třeba v těch zákonech identity).

Přijde mi, že jsi v podstatě ze SAML vykostil věci, které ti přijdou pro tvůj konkrétní scénář zbytečné. Což je nepochybně možné, protože SAML narozdíl od tebe představuje univerzální formát pro zcela jakékoliv použití.

Zásadní nevýhodou tvého systému (stejně jako OpenID) v mých očích je, že neřeší problém phishingu a v důsledku toho podvrženého identity providera. Což ovšem ze všech dostupných řešení pokud je mi známo řeší jenom Information Card, protože není čistě browser-based (což s sebou nese zase další záludnosti).

Jinými slovy: přijde mi, že tvoje řešení je jenom jinou implementací toho, co tady už je. Možná je jednodušší, nicméně nemyslím si, že komplikovanost implementace na straně SP/IdP je důvodem, proč se tyto systémy dosud nerozšířily.

bredy 22.7.2010 22:50  7350
hmm koukám, že oni radši místo IP používají IdP
bredy 22.7.2010 22:48  7349
Tajemství šefkuchaře

Rozdíl oproti obrázku u SAML2 jsou některé šipky obráceně.

Právě směr těch šipek je důležitý, i když je to pro někoho detail. Ale není. Stějně tak špatné rozmístění jednosměrek v městě znamená, že jednou projedete rychle a podruhé budete bloudit.

Ten rozdíl je v tom, že zatímco u SAML jsou role rozdány spíš tak, že IP má větší pravdu, než SP, tudíž. IP se chová jako klient, zatímco SP se chová jako server, u mě je to přesně naopak. SP je v tomto případě klient a IP server.

SP důvěřuje hlavně sobě, on zodpovídá za bezpečnost svých dat. Tedy on ověřuje, zda uživatel zadal doménu, která někomu patří, provádí discovery a následně oslovuje server IP, aby s ním vyjednal relaci. K tomu vygeneruje náhodné ID "salt", jenž pak slouží k ověření relace.

IP naopak prostřednictvím SP pouze navede uživatele k přihlášení. To se vykoná na IP server a po autentifikaci se předává na SP ticket, který identifikuje ověřenou relaci. SP tím dostává informaci, že IP uživatele ověřil, ale protože ticket prošel zkrz UA, a tento kanál není důvěryhodný, musí ticket ověřit. A aby nedošlo ani k pozměnení ticketu, treba na straně UA (paralelně provedené přihlášení na jiný účet), k ověření ticketu musí SP dodat ještě ono náhodné 'salt'. IP většinou ze saltu, adresy SP a nějakého dalšího saltu na straně IP vypočítá hash, které se následně porovnávají.

Je to primitivní, protokol má vlastně jen tří příkazy. "probe","login","validate". Vše se předává přes application/x-www-form-urlencoded, příkazy většinou v GETu a odpovědi v těle dokumentu. GET požadavky posílá SP, v PHP na to stačí obyčejné fopen. Na sestavení odpovědi na straně serveru stačí http_build_query, případě parse_str().

Zkuste mi někdo najít slabé místo. Podotýkám, že návrhy typu podvodný IP, zkompromitovaný SP, případně malvare na UA jsem už testoval. U rozhodování o tom, co je a co není bezpečné je třeba vzít v úvahu uživatele. Ten si sám zvolil IP, takže je garantem jeho důvěryhodnosti. Šipka v bodě 3 směrem od SP k IP je důležitá v tom, že je to SP, který si vybere, kam pošle požadavek, nikoliv IP. To obrácené řešní totiž znamená, že SP musí IP nějak ověřit, a tam už má jen jeho IP adresu a zbytek musí dohánět různými variantami elektronického podpisu.

Samotný protokol by bylo možné rozšířit, ale časem.
bredy 22.7.2010 20:58  7348
vitsoftJo to není problém, akorát pokud mám stránky rozjet jako demonstrativní provider, tak musím zakázat přístup do uživatelské sekce, kde jsou hesla(byť zahashované) a jiné informace.

Jinak něco podobného jsem měl taky, dokonce to barvilo syntax
vitsoft vitsoft Pryč se zrůdnou obrazotvorností mládeže! - about.me 22.7.2010 19:35  7347
Bredy [7343]: Já jsem před šesti lety dělal na firemním intranetu něco podobného, založeného na principu Shibboleth, a abych získal důvěru uživatelů, poskytuju nejen zdrojáky, ale jedním skriptem (viewfile.php) dovoluji prohlížet všechny ostatní skripty i samotný viewfile.php v reálném čase.
bredy 21.7.2010 06:31  7346
RiderCo je na tom obrázku špatně a proč to podle mne odsuzuje technologii k zániku...?
bredy 21.7.2010 06:18  7345
Rider ověřAle tady na te technologii je naprosto jedno, jakým způsobem se provede ověření. Důležité je, že ověření se provádí pomocí technologie poskytovatele. O nic víc. OpenID má za úkol pouze definovat jednoznacne ID a z toho ID umět odvodit adresu poskytovatele a toho oslovit. Cokoliv technologicky či HW překomplikovaného za tím už dotyčný systém nezajímá.

Dál nechápu, proč spojovat technologie pro přihlašování přes prostředníka do další technologie přihlašování. A zas tam bude nějaký jednotný protokol, zase tam bude někdo, kdo řekne "takhåe to bude". A kde beres jistotu, ze se neobjevi subjekt C, ktery prijde s jinym protokolem a subjekt D, ktery ty protokoly spoji do dalsiho jednotneho protokolu. Haluz...

Vrátil bych se ale zpět na Web, protože o ten jde především. V současné době je nejoblíbenějším přihlašováním jméno a heslo, případně e-mail a heslo. Dalším na řadě jsou proprietální systémy velkých portálů, ať jde o microsoft passport, facebook login, asi tě nepřekvapí, že existuje i Seznam login (http://login.szn.cz) a že napsat klienta pro Seznam login není problém, jediný, kam se nedostaneš jsou zatím osobní údaje, ale na ověřování se to docela hodí (dostaneš, ale není to zdarma, ale pokud jsi partnerem Seznamu, máš přístup k celému jednotnému přihlašování). Ale Seznam podporuje i OpenID, takže není potřeba. No a posledním způsobem je OpenID. Dál nic, snad jen vystupování anonymě. Jako identifikaci s oblibou na anonymních forech pouzivam své openid, ale to je samozřejmě neověřené.

To, že je něco někam vestavěné neznamená, že to automaticky úspěšné. Takových systémů už bylo.

Já jsem se podíval na SAML a nevím, je to prošpikovaný komplikovaným ukecaným XML protokolem (XML je zhouba), a spoustou nějakých klíčů a hashů. Snad ve snaze o superbezpečnost??? V současném systému je stále nejsilnějším prostředkem ochrany heslo a to je tak bezpečné, jak dobrou má uživatel paměť, případně jak moc má počítač zabezpečený proti keyloggeru, a případně, jak zabezpečená služba je, kam se přihlašuje. U přihlášení přes prostředníka je situace lepší, protože zabezpečený musí být jen prostředník. A navíc umožňuje uživatel použít jiné způsoby zabezpečení (třeba certifikát, kartu) aniž by to cílová služba musela implementovat a vůbec měla potřebu o tom vědět. Tohle zvládne i debilní OpenID. Na co tedy SAML?

[ 4074 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt