Jelszó nélküli jövő: Épület a biztonságosabb és használhatóbb hitelesítési rendszerek felé

A jelszavak cseréje privát kulcsokkal könnyen érthető metaforában

Az EOSIO Labs ™ kezdeményezés bevezetésével nyíltan megkezdtük az innovációt az EOSIO-ra épülő blockchain technológiák jövője szempontjából. E kezdeményezés keretében kiadott első kiadásunk a Univerzális hitelesítő könyvtár (UAL) a magánkulcs-kezelés jövőjét és annak biztonsági és kulcskezelési vonatkozásait vizsgálja. A kiadás filozófiájának alapja egy nagyobb probléma feltárása, amelynek középpontjában az áll, hogy a jelszavakat és a hitelesítést hogyan hajtották végre az interneten, a blokkláncon vagy más módon. Noha ezt a hozzászólást nem kíséri szoftveres kiadás, a cikk célja a meglévő hitelesítési rendszereket sújtó problémák, valamint az ilyen problémákhoz kapcsolódó jelszavak meghaladásának modern kísérletei. Ezután elvontan egy új modellt fogunk javasolni, amely egy „bérlet” metaforáját használja, mint például repülőjegy vagy könyvtári kártya, hogy ezeket a problémákat biztonságos és használható módon kezeljük.

A Hearsay-probléma

A felhasználók hitelesítésének jelenlegi módszerei szenvednek az úgynevezett „Hearsay probléma” néven. A Hearsay olyan információ, amelyet az egyik fél kap a másik fél kijelentéseiről vagy intézkedéséről, és amelyet nem lehet megfelelően alátámasztani. Álláspontunk az, hogy minden olyan rendszerből származó információ, amely a felhasználók hitelesítésének legmodernebb módszereire támaszkodik, pusztán hallgatásnak minősül, ha valamelyik érintett fél megkérdőjelezi az információ érvényességét.

A szemléltetés céljából képzeljünk el egy rosszul fogadott közösségi médiabejegyzést, amelyet állítólag egy jól ismert politikus írt, és amely fenyegetheti az említett politikus karrierjének elpusztítását. Honnan tudhatjuk biztosan, hogy a politikus valójában szerzője volt az átkozott posztnak? Noha a szerző valóban a szóban forgó politikus lehetett, ugyanúgy bárki lehet, aki hozzáfér a politikus szociális média fiókjához. Ennek az érvelésnek a kibővítése érdekében a lehetséges „szerzők” csoportja tetszőleges számú politikához közeli személyt vagy ellenzéki hackert tartalmazhat egy célzott támadásban. Ennek ellenére senki, köztük a politikus és a szociális média szolgáltatója, nem tudna meggyőző, nem közvetett bizonyítékokat bemutatni arról, hogy a politikus a véglegesen vagy nem volt a szóban forgó állásfoglalás szerzője.

A jogi és technikai terminológia használatához ezt a tulajdonságot megcáfolhatóságnak nevezik, és ez nem a kívánt tulajdonság. A fenti szociális média példánkban két elsődleges tényező vezet a megcáfolhatóság ezen jellemzőjéhez; az első tényező egy hitelesítési rendszer, amely titok nyilvánosságra hozatalát követeli meg annak titka birtoklásának érvényesítése érdekében. A biztonsági rendszerekben (mint például a jelszavak), amelyekre ez a tényező vonatkozik, lehetetlen létrehozni olyan felhasználói tevékenységi naplókat, amelyeket a felek és az ügyfelek kivételével bárki más ellenőrizhet. A második tényező az eszközök hiánya annak bizonyítására, hogy egy olyan rendszeren belüli adatok, amelyek valóban a felhasználó szándékát képviselik, ami egy másik problémahoz vezet minket, amelyet az „Üres ellenőrzés” -nek hívunk.

Az üres ellenőrzés problémája

Az Üres ellenőrzés probléma minden olyan rendszerben megtalálható, amely a felhasználó nevében felléphet anélkül, hogy a felhasználó kifejezett hozzájárulása szükséges az adott művelethez. Ez akkor is fennáll, ha a felhasználó hozzájárulásának megragadására szolgáló eszköz elegendő bizonyítékként szolgál annak igazolására, hogy a felhasználót tájékoztatták minden egyes intézkedés következményeiről, és kifejezetten hozzájárult az egyes műveletekhez.

