Cutting the Gordian Knot of Web Identity
Ötlet autentikációs protokollra
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
Bártházi András:
Perl alapjai VIII. - Könyvtárműveletek
macat:
A NoSQL világa – 1. rész: Bevezető
Hojtsy Gábor:
Két éves a PHPinfo - interjú a készítőkkel
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 28 | 29 | 30 | 31 | 1 | 2 | 3 |
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 1 |
Böngésző a szerveren
Gratulálok, feltaláltad a
vicc?
Pl. az X szerverek pontosan
Amit felvázoltál, az kb. egyenlő ezzel.
Másik verzió, hogy valóban nem értelek.
a lényeg
A cikk egy megoldást próbált nyújtani arra, hogy csak 1 azonosítás legyen, de mégis megmaradt, hogy chapta-t kell használni.
Az ötletem nem az volt, hogy használjunk terminált, vagy X szervert vagy ilyesmit (önmagában ez nem nyújt megoldást), hanem az, hogy legyen az eljárás része az, hogy a böngésző is (megbízható, hitelesített) szerveren van.
Ez több előnnyel is jár (a nyilvánvaló hátrányok mellett), de konkrétan a megmaradt 1 problémára megoldást nyújt:
A weboldalak biztosak lehetnek benne, hogy nem hekkelt böngészővel jössz, így tuti hogy te vagy az (nem gép). Mivel képek jönnek, ezért ez már eleve chapta (és ez utóbbi az ötlet lényege).
Vagyis a nap elején bejelentkezel, a böngésző a szerveren azonosított, és mindenki akit ezen keresztül látogatsz, bízhat a protokollban, hogy te vagy az (az azonosítási adatok sem a te gépeden tárolódnak, hanem egy megbízható szerveren)
Ezt nyilván tovább lehetne gondolni, és egyéb előnyei is vannak (pl. nem tudnak a böngészőn keresztül a gépedre jutni hackerek stb). Nyilván egy csomó technikai probléma is felmerül és nem reális technológia (manapság még nem) ez csak egy ötlet volt tőlem, semmi több.
(Magamban egyébként továbbgondoltam és a jövőben lehet realitása a dolognak: ellentétben a hasonló technológiájú játékszerverekkel ez esetben a weboldalak, az igazi külvilág felé normál adatforgalom menne, a képformában történő adatátvitel csak a közeli "böngésző szerverig" kell hogy eljusson. Ez akár lehetne az ISP is.)
Mivel képek jönnek, ezért ez
(Persze úgy is megoldható, hogy a szerver satírozandó koordinátákat küld vissza, de így kliens csak végigkérdi az ábécét, feljegyzi a koordinátákat és összeolvassa a szöveget. Még OCR sem kellene és máris ugrott a képpé alakítás értelme.)
Ez már megoldott
Nyilván egy idő múlva a képi átvitel már semmiképp nem lesz elegendő arra, hogy megkülönböztessük a gépet az embertől... Túl okosak lesznek a gépek...
Amelyik weboldalnak ez nem elég, annak egyedi chapta-t kell kitalálnia, ez nem kétséges.
(Mondjuk ez visszafelé is működhet: el tudom képzelni, hogy egy browserszerverre tesznek egy olyan figyelőalgoritmust, ami megtippeli, hogy a felhasználó gép-e -- a viselkedése alapján. Ha gyanús, akkor kitesz egy bonyolultabb chaptát. Az eredmény az lenne, hogy mégsem kell a weboldalaknak azzal foglalkozni, hogy vajon te gép vagy-e, mert ezt is garantálhatná a browserszerver)
De más járulékos előnye is van a browserszervernek, ha most el kéne adnom az ötletemet, biztosan tudnék még néhány érvet ;-)
ne haragudj, de mivel ugy
miert lenne jo ez a felhasznaloknak? azt ertem, hogy miert lenne jo a nemzetbiztonsagnak, vagy a tartalomszolgaltatoknak, de mitol kezdenek el hasznalni a felhasznalok?
az sem vilagos, hogy mit ertesz ez alatt: "hanem az, hogy legyen az eljárás része az, hogy a böngésző is (megbízható, hitelesített) szerveren van".
ki minositene, vagy mitol lenne ez megbizhato?
ha a user fennhatosaga ala tartozik ez a szerver, akkor nyilvan a weblapok nem bizhatnak meg abban, hogy az akinek mondja magat (ergo kell valami azonositas, session, etc.), ha a szolgaltato(ezt valoszinusitem a leirasodbol), akkor az osszes website-nak meg kell biznia a szolgaltatoban, hogy meg tudja kulonboztetni a sajat usereit, plusz ha ellopjak/lehallgatjak/feltorik a szolgaltatodnal hasznalt browser accountodat, vagy csak leul valaki a geped ele, akkor buktad a teljes netes identedet.
alapvetoen mind a cikkben, mint az itt felvazol javaslat az oAuth kornyeken kaparaszik, csak te kevertel bele nemi vekonyklienst.
ahogy irtam a felhasznalok elbuknanak egy csomo feature-t (ha minden kepkent megy, akkor ilyenek mint felolvaso program, kereses, szoveg kijelolese, billentyuzet gyorsgombok, etc. mind mehetnek a levesbe), plusz kenyszeritve lenne a felhasznalo hogy a tobb kulonbozo account helyet egyet hasznaljon (ha valahogy megszerzik a fiokod, akkor mindenhez hozzafernek a nevedben), a privacy megszunne letezni mint fogalom (jelenleg tudok/tudnek ugy bongeszni/levelezni, etc hogy rajtam, es a tartalomszolgaltaton kivul senki nem tudja megmondani, hogy mit forgalmaztam, ezt az ablakozos modszerrel nem tudnad megtenni).
a robotokat amugy nem tudna kiszurni a megoldas, hiszen bar kenyelmesebb html formokat kuldozgetni scriptbol, de ha szukseges, akkor ugyanugy scriptelheto az egermozgas/kattintas is.
Tyrael
Köszi a javítást
- A felhasználónak azért lenne jó mert ez egy olyan SSO mint ami a cikkben le van írva de captcha sem kell
- Nem tudom hogy ki minősítene, de lenne egy minőségbiztosítási rendszere a dolognak, amiben mindenki megbízik, hasonlóan az SSL tanúsítványok kezeléséhez. Igen, a szolgáltatónál lenne a browser nyilván (lehetne a felhasználónál is, ha vállalja a követelményeket, de nyilván nem fogja) Nem kínálok megoldást erre a kérdésre, csak feltételezem, hogy megoldható.
- "vagy csak leul valaki a geped ele, akkor buktad a teljes netes identedet." a browserszerverbe be kell jelentkezni egyszer. Aztán neked kell vigyáznod hogy ne hagyd úgy a gépet.
- Más SSO rendszernél is elbukod ugyanígy az összes accountodat, ha a gépeden tartod, az sem biztos hogy jobb, de ez most nem is téma. Annyiban viszont biztosan jobb, hogy egyrészt mivel csak a browserszerveren keresztül lehet a lopott accounttal ténykedni, utólag jobban lekövethető hogy a tolvaj mit csinált és hamarabb megtalálható, valamint mivel (a cikk alapján) a protokoll része, hogy véletlenszerű jelszavakkal regisztrálsz az egy kalapba vett accountjaiddal, te magad sem tudod, hogy mik ezek a jelszavak és a böngészőszerver sem adja ki, ezért elegendő a főjelszót megújítani a betörés után. Vagy legalábbis erre is lehet egy eljárást kidolgozni.
- A felhasználók nem buknak el semmit, mert ha nem felel meg nekik, nem használják, nem kötelező, a cikkből úgy értelmeztem hogy ez egy olyan protokoll, ami akkor lép életbe ha mindkét fél felkészült rá. Egyébként marad az egyedi regisztráció és bejelentkezés.
- Jelenleg is csak azért gondolod, hogy tudsz úgy böngészni "hogy rajtam, es a tartalomszolgaltaton kivul senki nem tudja megmondani, hogy mit forgalmaztam" mert megbízol az ISP-ben és az SSL hitelesítésben. Nyilván nem kötelező a böngészőszerveren keresztül bankolnod, ez arra alternatíva, ha Faház Fórumozol meg Kiskutya Neveldézel.
- A robotok kiszűrésére ennek a segítségével nyílhatna új technológia: mivel eddig nem lett volna értelme ilyet beépíteni a böngészőbe, a böngészőszerverbe nyilván érdemes lehet okos figyelőalgoritmusokat tenni, amik képesek lennének detektálni ha valamilyen tevékenység robotnak tűnik, vagy captchafeltörés történt. Ha a browserszerverek egymást tájékoztatják, hatékonyabban léphetnek fel ez ellen is.
"minőségbiztosítási rendszere
ez epp most latszik osszedolni.
"- Más SSO rendszernél is elbukod ugyanígy az összes accountodat, ha a gépeden tartod, az sem biztos hogy jobb, de ez most nem is téma."
ott megvan a lehetosegem, hogy minden oldalra kulon accountot hasznaljak.
"Annyiban viszont biztosan jobb, hogy egyrészt mivel csak a browserszerveren keresztül lehet a lopott accounttal ténykedni"
azt irtad, hogy a browserszerver mogott ugyanugy http lenne, szoval ha a rosszfiuk tudnad direkt hozzaferest szerezni, akkor elmeletileg a browserszerver megkerulheto lenne.
ott van meg tovabba a problema, hogy mi tortenik, ha egy browserszerver megszunik/kompromittalodik.
az architechturatol fuggoen ez vagy azt jelenti, hogy minden altala kezelt felhasznalo hozzaferese megszunik, kompromitalodik, vagy amennyiben igy lett kialakitva a rendszer, hogy nincs lehetoseg a trusted browser szerver allitasat ellenorizni a tartalomszolgaltatonal, akkor gyakorlatilag 1 browser szerver kompromittasa utan barkinek az identitasat fel tudja venni a tamado (hasonloan ahhoz, ahogy most egy CA kompromittalodasa utan barmelyik domainhez ki tud allitani a tamado valid certet).
"utólag jobban lekövethető hogy a tolvaj mit csinált és hamarabb megtalálható, valamint mivel (a cikk alapján) a protokoll része, hogy véletlenszerű jelszavakkal regisztrálsz az egy kalapba vett accountjaiddal, te magad sem tudod, hogy mik ezek a jelszavak és a böngészőszerver sem adja ki, ezért elegendő a főjelszót megújítani a betörés után. Vagy legalábbis erre is lehet egy eljárást kidolgozni."
ott megvan"
szoval ezek a random jelszavak lennenek hasznalva a browserszerver es a content szerver kozti authentikaciora.
ez eddig nem volt teljesen vilagos (meg a fenti bekezdest sem ennek a fenyeben irtam).
nyilvan a browserszerver kompromittalodasa eseten minden jelszot le kellene cserelni, nem csak a master jelszot, hiszen a tamado megszerezhette az egyes jelszavakat, es megszemelyesitheto az osszes site fele a usert ezekkel.
" Jelenleg is csak azért gondolod, hogy tudsz úgy böngészni "hogy rajtam, es a tartalomszolgaltaton kivul senki nem tudja megmondani, hogy mit forgalmaztam" mert megbízol az ISP-ben és az SSL hitelesítésben."
az ISP-ben nem kell megbizzak, csak az SSL hitelesitesben, mivel az ssl tunnelen forgalmazott informaciot csak a ket vegponton lehet elolvasni(az en gepemen, es a tartalomszolgaltato szerveren).
"A robotok kiszűrésére ennek a segítségével nyílhatna új technológia"
sajnos konkretumok nelkul (amiket nagyvonaluan atugrasz egy "szerintem megoldhato" kijelentessel) nem latom, hogy hogyan adna ez uj, vagy jobb eszkozoket a robotok szuresere, plane egy olyan vilagban, ahol az ilyen akadalyokat mar most is emberi eroforras felhasznalasaval abszolvaljak a csunya emberek.
Tyrael
Dőljön
Oldják meg azt is, hogy mi legyen akkor, ha kompromittálódik egy szerver. Állítsanak fel magasabb biztonsági követelményeket.
Most is történhet ilyen, pl. a Sony feltörésével sok bankkártyaadat jutott ki. Az SSO-t arra használd, amire kényelmes és megéri, Kutya Neveldére, bankkártya nélkül. Olyan dolgokat hozol fel, amik sokkal súlyosabb problémákat okozhatnak mint a felhasználók Kutyaneveldéjének feltörése. Olyan problémákat említesz, ami az ötletemtől függetlenül léteznek.
A cikk alapján leírt ötletet egészítettem ki azzal, hogy megoldaná a cikkíró megmaradt problémáját, ha a browser egy hiteles szerveren lenne. Aztán továbbgondoltam és még mindig úgy gondolom, hogy ez egy jó ötlet. (De semmi más. Nyilván nem fog megvalósulni. Már eleget írogattam ezzel kapcsolatban, többet már nem akarok írogatni, értelmetlen. Elment a kedvem, valahogy nem értetek meg, nem olvastok vissza vagy nem tudom miért. Most még megpróbálok válaszolni a kérdéseidre hogy megértsd, hogy mit írtam, de nem akarok vitatkozni hogy ezt tényleg érdemes-e megvalósítani vagy sem, értelmetlen. Legalább valaki írhatta volna, hogy "érdekes ötlet" de semmi ilyesmi nem történt, legközelebb jobban meggondolom hogy postoljam-e, ha támad egy ötletem.)
"szoval ezek a random jelszavak lennenek hasznalva a browserszerver es a content szerver kozti authentikaciora" igen, ha jól olvastam ilyesmi van a cikkben.
"nyilvan a browserszerver kompromittalodasa eseten minden jelszot le kellene cserelni, nem csak a master jelszot, hiszen a tamado megszerezhette az egyes jelszavakat, es megszemelyesitheto az osszes site fele a usert ezekkel."
Nem akarok most az SSO ellen vagy mellett állástfoglalni, de a user gépén sincs nagyobb biztonságban a jelszóhalmaz, tekintve a userek tömkelegét, akiknek zombi a gépe. El tudom képzelni hogy egy browserszerveres megoldás profibban lenne képes reagálni a behatolásveszélyekre. De lehet hogy nem. Ez most független az ötletemtől.
Lehet, hogy meggátolható hogy megszemélyesíthető legyen a az összes site felé a user hosszú távon a lopott jelszóval, talán meg lehet oldani úgy is a protokollt, hogy a jelszó csak az egyik eleme legyen a védelemnek, mondjuk csak bizonyos szerver felől legyen érvényes.
Ha meg mégis le kell cserélni a (véletlenszerűen generált) jelszavakat, az sem olyan nagy baj, hiszen ez is automatizálható (sőt az időnkénti csere lehet a protokoll része egyébként is)
Ezek nyilván problémás kérdések, de csak érintőlegesek az ötletemmel kapcsolatban.
"az ISP-ben nem kell megbizzak" nyilván sokan vannak akik megbíznak, itt nem csak rólad van szó. A legtöbb oldallal, a Kutyaneveldékkel, amikről most szó van, sima HTTP-vel játszanak az emberek, vagyis megbíznak az ISP-ben. Még egyszer: ez nem kötelező szolgáltatás, pusztán kényelmi. Bankolni nem muszáj ezen keresztül.
A robotok kiszűréstét, az emberekkel végzett tömeges regisztrációt ez a rendszer nagyszerűen képes lenne gátolni. Ha egy weboldal csak böngészőszerveren keresztül, a HTTPBSC protokollal engedne regisztrálni, akkor elég jól biztosítható lenne számára hogy igazi emberrel kommunikál.
Mondjuk az internet szolgáltató szerződést köt valakivel. Ez egy nagyobb cég, 1000 felhasználóval. Ez az 1000 felhasználó mind létrehozna összesen 1000 accountot az ISP browserszerverén. Így az 1000 felhasználó mindegyik csak 1 accountot tudna nyitni azon a weboldalon, ahol csak a browserszerveres regisztráció engedett.
Szerintem egyébként ezeket te is végig tudod gondolni, nem kellek hozzá ;-)
Jelszókezelő
Elbeszélünk egymás mellett:
Gyanítom, nem azért, mert a tudás vagy a szándék hiányzik.
Csak egy konkrét példa: próbálj ki egy X szervert ssh-n át mondjuk 100-150Mbps sávszél mellett! Még így is iszonyat lassú, nehézkes. Képzeld el, milyen lehetne mindez a jelenlegi interneten!
Arról nem beszélve, hogy miért lenne biztosíték a hackelés mentes böngészőre az, hogy egy megbízhatónak cimkézett szerver címéről jön?
És én nyugodtabb vagyok, ha nem egy (több) "nagytestvér" gépén tárolom a privát adataimat.
Nagytestvértől függetlenül én
A cikk szerint
Ráadásul az egyes weboldalak teljesen véletlenszerű jelszavakat (azonosítókat) kapnak, szóval nem tudnak meg semmi egyebet.
De aki hozzájut a böngésző
Ez így van
A lényeg, hogy van 1000 olyan, kisjeletőségű oldal, ahova regisztrációt kérnek a Kiskutya Neveldétől a Faház Fórumig, ezeket lenne jó megoldani valahogy úgy, hogy ne kelljen regisztrálgatni és bejelentkezgetni mindenhova -- a banki elérésedet meg a saját szervereid elérését persze nem kell erre bíznod, ezekre külön jelentkeznél be.
Egyébként ha valaki megszerzi ezt az egy jelszavadat, és ez kiderül, akkor csak 1 helyen kell módosítanod a jelszót, (erre kaphatnál egy másik lehetőséget a böngészőszervertől, mint a SIMkártyán a PUK-kód) mivel a többi jelszót te magad sem tudod és nem is fér hozzá senki.
(Sőt! Ha böngészőszerveren keresztül megy fel valaki más a netre a te jelszavaddal, akkor talán még könnyebb kinyomozni hogy ki lehetett az, mert logolva lenne az akció.)
Megoldásom nincs, de a
Az a véleményem, hogy ez a böngésző szerver egy olyan felesleges overhead lenne a hálózati kommunikációban, ami inkább több biztonsági kérdést vet fel, mint amennyit megold.
Persze lehet, hogy még mindig nem értem, hogyan képzeled ezt a böngésző szerver dolgot, és hogy hogyan tudna ez (jobban) gátat szabni bármilyen programozott támadásnak.
A képként küldöm ki a weboldalt a kliensnek meg ugye hozzáférhetőségi szempontból kifejezetten problémás lehet.
SSO
Miért pont a böngészőszerverben ne bíznának? Az ISP-ben megbíznak?
A kommersz weboldalakat a böngészőszerveren keresztül látogathatnák, és akkor tudnák, hogy azonosítva vannak, egyébként meg kijelentkeznének, vagy a saját gép böngészőjét használnák.
Megvan az előnye és a hátránya, kár erről most vitatkozni, a szempontjaiddal egyetértek, de itt most nem erről van szó. Ha nem tetszik, nem csinálod, senki sem kényszerít rá. Nyugodtan regisztrálj be egyenként azokra az oldalakra amikkel kommunikálsz, ha az téged nem zavar, hogy sok helyre kell regisztrálnod és bejelentkezned, akkor ez a téma számodra érdektelen.
A cikk sem kizárólagos protokollként gondolja ezt a megoldást, hanem kényelmi, kiegészítő szolgáltatásként. Nyilván a korlátozott felhasználók más utat választanak.
Sok biztonsági kérdést felvet, de sokat meg is old.
Lehet, hogy még mindig nem érted, hogy mire gondolok, de szerintem nem is érint téged ez a téma, mert úgyis tartózkodsz az SSO használatától, ezért felesleges lenne még egyszer megpróbálnom elmagyarázni, hogy miért tartom jó ötletnek, miért tartom elképzelhetőnek, hogy ez egy kényelmesebb, biztonságosabb megoldás lenne.
Még egy ötlet: az ISP-n működő böngészőszerver akár azt is megtehetné, hogy különböző weboldalakat külön IP címmel kér le neked. (Főleg ha már általános lesz az IPV6) Vagyis még a fordítottjára is használható lenne a technika: elrejthetné, hogy ki vagy, ha akarnád.
Az tényleg nem témaköre ennek
Viszont még mindig nem értem, hogy ez a böngészőszerver miben nyújtana többet annál felállásnál, amikor a böngészó jelszókezelője megfelelően titkosítva kiküldi a felhőbe a bejelentkezési adataimat, amiket aztán csakugyan bárhonnan elérhetek.
Eddig jutott el a cikk is.
(A többi pedig a járulékos haszon, amiket említettem: ha helyben vannak az adataid, akkor nem biztos, hogy jobb helyen van, mint egy megbízható szerveren, hiszen pl ha téged feltörnek, akkor az összes oldal jelszavához hozzáférhetnek; valamint bárhonnan elérheted a böngészőszervert, nem kell a jelszócsomagodat átszinkronizálnod a mobilodra vagy kézigépedre; ráadásul ha bizonyos oldalakat a szerveren keresztül látogatsz, és valaki illetéktelenül akarja használni, akkor lekövetheted a nyomát hogy mit tett -- nyilván vannak hátrányai is, én csak az előnyöket ecseteltem)
Hamisítani
Ok,
Ugyanúgy, ahogy a https-nél hitelesített szolgáltatók vannak, ugyanígy hitelesítve lennének a böngészőszerverek is. Most sem kételkedik senki sem a HTTPS tanúsítványban (kivéve, akinek az a dolga, hogy kételkedjen)
OK, feltörnék a chaptát, és akkor gyorsan rájönnének, globálisan alkalmazkodnának és a logok alapján törölnék a csaló felhasználókat és könnyebben jutnának el hozzájuk (az ISP tudja, hogy ki vagy, szerződtél vele). Ha a szerveren van a böngésző, akkor szigorúbb a rendszer. Ráadásul lehet hatékonyabbá tenni a chaptafeltörés észlelését is, pl. a böngészőszerverek gyorsan tájékoztathatnák egymást hogy hogy jártak. A böngészőkbe most nem lehet chaptafeltörést vizsgáló, gépuser lefülelő algoritmust tenni mert értelmetlen lenne. Ellenben ha ez a rendszer és a protokoll része lenne, akkor ez új eszközöket adna.
Attól hogy egy SSO van, nem feltétlenül egy chapta módszer kellene (a Facebook is használhatna ezerfajta chaptát egyszerre, nem is értem miért nem teszi). A weboldalaknak viszont ezzel már nem kéne foglalkozniuk.
hitelkartya csalasrol
ugyanugy szerzodni kell a bankkal, ugyanugy visszakovetheto (elmeletileg) hogy ki hasznalta, aztan megsem olyan egyszeru kiszorni a csalokat, mert a csalok nem a sajat vagy kamu nevre kiallitott kartyakat hasznalnak, hanem megveszik a feketepiacon (vagy beszerzik elsokezbol) a lopott kartyaadatokat, amivel aztan jol visszaelnek.
a captcha feltoreses reszt megint csak nem latom relevansnak itt (kicsit mintha vesszoparipad lenne, szerintem tul sokat feltetelezel rola), raadasul mar most is vannak olyan captcha szolgaltatok, amiket tulsagosan koltseges/eroforrasigenyes lenne gepi eszkozokkel torni, de erre nem az lett a valasz a rosszfiuk reszerol, hogy feladtak a kiserletezest, hanem az, hogy kiszerveztek indiaba/kinaba a captchak megfejteset fagyiert, meg csinaltak kamuporno oldalakat, ahol a latogatok kitoltogetik a captcha-t, hogy hozzaferjenek a contenthez, ami megfejtest a rosszfiuk visszakuldenek az eredeti szolgaltatonak.
nem tudod megmondani, hogy nem ember fejtette meg, mivel ember fejtette meg, vagy irhatnam azt is, hogy az ellen nem ved.
Tyrael
De véd
ok, tehat szerzek egy(tobb)
Tyrael
Igen, jól látod
(Minden egyes új accounthoz szerzel egy hajléktalant?)
Browser bevonása a protokollba
Az én ötletem az volt, hogy a böngészőt megbízható szerverre téve, beleillesztve az eljárásba (szabványosítani a folyamatot természetesen) egy új szintre emelhető az egész.
Ez akár egy teljesen új protokollal is mehetne (HTTPBSC néven mondjuk ;-)
A lényege, hogy a weboldalak kapnának egy szabványos lehetőséget (hasonlóan a cikkben leírtakhoz) hogy a most elterjedttől különböző módon (is) kapcsolódhassanak a látogatókhoz.
Mindegy, hogy ez X szerver, vagy akármi technológia módosításával történik-e. A lényeg, hogy biztosítva legyen a hiteles és biztonságos kapcsolat a weboldal és a browserszerver, valamint a browserszerver és a felhasználó közt.
Nem kétséges hogy ez nagy sávszélesség, de lényegesen kisebb forgalmi probléma, mint amit most próbálgatnak a játékok esetén (belinkeltem előbb egy cikket) hiszen a nagyobb sávszélesség csak az ISP-ig kellene hogy szükséges legyen. Ezt akár adhatná ingyen is az ISP: meghirdetné, hogy plusz szolgáltatásként támogatja a HTTPBSC protokollt, és mindenki rácuppanna, hogy húdejóóó.
Na szóval az egész csak képzelgés, nyilván a cikkben leírt protokoll sem fog megvalósulni, nemhogymég a browserszerver. De azért szerintem nem teljesen elrugaszkodott az ötletem, akár még ilyesmi is jöhetne.
https://browserid.org/
szerintem kulon-kulon mar
akar az openid/oAuth jellegu dolgokat nezzuk, akar a bongeszokben talalhato profil/jelszokezelot (ha jol emlekszem pl. Safari alapbol kitolti neked a szemelyes adataiddal a megfeleloen elnevezett/strukturalt formokat), akar a kliens tanusitvanyok hasznalatat.
szoval azzal egyetertek, hogy a jelszavak gyakori ujrahasznositasa miatt a minden oldalra kulon regisztralok egy fiokot nem tul szerencses, de azt sem biztos hogy jobb megoldas, ha mindent elmentunk 1 helyre (legyen az egy openid szolgaltato, vagy a browser jelszokezeloje) amit aztan ugyanaz az egy jelszo ved, amit amugy is mindenhol hasznal a user.
a jelszavakkal/certekkel alapvetoen az a problema, hogy nem tudod megmondani, hogy kompromittalodott-e, vagy sem, ezzel szemben pl. a tokenes megoldasoknal van egy fizikai eszkoz, amit jo esetben csak addig dugsz be a gepbe, amig szukseg van ra, nem lehet lemasolni(ergo csak fizikailag lehet ellopni, annak pedig nyoma van), es a token birtokaban egyertelmuen azonosithato a user.
Tyrael