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

Lopuch, server nejen
pro botaniky

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: muvdgrb
[ 4075 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
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?
rider Rider - Asociace chovatelů antropomorfních koní 20.7.2010 22:08  7344
Aha. Takže ty ten hlavní proud sice neznáš a nemáš čas ho studovat, ale jsi přesvědčen, že jde špatným směrem. Zajímavé.

Jde o to, že Laws of identity vznikly např. jako reakce na zbastlené OpenID - nijak nepolemizuju, že je hrozné. Podle mého názoru je lepší a bezpečnější třeba logika information cards, která má ovšem nevýhodu v malé portabilitě.

SAML a technlogie na něj navázané jsou způsobem, jak všechny tyhle technologie (OpenID, InfoCard, NTLM, třeba i tu tvoji) nějak rozumně propojit. Protože pro mne je třeba výrazně snazší použít podporu SAML vestavěnou v .NET Frameworku, resp. WIF, než bastlit nějaký jiný systém, byť jednoduchý.

bredy 20.7.2010 20:06  7343
RiderTo je všechno hezký, ale já si právě myslím, že to je špatná cesta. Nemyslím si, že je vhodné se zapojovat do hlavního proudu, když ten proud ještě vlastně není vidět a když si myslím, že jde špatným směrem. V současné době je vidět akorát OpenID a jeho přeteoretizovaná snaha nabídnout komplexní řešení. A teď tu je další teoretik, kteří přichází z dalším teoretickým cvičením.

A přitom si myslím, že RP a zejména EU přijmou jednoduché řešení snáze, než nějaké komplikované, superbezpečné a komplexní řešení. Konečně, výsledek OpenID je tristní. Dodnes si nemohu v Alze nakoupit bez nutnosti se registrovat. Máme víc providerů než subjektů. Velcí provideři nemají problém najít nějakou manhodinu na to, aby doimplementovali do svého autentifikačního systému OpenID. Nedělá to problém ani Seznamu, konečně, můžu se kdykoliv podívat do zdrojáků. Problém je se subjekty, kteří jsou buď odkázáni na hotové balíky, které jsou kolikrát komplikovatelně nasaditelné a jsou zbytečně velké. K čemu mi je klient OpenID který má 7MB když webovka má s bídou 1MB? Další možností je svěřit osud do rukou nadšenců a jejich udělátek, jejichž spolehlivost je přitom nejistá. Například já mám stažený jeden skript, který dělá OpenID u Seznamu a u MyOpenID ale třeba u Google vyžaduje menší úpravu a na mojeid.cz mě to vykopne s tím, že nepodporuju plně verzi 2.0. Zkus si přečíst specifikaci OpenID 2.0 a budeš naříkat. Vlastní implementace celkem padá...

A přitom je celý systém velice primitivní, založený na jednoduché myšlence svědka, kterého lze ověřit a který přebírá autentizaci uživatel. A pokud mu věří uživatel, není problém, aby mu věřil i subjekt, protože díky ověření prostředníka ochrání uživatele mající jiné prostředníky před podvodníkem.

Celý koncept OpenID (nevím zda se to týká i těch zákonů) má zároveň významnou skupinu uživatelů, kteří z nějakého důvodu nechtějí tento způsob identifikace používat. Důvodem je nikoliv nedůvěra v prostředníka, ale jednoznačná identifikace u subjektu, kterému nemohou nebo nechtějí poskytovat své osobní údaje. A tohle OpenID nevyřeší, ale snažím se to řešit já.

Netvrdím, že je to geniální systém. Napíšu technologické demo, zveřejním ho v české a anglické verzi a pokusím se pro projekt získat podporu komunity. Zkusím přesvědčit i lidi ze Seznamu, zda by mi neudělali providera. Stáhnu si i ten 7MB balíček pro OpenID a zřídím OpenID proxy, takže můj systém bude umět i OpenID se stejně složitým kódem. Tím bych přesvědčil zejména EU k implementaci této technologie do svých systémů, protože budou mít jistotu, že když nic, tak aspoň uživatele s OpenID budou moci systém používat.

Víc udělat nemohu a ani nechci. Buď se to uchytí, nebo ne.
rider Rider - Asociace chovatelů antropomorfních koní 20.7.2010 12:08  7342
Nevím co se myslí těmy zákony identity. Nechci to studovat, je to dlouhý a nemám na to čas.
Snažíš se se svým projektem zapojit do oboru, který je docela slušně rozjetý. Podobných systémů je spousta, že (patrně) znáš jenom OpenID ještě neznamená, že je jediný. The Laws of Identity je zásadní teoretický dokument, který se snaží definovat problémy, které současné veřejné identifikační a autentizační systémy mají a definuje sedm "zákonů", o kterých si autor (Kim Cameron) myslí, že by měl každý takový systém dodržovat, aby se jim vyhnul. Tenhle dokument jistě není svatý a lze s ním polemizovat. Ale odmítnout ho studovat s tím, že na něj nemáš čas? To je velmi zvláštní.

Budí to ve mně dojem, že pod dojmem OpenID (které je dost hrozné, pravda), jsi vymyslel nějaké řešení, o kterém si myslíš, že je geniální, ovšem aniž bys věděl něco o současné situaci v oboru. Skutečně nelze vyloučit možnost, že jsi z jedné vody načisto vymyslel geniální postup, aniž bys předtím věděl něco o oboru, do kterého jsi vlezl, ale nepokládám ji za příliš pravděpodobnou.

Mimochodem: zákony identity a systémy na nich založené řeší i problémy, které zmiňuješ. O důvod víc, proč se zajímat o to, co dělají jiní.

Druhý a možná ještě podstatnější důvod je, že není zase až tak obtížné vymyslet autentizační protkol (např.), ale je obtížné přimět RP (relying party) a EU (end user, subject), aby to používali, protože jim to něco nového přinese. Už jenom z tohoto důvodu mi přijde rozumné nezačínat s jiným systémem od nuly, ale třeba se zapojit do vývoje jiného systému, který má větší šanci na úspěch.

bredy 19.7.2010 21:07  7341
RiderHele, ty zákony identity, to je nějaké nařízení Evropské unie?

Já nevím jestli chápeš o co jde. Nejde o žádný nový protokol, jde jen o jednodušší řešení OpenID. Jde jen o možnost delegovat ověření identity na prostředníka, kterému věří uživatel.

Běžný postup je ten, že uživatel zadá jméno a heslo. Jménem říká "kdo je" a heslem říká "tady máš důkaz". Pokud použiju přihlášení přes prostředníka, říkám "kdo jsem" a zároveň říkám službe, koho se má zeptat, aby došlo k ověření. Zároveň uživatel svěřuje proces ověření právě prostředníkovi. Je motivací uživatele vybrat si důvěryhodného prostředníka. Nedá se to ani nijak moc podvrhnout, třeba že si napíšu vlastního prostředníka, který ověření neprovede. Můj prostředník má totiž jednoznačné jméno, a to jméno domény, které jsem si musel zakoupit. Nemohu nikomu nastrčit falešného prostředníka, který ověření neprovede. Už proto, že webová služba se neptá zkrze uživatele, který může mít kompromitované spojení, ale přímo se dotáže toho prostředníka (resolving si udělá sám přes DNS, to už je dnes dostatečně autoritativní služba, nefiguruje tam žádná proxy). Zkrze uživatelské spojení se posílají pouze nějaké hashe, které uživateli i "člověku mezi" jsou k ničemu.

Nevím co se myslí těmy zákony identity. Nechci to studovat, je to dlouhý a nemám na to čas. Jestli existují nějaké zákony na sledování identit, či co... klidne mi to přibliž, jak to funguje.

Ale za sebe se snažím řešit dva protichůdné problémy. Jeden problém je, že určitá skupina uživatelů si ráda pěstuje svůj profil a na každém webu se vyskytuje pod stejným ID (a běda, pokud je to ID obsazené). Té se tohle náramě hodi. Druhá skupina chce spíš utajit to, že navštěvuje různé weby, nicméně nechce těm webům dávat svá hesla. Těm se také hodí mít centrální login. Ale tohle OpenID už nenabízí (nabízí to můj systém).

Není účelem služby lámat se do bankovních systémů, ani do vládních, či jiných služeb. Cílovka této technologie jsou diskuzáky, blogy, portály, sociální sítě, víceméně webově zaměřené.

huh
Až to dodělám, můžete přesvědčit místní správce, aby fungovali jako provideři. Pak můžeš svůj login do lopuchu použít na jiné weby, které budou technologii implementovat. A nebo naopak, můžeš zařídit, aby ses do lopuchu přihlašoval třeba e-mailem do seznamu, pokud se implementuje klientská část. Já ještě plánuju udělat proxy na OpenID, takže by nemělo být těžký se přihlásit i prostřednictvím OpenID tam, kde bude implementovan klient mého protokolu. Prostě budu mít veřejnou proxy, která bude požadavky převádět na OpenID požadavky.
huh huh 19.7.2010 15:00  7340
Mě by se líbilo ověřovat uživatele oproti lopuchu, nemusel bych je do tipovačky přidávat ručně :-)
rider Rider - Asociace chovatelů antropomorfních koní 19.7.2010 14:42  7339
Hm. Téhle odpovědi jsem se bál. Je to jako když někdo tvrdí, že vymyslel perpetuum mobile a pak se zeptá "co myslíš prvním zákonem termodynamiky?".