A fenti példában ez a probléma magát a szociális médiaszolgáltatást, valamint sok alkalmazottat hozzáadja azoknak a feleknek a listájához, amelyek elküldhetik az átkozott posztot. Hogyan bizonyíthatjuk, hogy a közösségi média szolgálata vagy annak egyik alkalmazottja nem volt veszélyeztetõ hozzáféréssel a „postahoz” a politikus nevében? A probléma magasabb szintű példája, amely bemutatja a „Az üres csekk probléma” név megfelelőségét, egy bankszámla. Technológiai szempontból semmi sem akadályozza meg a bankot, hogy likvidálja vagy zárolja a pénzeszközeit, és nem lenne mód arra, hogy igazolja a téves cselekedeteket, mivel a bank képesnek látszik nyilvánvalóan legitim tranzakciók nyilvántartására. Ez kétségkívül súlyos következményekkel jár, amelyek anyagilag érintik sok érdekelt felet.

A „Két válj egyet”

Egy szigorú megfigyelő észrevette, hogy ezek a problémák valójában ugyanazon alapvető probléma két kimenetele: a bizonyítható ellenőrzési naplók hiánya. Noha vannak olyan technológiák, amelyek orvosolják a jelenlegi rendszerünk ezt az alapvető hiányosságot, mint például az aszimmetrikus kriptográfián alapuló tanúsítványalapú rendszerek, még nem sikerült elérniük egy olyan felhasználóbarát felhasználási szintet, amely hozzáférhetővé teszi azokat a nagyközönség számára. Ha ezt a kihívást könnyen érthető metaforákkal kezeljük egy alább bemutatott elméleti megoldás érdekében, akkor lehetőségenk van javítani az összes rendszerünk biztonságát és használhatóságát, mindenféle felhasználó számára, és javítani a felhasználók tapasztalatait a folyamat során .

jelszavak

A kiberbiztonság megvitatásakor két alapfogalmat kell meghatározni: „hitelesítés”: az a folyamat, amellyel a felhasználó igazolja, hogy ők azok, akiknek azt mondják, hogy rendelkeznek bizonyos azonosító hitelesítő adatokkal, általában felhasználónévvel és jelszóval; és az „engedélyeztetés”, amely az a folyamat, amellyel a felhasználó tevékenységei a szoftverplatformon belül megengedettek vagy korlátozottak személyazonosságuk alapján.

Az 1960-as évek óta a jelszavak a tényleges módszer, amely lehetővé teszi a felhasználó számára, hogy hitelesítse magát egy eszköz vagy szolgáltatás mellett. A jelszavak hitelesítése mára jól ismert technológia a mérnökök számára. A felhasználók számára a jelszavak egyszerű fogalommá váltak; kényelmesek és ismerkednek még a nem műszaki felhasználók számára is. De bár egyszerűségük és ismertségük erőssége, a jelszavaknak számos hiányossága is van.

Az ilyen gyengeségek mind technológiai, mind emberi természetűek. Néhányat széles körben megvitatták, többek között a NIST Digitális identitás iránymutatásaiban is, és így nem fogjuk megismételni őket itt. Fontos azonban megjegyezni, hogy a jelszavak nem teszik lehetővé a felhasználó által jóváhagyott műveletek megbízható, auditálható naplóit. A jelszóval történő hitelesítéshez azt fel kell tárni, és a felhasználói jelszó érvényességének ellenőrzése érdekében a szolgáltatóknak tárolniuk kell őket valamilyen centralizált infrastruktúrában. Ez azt jelenti, hogy senki más, mint a szolgáltató, nem bízhat abban, hogy az általuk megőrzött ellenőrzési naplók a felhasználó műveleteinek pontos ábrázolása. Ezért a hitelesítéshez jelszavakra támaszkodó rendszerekre a fentiekben ismertetett Hearsay probléma és az Üres ellenőrzés problémája is vonatkozik.

A jelszavak fejlesztésének vagy cseréjének korszerű kísérletei

Az évek során számos kísérlet történt a jelszavak fokozatos javítására vagy cseréjére. Az alábbiakban néhány, a legsikeresebb esetet ismertetünk, azok erősségeivel és gyengeségeivel együtt.

Jelszókezelők

A Jelszókezelők létezése jelszavak számos alapvető hibájának elismerését jelenti. Megpróbálják javítani a helyzetet azáltal, hogy megszabadítják a felhasználót attól, hogy kellőképpen összetett jelszavakat kell előállítania és megjegyezniük, lehetővé téve ezzel az egycélú jelszavak használatát, amelyek megfelelnek a sokkal magasabb szintű biztonsági szigornak.

Helyesen használva a Jelszókezelők javítják a biztonságot, és korlátozott mértékben a jelszó alapú hitelesítéssel rendelkező rendszerek használhatóságát. Mindazonáltal bárki, aki megpróbálta megtanítani szüleit, gyermekeit vagy nem technikai barátait a mai jelszókezelő szoftver ismétléseinek használatára, fájdalmasan tisztában van azzal, hogy nem alkalmazzák széles körben és nem használhatók eléggé ahhoz, hogy így váljanak.

Technikai szempontból nincsenek szabványok a jelszókezelők számára. Megpróbálják kitalálni, amikor a felhasználó fiókot hoz létre, bejelentkezik vagy frissíti a jelszavát, hogy kényelmesebb legyen, de gyakran kudarcot vall. Alapot nyújtanak a továbbfejlesztett megoldáshoz, ám végül még mindig csak jelszavak és továbbra is mind a Hearsay probléma, mind a The Blank Check Problem ki vannak téve.

Két tényező hitelesítése

A jelszavak gyengeségének felismerése érdekében megkíséreltek további biztonsági szint kialakítását annak biztosítása érdekében, hogy maga a jelszó ne legyen a hiba egyetlen pontja. Ezt a megközelítést általában második tényezőnek vagy kétfaktoros hitelesítésnek (2FA) nevezik. A 2FA különféle megvalósításai vannak, és bár ezek mindegyike eltérő fokú növekményes biztonságot nyújt a jelszó alapú hitelesítési rendszerek számára, addig ezt még komplexebbé teszik a telepítés és a végfelhasználói működés szempontjából. A közös 2FA-megoldás az SMS-üzenetekre támaszkodik, hogy időalapú egyszeri jelszavakat (OTP) biztosítsanak. Ugyanúgy, mint maguk a jelszavak, a két tényezővel járó megoldások olyan problémától szenvednek, hogy nem ellenőrizhetők, és érzékenyek azokra a telefonszolgáltatókra, amelyek SMS-üzeneteket szállítanak az eszközére.

A bizonyítható auditálhatóság hiánya azt jelenti, hogy a 2FA továbbra sem oldja meg a Hearsay problémát vagy az üres ellenőrzési problémát.

A WebAuthn szabvány

A WebAuthn egy új hitelesítési standard, amelyet a World Wide Web Consortium (W3C), a tagszervezetek nemzetközi közössége, a teljes munkaidős alkalmazottak és a közönség javasolt a webes szabványok kidolgozása érdekében. A WebAuthn nagyon közel áll ahhoz, hogy ezeket a problémákat megoldja a web alapú tranzakciókhoz aszimmetrikus kriptográfia helyett jelszavak használatával, amely az egyik szükséges összetevő a felvázolt problémák leküzdéséhez. Annak elkerülése érdekében, hogy az eszközüket elveszítő felhasználókat minden szolgáltatásból kizárják, a WebAuthn-ot úgy tervezték, hogy jelszóval együtt használja, és ne helyettesítse.

A WebAuthn másik lényeges korlátozása az, hogy a jelenlét igazolására, nem pedig a hozzájárulás igazolására fejlesztették ki. Nincs meghatározva, hogy engedélyezzék-e olyan tranzakciónkénti engedélyezési kérelmeket, amelyeket a társak megvizsgálhatnak. Tehát ismét, a WebAuthn-ra támaszkodó rendszerek nem rendelkeznek bizonyítható naplózási naplókkal, és mind a Hearsay probléma, mind az Üres ellenőrzés problémájának vannak kitéve.

Blockchain mint lehetséges megoldás

A blokkláncok népszerűsítették a felhasználó hitelesítésének ötletét minden általuk engedélyezett művelethez, ennek a célnak a megvalósításához a tranzakciók nyilvános kulcsú kriptográfiai aláírásával. Ez nagy előrelépést jelent a jelszavakban, és egy lépéssel meghaladja a WebAuthn által kínált lehetőségeket. Ez kielégíti a Hearsay-probléma kezeléséhez szükséges első tényezőt is: a bizonyítható auditálhatóságot.