The Laws of Identity

Jinak si myslím, že pokud něco současné IT nepotřebuje, tak je to ještě další přihlašovací protokol. Není nijak těžké je vymyslet, je těžké je prosadit, protože jejich uživatelé (jak RP tak EU) v nich zpravidla nevidí hodnotu.

Jde taky o to, jestli ti jde jenom o identifikaci, nebo i autentizaci a další...

bredy 19.7.2010 06:11  7338
RiderSe SAML to nemá nic společného, alespoň co do složitosti. Ani vlastně nevím, k čemu SAML je (koukám na wikipedi, a vypadá to šíleně). Ale máš pravdu, že nic nevymýšlím, inspirací je jednoznačně OpenID. Jenže by to mělo být jednodušší jak na implementaci do webovky, tak na implementaci providera. Protože účelem není nic jiného, než umožit uživateli identifikovat se na službě přes prostředníka. Žádná další security tam není potřeba, protože zodpovědnost je rozložena mezi webovku, providera, a uživatele. Jediný, proti čemu je třeba se chránit je proti ManInMiddle (většinou u uživatele) a proti phishingu, ale to je věcí uživatele. Webovka musí věřit uživateli, že má důvěryhodného providera. Což je na stejné úrovni, jako když věří uživateli, že se jmenuje "franta" a má heslo "opice". Případně je tu ještě možnost filtrace providerů a blokování těch, které nejsou považovány za důvěryhodné.

Co myslíš zákony identity?

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

(c) 2001-2011 Lopuch.cz   
Kontakt