Sajnos a mai blokkláncú felhasználói interfészek szintén nem határoznak meg egy szabványt, amely lehetővé teszi az engedélyezési kérelmeknek az emberek számára barátságos leírását, hogy azok megbízható környezetben megjelenjenek a felhasználói jóváhagyáshoz. Ennek az emberi barátságos, szabványt megjelenítő kérés nélkül a felhasználók nem tudhatják, mit vállalnak. Ez azt jelenti, hogy annak ellenére, hogy a blokkláncok bizonyítható auditálható naplót hoznak létre, hiányoznak az eszközök annak bizonyításához, hogy a rendszeren belüli adatok valóban a felhasználó szándékát képviselik. Így továbbra is fennállnak a Hearsay és az üres ellenőrzés problémái.

Visszatérve a közösségi média példájához, ha egy szociális média platformot egy láncszemre építenek, akkor bizonyítani tudják, hogy a kérdéses politikus valójában aláírta a beosztás eredményeként létrejött akciót, de nem tudnák bebizonyítani hogy ők (vagy egy másik párt) nem tévesztették meg a politikusot az akció aláírásával, hamis bemutatásával.

Elméleti megoldás: Kulcsok vagy jelszavak helyett „átad”

Rendszereink biztonságának javítása érdekében szükség van a felhasználói beleegyezés igazolására, valamint az egyszerűség és a használhatóság szintjére, amely meghaladja a páros jelszavakat is. Ez azt jelenti, hogy olyan összetett technológiákat kell közölnünk, mint például az aszimmetrikus kriptográfia, olyan metaforával, amely azonnal érthető minden felhasználó számára, nem csak a technikusok számára. Az egyik koncepció, amely megfelel ezeknek a kritériumoknak, az „átadás” fogalma. A bérlet fogalmának leírása során megmutatjuk, hogy a Pass Manager alkalmazásban alkalmazott bérlet ezen elméleti megoldása miként képes kielégíteni mind a Hearsay problémát, mind az üres ellenőrzési problémát, amelyet felvázolunk.

A felhasználók számára a bérlet ismert és kézzelfogható módon bizonyítja a hitelesítő adatok birtoklását. Napi rutinunk részeként minden nap kölcsönhatásba lépünk a fizikai átadásokkal. Mint könyvtárfelhasználó, egyszerűen megmutatja és bemutatja a könyvtári kártyáját. Légi utasként csak megjelenik és bemutatja a jegyét. Példák az egycélú bérletekre, olyan szolgáltatások esetében, amelyek nem egycélú bérleti engedélyeket szolgáltatnak, személyi igazolása érdekében bemutathatja a jogosítványt.

A hitelesítés és az engedélyezési felhasználási esetek támogatása érdekében bevezettük a digitális „Pass Manager” fogalmát. A Pass Manager egy jelszó nélküli paradigma a regisztrációhoz, a hitelesítéshez és az engedélyezéshez.

Mit tehetsz egy Pass Managerrel?

Kiadás és visszavonás

  • A szolgáltatók kérhetik a Pass Manager-től, hogy új hozzáférési engedélyt adjon ki a felhasználó számára.
  • A felhasználók csoportokba rendezhetik átadásaikat. (például a munkám és a személyes igazolvány)
  • A felhasználók engedélyezhetik és jogosulatlanul engedélyezhetik az átadásokat több eszközön keresztül.

Hitelesítés

  • A szolgáltatók kérhetik igazolást arról, hogy a felhasználó rendelkezik-e bérlettel.
  • A felhasználók igazolhatják, hogy bérletük van.

meghatalmazás

  • A szolgáltatók kérhetik igazolást a felhasználó arra vonatkozó felhatalmazásáról, hogy egy adott művelet végrehajtására a felhasználó birtokában legyen.
  • A felhasználók láthatták, hogy az engedélykérelmek egyértelműen, emberbarát módon történnek, és választhatják, hogy engedélyezik-e a műveletet a birtokukban lévő engedély alapján.

Hogyan működne egy Pass Manager?

A Pass Manager egy (még meghatározandó) szabványosított protokollt valósít meg az engedélyek kiadására és visszavonására, hitelesítésre és engedélyekkel történő engedélyezésre. A Pass egy fogalmi absztrakció, amely magában foglalja a hitelesítő adatokat (kulcsok).

A digitális Pass Manager használatának tapasztalata nagyon hasonló lehet a pass kártya fizikai analógjához. A felhasználó egyszerűen megérkezik egy szolgáltatáshoz (legyen az webalkalmazás, natív alkalmazás, értékesítési pont rendszer vagy kioszk), és átad egy igazolványt a bejelentkezéshez vagy a művelet engedélyezéséhez. Ez olyan, mint egy főiskolai hallgató, aki az egyetemi igazolvánnyal felveszi a belépést a kollégiumi sporteseményekbe, majd egyszer belépett, és arra vásárolt, hogy egy standon vásároljon ételt az egyetemi étkező egyenlegükkel, és megrendelés-visszaigazolást kapjon a tranzakciók elkötelezettsége előtt.

A motorháztető alatt a technológiák keveréke párhuzamosan működhet, hogy kiemelkedő biztonságot és használhatóságot biztosítson a felhasználók számára, ideértve a kriptográfiai aláírást, a hardverkulcsokat és a hitelesítő adatok biztonságához szükséges biometrikus adatokat, valamint a hordozhatóság szállítási-agnosztikai protokollt.

Ha a felhasználó hozzájárulását egy Pass Manager kéri, a művelet emberbarát leírását meg kell mutatni a felhasználónak, és ezt a leírást (vagy annak kriptográfiailag ellenőrizhető származéka) bele kell foglalni a Pass Manager által aláírt válaszba. A kulcsok használata azt jelenti, hogy a naplók nem tagadhatatlanok és harmadik felek ellenőrizhetők, és az emberbarát leírásnak az aláírt válaszba történő felvétele bizonyíthatja a felhasználó szándékát. Ezek a jellemzők megoldják a Hearsay és az Üres ellenőrzést is.

Ez a modell támogathatja mind a jelenlegi webes technológiát, mind a jövőbeni blockchain technológia felhasználási eseteit. Emellett egyértelmű felhasználói élményt nyújt a bejelentkezés és az engedély felhasználása esetén is.

Mi szükséges ahhoz, hogy a Pass menedzser sikeres legyen?

Az interoperabilitás

Mindenekelőtt úgy kell elkészíteni a Pass Manager protokollt, hogy a felhasználók szabadon választhassák meg az igényeiknek leginkább megfelelő Pass Manager alkalmazást. Ez azért fontos, mert megakadályozza az eladók bekapcsolódását, létrehozva a szabad piacot, amelyre szükség van az innováció előmozdításához mind a biztonság, mind a felhasználói élmény szempontjából. Ily módon nyer a legjobb felhasználói élmény, elfogadható biztonsággal.

A választás szabadságának biztosításához szabványos protokolloknak kell lennie a regisztrációhoz, a bejelentkezéshez és a hitelesítéshez. Különösen az engedélyeztetés érdekes kihívás, mert megköveteli egy olyan szabvány meghatározását, amely leírja a felhasználók számára az engedélykérelmeket érthető, ellenőrizhető, igazolható és hordozható módon.

Hordozhatóság

Másodszor, a Pass Manager protokollt ki kell építeni a hordozhatóság érdekében; jelentése: 1) bármilyen platformon futó alkalmazás vagy szolgáltatás támogatása, 2) korlátozott vagy hiányos hálózati kapcsolat támogatása, 3) több eszköz támogatása és 4) eszközközi kommunikáció támogatása.

A felhasználók asztali számítógépekkel, laptop számítógépekkel, telefonokkal, táblagépekkel, intelligens órákkal és USB-kulcsokkal rendelkeznek. Tehát kritikus fontosságú az egyszerű és zökkenőmentes élmény a hozzáférési engedélyek kiadása és visszavonása több eszközön keresztül. A felhasználók kölcsönhatásba lépnek az értékesítési pontok rendszerével, a nem megbízható nyilvános számítógépekkel, az automatákkal és a kioszkokkal. Tehát szükséges az egyik eszközről a másikra történő kommunikáció, akár hálózati csatlakozással, akár anélkül, anélkül, hogy az eszközöknek egymásba kellene bízniuk.

Ezeket a követelményeket akkor lehet teljesíteni, ha a Pass Manager protokollt transzportagnosztikussá tesszük. Ez azt jelenti, hogy a protokollnak a főnevek és igék meghatározására kell összpontosítania, hogy a végrehajtó rendszereknek folyékonyan beszélniük kell, és lehetővé kell tenniük a szállítások változását. A szállításra példa lehet az egyéni protokoll URL-ek, az Apple Universal Links, az Android Intents, a szerver kérések, a QR-kódok, a Bluetooth, NFC és a JavaScript API-k. Ezzel a rugalmassággal a Pass Manager-ek valóban hordozhatóak lehetnek.

használhatóság

A felhasználóknak nem kell mérlegelniük annak következményeit, hogy webszolgáltatást használ-e adatbázis-háttérrel vagy blokklánc-rendszerrel. A blockchain esetében nem kellene tudniuk, hogy melyik blockchain platformra vagy hálózatra épül az általuk használt alkalmazás. Csak felhasználási esetüket kell megfontolniuk. Dolgok mint…

"Pénzt vonok ki ATM-ből."

"Bejelentkezek az e-mailbe."

"Szeretem a közösségi médiában való bejegyzést."

"Chipeket veszek egy automatából."

"100 zsetont átadok Danről Brianre."

Soha ne olyan dolgok legyenek, mint…

"Aláírom egy tranzakciót egy R1 kulcsmal, amely engedélyezett a blockchain11 számlámhoz, a example.com dapp-on, amely a Telos blokkláncon épül, amely az EOSIO platformon épül."

Biztonság

A jelszavak és a nyilvános kulcsú rendszerek jelenlegi megvalósítása különféle okok miatt nem biztonságos. A bérletvezetőknek jobban kell teljesíteniük.

Annak érdekében, hogy megvédjük a felhasználókat a központosított hitelesítő adatok mágneses edényeitől, a titkos hitelesítő adatokat soha ne tároljuk centralizált infrastruktúrán semmilyen formában (a hasítás és a sózás nem elég jók). Annak érdekében, hogy megvédjük a felhasználókat attól, hogy hitelesítő adataikat adathalász, rosszindulatú programok és közép-ember támadások révén ellopják, a felhasználóknak soha nem szabad tudniuk, mi a hitelesítő adataik, és soha nem szabad manuálisan vagy automatikusan bevinni semmilyen szolgáltatást. Annak érdekében, hogy megóvják a felhasználókat attól, hogy becsapják őket a rosszindulatú bérletek hozzáadásával, a felhasználóknak nem szabad maguknak hozzáadniuk vagy eltávolítaniuk a bérleteket. Ehelyett egy megbízható Pass Manager ezt automatikusan kezeli a felhasználó nevében, válaszul arra, hogy a felhasználó új szolgáltatásokat látogat, vagy új eszközöket szerez.

A jövő szélesen nyitva áll a Pass menedzserek számára

Ebben a cikkben a jelenlegi legmodernebb felhasználói fiókok biztosítási módszereivel kapcsolatban megfogalmaztuk a megoldandó problémákat a biztonsági és használhatósággal kapcsolatos problémákkal kapcsolatban. Ezen problémák megoldásának eszközeként bemutattuk a jelszavak helyettesítésére szolgáló Passes koncepciót és a digitális Pass Manager szoftvert. Megbeszéltük a Pass Manager protokoll sikeréhez szükséges attribútumokat, de nem határoztuk meg kifejezetten a protokollt. Arra ösztönözzük a vállalkozó fejlesztőket, hogy oldják meg a problémákat, amelyek mind a jelszó, mind a kulcs alapú biztonsági rendszereket sújtják, és fontolja meg a Pass metaforát az egyik módszerként e cél elérésében.

Jogi nyilatkozat: A Block.one önkéntes alapon járul hozzá az EOSIO közösség tagjához, és nem felelős a szoftver vagy a kapcsolódó alkalmazások teljes teljesítményének biztosításáért. Az itt leírt kiadások, a kapcsolódó GitHub kiadás, az EOSIO szoftver vagy bármely kapcsolódó, akár kifejezett, akár hallgatólagos dokumentum vonatkozásában nem vállalunk felelősséget, garanciát vagy garanciát, vagy vállalunk kötelezettséget, ideértve, de nem korlátozva a garanciákat vagy a forgalmazhatóságot, az adott felhasználásra való alkalmasságot. cél és jogsértés. Semmilyen esetben sem felelünk semmilyen követelésért, károkért vagy egyéb felelősségért, akár szerződéses, akár károkozásban, vagy más módon, amely a szoftver vagy a dokumentáció, illetve a szoftver használatának vagy egyéb ügyleteinek vagy azokkal összefüggésben, vagy azzal összefüggésben merül fel. dokumentáció. A teszt eredményei vagy teljesítményértékei indikatívak, és nem tükrözik a teljesítményt minden körülmények között. Bármely harmadik fél vagy harmadik fél termékére, erőforrására vagy szolgáltatására történő hivatkozás nem jelenti a Block.one általi jóváhagyást vagy ajánlást. Nem vagyunk felelősek, és nem vállalunk semmiféle felelősséget és felelősséget azért, hogy felhasználjuk ezeket az erőforrásokat. A harmadik féltől származó erőforrásokat bármikor frissíthetjük, megváltoztathatjuk vagy megszüntethetjük, tehát az itt szereplő információk lehetnek elavultak vagy pontatlanok. Bármely személy, aki ezt a szoftvert használja, vagy szoftvert kínál, árukat vagy szolgáltatásokat nyújt harmadik feleknek, tájékoztatja ezeket a harmadik feleket ezekről a licencfeltételekről, a felelősség kizárásáról és kizárásáról. A Block.one, az EOSIO, az EOSIO Labs, az EOS, a heptahedron és a kapcsolódó logók a Block.one védjegyei. Egyéb itt hivatkozott védjegyek a megfelelő tulajdonosok tulajdonát képezik. Felhívjuk figyelmét, hogy az itt szereplő állítások a Block.one jövőképének kifejezését képviselik, nem garantálnak semmire, és annak minden szempontját a Block.one kizárólagos belátása szerint minden tekintetben megváltoztathatja. Ezeket a „előretekintő nyilatkozatokat” nevezzük, amelyek magukban foglalják a dokumentumban szereplő nyilatkozatokat, kivéve a történelmi tények nyilatkozatait, például az EOSIO fejlődésével, várható teljesítményével és jövőbeli jellemzőivel, vagy üzleti stratégiánkkal, terveinkkel, kilátásainkkal, fejlesztéseinkkel és céljainkkal kapcsolatos nyilatkozatokat. Ezek az állítások csak előrejelzések és tükrözik a Block.one jelenlegi hiedelmeit és elvárásait a jövőbeli eseményekkel kapcsolatban; feltételezéseken alapulnak, és bármikor kockázatnak, bizonytalanságnak és változásnak vannak kitéve. Gyorsan változó környezetben működünk. Időről időre új kockázatok merülnek fel. Figyelembe véve ezeket a kockázatokat és bizonytalanságokat, figyelmeztetni kell arra, hogy ne támaszkodjon ezekre az előretekintő kijelentésekre. A tényleges eredmények, teljesítmény vagy események lényegesen eltérhetnek az előretekintő kijelentésekben előrejelzettől. Néhány olyan tényező, amely miatt a tényleges eredmények, teljesítmény vagy események lényegesen eltérhetnek az előretekintő kijelentésektől, többek között, korlátozás nélkül: piaci volatilitás; a tőke, a finanszírozás és a személyzet folyamatos rendelkezésre állása; termék elfogadása; bármely új termék vagy technológia kereskedelmi sikere; verseny; kormányzati rendeletek és törvények; valamint általános gazdasági, piaci vagy üzleti feltételek. Minden nyilatkozat csak az első feladás napjától érvényes, és a Block.one nem köteles és kifejezetten elutasítja a nyilatkozatok frissítésének vagy megváltoztatásának kötelezettségét, akár új információk, akár későbbi események eredményeként vagy más módon. Semmi sem jelent technológiai, pénzügyi, befektetési, jogi vagy egyéb tanácsokat, sem általánosságban, sem az adott helyzet vagy a végrehajtás szempontjából. Kérjük, konzultáljon a megfelelő területek szakértőivel, mielőtt megvalósítaná vagy felhasználná a dokumentumban található információkat.