Salasanaton tulevaisuus: rakentaminen kohti turvallisempia ja käyttökelpoisempia todennusjärjestelmiä

Salasanojen korvaaminen yksityisillä avaimilla helposti ymmärrettävässä metaforassa

EOSIO Labs ™ -aloitteen käyttöönoton myötä olemme alkaneet innovoida avoimesti EOSIOan rakennettujen blockchain-tekniikoiden tulevaisuuden suhteen. Aloitteen mukainen ensimmäinen julkaisumme tutkii yksityisen avaimen hallinnan tulevaisuutta ja sen vaikutuksia tietoturvaan ja avainten hallintaan - Universal Authenticator Library (UAL). Tämän julkaisun filosofian taustalla on tutkiminen laajempaan ongelmaan, joka keskittyy siihen, kuinka salasanat ja todennus on toteutettu Internetissä, blockchain-verkossa tai muuten. Vaikka tämän viestin mukana ei ole ohjelmistojulkaisua, tämän artikkelin tarkoituksena on keskustella ongelmista, jotka rikkovat olemassa olevia todennusjärjestelmiä, ja nykyaikaisista yrityksistä siirtyä tällaisten ongelmien mukana olevien salasanojen ulkopuolelle. Ehdotamme sitten abstraktisti uutta mallia, joka käyttää ”passin” metaforia, kuten lentolippu tai kirjastokortti, näiden ongelmien ratkaisemiseksi turvallisella ja käyttökelpoisella tavalla.

Hearsay-ongelma

Nykyiset käyttäjien todentamismenetelmät kärsivät siitä, mitä kutsumme “Hearsay-ongelmaksi”. Hearsay on sellainen tieto, joka on saatu yhdeltä osapuolelta toisen osapuolen lausumista tai toiminnasta ja jota ei voida riittävällä tavalla perustella. Kannattamme sitä, että kaikki tieto, joka on saatu järjestelmistä, jotka tukeutuvat nykyaikaisiin käyttäjien todentamismenetelmiin, katsotaan pelkkään kuuloilmaisuun, jos joku osapuolista asettaa kyseenalaiseksi tietojen pätevyyden.

Kuvaillakseni kuvittele huonosti vastaanotettu sosiaalisen median viesti, jonka väitetysti on kirjoittanut tunnettu poliitikko ja joka uhkaa tuhota mainitun poliitikon uran. Kuinka tiedämme varmasti, että poliitikko itse asiassa kirjoitti kirotuksen? Vaikka kirjoittaja olisi todellakin voinut olla kyseessä oleva poliitikko, se voi yhtä hyvin olla kuka tahansa, jolla on pääsy poliitikon sosiaalisen median tilille. Tämän päättelyn laajentamiseksi mahdollisten ”kirjoittajien” joukkoon voisi kuulua mikä tahansa määrä poliitikkojen läheisiä ihmisiä tai vastapuolisia hakkereita kohdennetussa hyökkäyksessä. Kukaan, mukaan lukien poliitikko ja sosiaalisen mediapalvelun tarjoaja, ei pystyisi esittämään vakuuttavaa, epäsäännöllistä näyttöä siitä, että poliitikko oli tai ei ollut lopullisesti kyseisen viestin kirjoittaja.

Juridisen ja teknisen terminologian käyttämiseksi tätä ominaisuutta kutsutaan virheellisyydeksi, eikä se ole haluttu piirre. Kaksi päätekijää johtavat tähän väitettävyysominaisuuteen yllä olevassa sosiaalisen median esimerkissä; Ensimmäinen tekijä on todennusjärjestelmä, joka vaatii salaisuuden paljastamista salaisuuden hallussapidon validoimiseksi. Tietoturvajärjestelmissä (kuten salasanat), joihin tämä tekijä kohdistuu, on mahdotonta luoda lokitietoja käyttäjätoiminnoista, jotka ovat muiden todennettavissa kuin osapuoli ja vastapuoli. Toinen tekijä on keino puuttua osoittamaan, että järjestelmän sisällä olevat tiedot, jotka tosiasiallisesti edustavat käyttäjän tarkoitusta, johtavat meihin toiseen ongelmaan, jota kutsumme, ”Tyhjä tarkistus”.

Tyhjän tarkistuksen ongelma

Tyhjän tarkistuksen ongelma esiintyy kaikissa järjestelmissä, jotka voivat ryhtyä toimiin käyttäjän puolesta ilman, että käyttäjän nimenomaista suostumusta kyseiseen toimintoon tarvitaan. On myös läsnä, jos käyttäjän suostumuksen kaappaamiseen tarvitaan jotain muuta kuin todistusaineistoa siitä, että käyttäjälle on ilmoitettu jokaisesta yksittäisestä toiminnasta ja että hän on nimenomaisesti antanut suostumuksensa jokaiseen toimenpiteeseen.

Yllä olevassa esimerkissä tämä ongelma lisää itse sosiaalisen mediapalvelun sekä monet sen työntekijät luetteloon osapuolista, jotka olisivat voineet lähettää kirotuksen. Kuinka voimme todistaa, että sosiaalisen median palveluksella tai jollakin sen työntekijöistä ei ollut vaarantavaa pääsyä "viestiin" poliitikon puolesta? Suurempi panos tästä ongelmasta, joka osoittaa nimen "The Blank Check Problem" soveltuvuuden, on pankkitili. Teknisesti ottaen mikään ei estä pankkiasi selvittämästä tai lukitsemasta varojasi, eikä ole mitään keinoa osoittaa väärää tekemistä, koska pankki voisi valmistaa kirjaa näennäisesti laillisista tapahtumista. Tällä olisi epäilemättä vakavia seurauksia, jotka vaikuttavat aineellisesti moniin sidosryhmiin.

'Kaksi tulla yhdeksi'

Kohtelias tarkkailija on ehkä huomannut, että nämä ongelmat ovat todellakin kaksi seurausta samasta taustalla olevasta ongelmasta: todistettavien tarkastuslokkien puuttuminen. Vaikka on olemassa tekniikoita, jotka korjaavat tämän perustavanlaatuisen puutteen nykyisissä järjestelmissä, kuten epäsymmetriseen salaukseen perustuvat varmennepohjaiset järjestelmät, niiden on vielä saavutettava käyttäjäystävällisyys, joka tekee niistä yleisön saatavilla. Vastaamalla tähän haasteeseen helposti ymmärrettävien metafoorien avulla teoreettisesta ratkaisusta, jonka esittelemme alla, meillä on mahdollisuus parantaa kaikkien järjestelmiemme turvallisuutta ja käytettävyyttä kaikentyyppisille käyttäjille ja parantaa käyttäjien kokemusta prosessista .

salasanat

Kyberturvallisuudesta keskusteltaessa olisi määriteltävä kaksi peruskysymystä: 'todennus', joka on prosessi, jolla käyttäjä todistaa olevansa ne, jotka he sanovat olevansa tietyn tunnistetietojen perusteella, tyypillisesti käyttäjätunnuksella ja salasanalla; ja 'valtuutus', joka on prosessi, jolla käyttäjän toimet ohjelmistoalustalla sallitaan tai rajoitetaan heidän henkilöllisyytensä mukaan.

1960-luvulta lähtien salasanat ovat olleet tosiasiallinen menetelmä, jonka avulla käyttäjä voi todentaa itsensä laitteelle tai palvelulle. Salasanan todennus on nyt insinöörien hyvin ymmärretty tekniikka. Käyttäjille salasanoista on tullut yksinkertainen käsite tarttua. ne ovat mukavia ja tuttuja jopa ei-teknisille käyttäjille. Mutta vaikka niiden yksinkertaisuus ja tuntevuus ovat vahvuus, salasanat kärsivät myös monista heikkouksista.

Tällaiset heikkoudet ovat luonteeltaan sekä teknisiä että inhimillisiä. Joistakin niistä on keskusteltu laajasti, mukaan lukien tyhjentävästi NIST: n digitaalisen henkilöllisyyden suuntaviivoissa, joten emme toista niitä täällä. Tärkeää on kuitenkin muistaa, että salasanat eivät salli käyttäjän luottamien toimien luotettavia tarkastettavia lokitietoja. Tunnistamiseen salasanalla se on paljastettava, ja käyttäjän salasanan oikeellisuuden tarkistamiseksi palveluntarjoajien on oltava tallentanut ne jonkinlaiseen keskitettyyn infrastruktuuriin. Tämä tarkoittaa, että kukaan palveluntarjoaja, paitsi palveluntarjoaja, ei voi luottaa siihen, että heidän pitämänsä tarkastuslokit edustavat tarkkaan käyttäjän toimia. Tästä syystä järjestelmiin, jotka luotettavuuteen luottavat salasanoihin, kohdistuu sekä Hearsay-ongelma että tyhjän tarkistusongelma, kuten yllä on kuvattu.

Nykyaikaiset yritykset parantaa tai korvata salasanoja

Vuosien mittaan on yritetty parantaa asteittain tai korvata salasanoja. Jäljempänä tarkastellaan muutamia menestyneimmistä tapauksista sekä niiden vahvuuksista ja heikkouksista.

Salasananhallinnat

Salasanan hallintaohjelmien olemassaolo edustaa useiden salasanojen perustavanlaatuisten puutteiden myöntämistä. He yrittävät parantaa tilannetta vapauttamalla käyttäjän tarpeesta luoda ja muistaa riittävän monimutkaisia ​​salasanoja, mikä sallii yksikäyttöiset salasanat, jotka täyttävät paljon korkeamman tason turvallisuus.

Oikein käytettynä salasananhallinnat parantavat tietoturvaa ja rajoitetussa määrin järjestelmien käytettävyyttä salasanapohjaisella todennuksella. Kuitenkin kuka tahansa, joka on yrittänyt opettaa vanhempiaan, lapsiaan tai muita kuin teknisiä ystäviä käyttämään nykyisiä salasananhallintaohjelmistojen iteraatioita, on tuskallisesti tietoinen siitä, että niitä ei ole laajalti omaksuttu eikä niitä voida käyttää niin, että niistä tulee.

Teknisestä näkökulmasta salasananhallinnalle ei ole standardeja. He yrittävät arvata, milloin käyttäjä luo tiliä, kirjautuu sisään tai päivittää salasanansa helpommaksi, mutta epäonnistuvat usein. Ne tarjoavat perustan parannetulle ratkaisulle, mutta lopulta ne ovat edelleen vain salasanoja ja niihin kohdistuu edelleen sekä Hearsay-ongelma että The Blank Check -ongelma.

Kahden tekijän todennus

Salasanojen heikkouden tunnistamiseksi on yritetty kerätä lisäturvaa sen varmistamiseksi, että salasana itsessään ei ole ainoa virhekohta. Tätä lähestymistapaa kutsutaan yleensä toiseksi tekijäksi tai kaksifaktoriseksi todennukseksi (2FA). 2FA: lla on useita toteutuksia, ja vaikka ne kaikki lisäävät eripitkäisen asteittaisen suojauksen salasanapohjaisiin todennusjärjestelmiin, ne korvaavat sen asennuksen ja loppukäyttäjän toiminnan kannalta monimutkaisempana. Yleinen 2FA-ratkaisu perustuu tekstiviesteihin aikapohjaisten kertaluonteisten salasanojen (OTP) tarjoamiseksi. Aivan kuten salasanatkin, kaksitekijäisissä ratkaisuissa on ongelma, että niitä ei voi tarkastella, ja ne ovat alttiita puhelimille, jotka toimittavat laitteeseesi tekstiviestejä.

Tämä todistettavuuden puuttuvuus tarkoittaa, että 2FA ei silti ratkaise Hearsay-ongelmaa tai Tyhjän tarkistuksen ongelmaa.

WebAuthn-standardi

WebAuthn on uusi todentamisstandardi, jonka on ehdottanut World Wide Web Consortium (W3C), kansainvälinen jäsenjärjestöjen yhteisö, kokopäiväinen henkilökunta ja kansalaiset yhdessä kehittämään web-standardeja. WebAuthn on hyvin lähellä kaikkien näiden ongelmien ratkaisemista verkkopohjaisissa liiketoimissa käyttämällä asymmetristä salaustekniikkaa salasanojen sijasta, tarjoamalla yhden välttämättömistä ainesosista havaitsemiemme ongelmien ratkaisemiseksi. Laitteiden menettäneiden käyttäjien lukitsemisen estämiseksi kaikista palveluista WebAuthn on kuitenkin suunniteltu käytettäväksi yhdessä salasanojen kanssa eikä korvaavina.

Toinen merkittävä WebAuthn-rajoitus on, että se on suunniteltu todisteeksi läsnäolosta, ei suostumuksen todisteena. Sitä ei ole määritelty sallimaan kauppakohtaisia ​​valtuutuspyyntöjä, jotka ovat vertaiskelpoisia. Joten jälleen kerran järjestelmissä, jotka tukeutuvat WebAuthniin, ei ole todistettavia tarkastuslokeja, ja niihin kohdistuu sekä Hearsay-ongelma että The Blank Check -ongelma.

Blockchain potentiaalisena ratkaisuna

Blockchains on suosinut ajatusta käyttäjän todentamisesta jokaisesta valtuuttamastaan ​​toiminnasta käyttämällä tämän tavoitteen saavuttamiseksi julkisen avaimen salaustekniset allekirjoitukset tapahtumien allekirjoittamisesta. Tämä on iso parannus salasanoissa ja askel pidemmälle kuin WebAuthn voi tarjota. Se täyttää myös ensimmäisen Harsay-ongelman ratkaisemiseksi tarvittavan tekijän: todistettavuuden.

Valitettavasti nykypäivän blockchain-käyttöliittymät eivät myöskään määrittele standardia, jolla kuvataan valtuutuspyynnöt ihmisille sopivalla tavalla käyttäjille, jotta ne voidaan näyttää luotettavassa ympäristössä käyttäjän hyväksyttäväksi. Ilman tätä ihmisystävällistä pyyntöä, joka antaa standardin, käyttäjät eivät voi tietää mitä ovat suostuneet. Tämä tarkoittaa, että vaikka lohkoketjut luovat todennettavissa olevan tarkastettavan lokin, niillä ei ole keinoja todistaa, että järjestelmän sisällä olevat tiedot todella edustavat käyttäjän tarkoitusta. Siksi heihin kohdistuu edelleen Hearsay- ja Tyhjennä-ongelmia.

Takaisin sosiaalisen median esimerkkiimme, jos sosiaalisen median alusta rakennettaisiin lukketjuun, he pystyisivät todistamaan, että kyseinen poliitikko itse asiassa allekirjoitti virkaan johtaneen toiminnan, mutta he eivät pystyisi todistamaan että he (tai jokin muu puolue) eivät huijannut poliitikkoa allekirjoittamaan toimen väärinkäyttämällä sitä.

Teoreettinen ratkaisu: “Passes” avainten tai salasanojen sijasta

Järjestelmämme turvallisuuden parantamiseksi tarvitaan todisteita käyttäjän suostumuksesta yhdistettynä yksinkertaisuuden ja käytettävyyden tasoon, joka ylittää jopa salasanat. Tämä tarkoittaa, että meidän on kommunikoitava monimutkaisten tekniikoiden, kuten epäsymmetrisen salauksen, avulla sellaisen metaforin avulla, joka on heti ymmärrettävissä kaikille käyttäjille, ei vain tekniikoille. Yksi konsepti, joka täyttää nämä kriteerit, on ”läpäisy”. Kuvailemalla passin käsitettä osoitamme, kuinka tämä Pass Manager -sovelluksessa käytetty passin teoreettinen ratkaisu voi tyydyttää sekä esitetyn Hearsay-ongelman että tyhjän tarkistusongelman.

Käyttäjille pass on tuttu ja konkreettinen tapa todistaa valtakirjan hallussapito. Joka päivä olemme vuorovaikutuksessa fyysisten kulkujen kanssa osana päivittäisiä rutiinejamme. Kirjaston käyttäjänä sinä vain näytät ja esität kirjastokorttisi. Lentomatkustajana näytät vain lipun ja esität sen. Nämä ovat esimerkkejä yhden käyttötarkoituksen kulkuneuvoista. Palveluille, jotka eivät tarjoa yhden käyttötarkoituksen kulkemista, saatat esittää ajokortti henkilöllisyytesi todistamiseksi.

Autamme todentamisen ja valtuutuksen käyttötapauksia ottamalla käyttöön digitaalisen ”Pass Manager” -käsitteen. Pass Manager on salasanaton paradigma rekisteröinti-, todennus- ja valtuutuskäyttötapauksissa.

Mitä voisit tehdä Pass Managerilla?

Myöntäminen ja peruuttaminen

  • Palveluntarjoajat voivat pyytää Pass Manageria myöntämään uuden passin käyttäjälle.
  • Käyttäjät voivat järjestää passinsa ryhmiin. (esimerkiksi työni ja henkilökohtaiset passini)
  • Käyttäjät voivat valtuuttaa ja poistaa valtuudet useiden laitteiden kautta.

Authentication

  • Palveluntarjoajat voivat pyytää todisteita käyttäjän hallussaan passista.
  • Käyttäjät voivat todistaa, että heillä on passi.

valtuutus

  • Palveluntarjoajat voivat pyytää todisteita käyttäjän valtuutuksesta suorittaa tietty toiminto käyttäjän hallussa olevan luvan perusteella.
  • Käyttäjät voivat nähdä selkeästi ihmisille sopivalla tavalla tehdyt valtuutuspyynnöt ja halutessaan sallia toimenpiteen luvan hallussaan olevalla passilla.

Kuinka Pass Manager toimisi?

Pass Manager toteuttaa (vielä määriteltävän) standardoidun protokollan passien myöntämistä ja peruuttamista, todennusta ja valtuutusta varten. Hyväksyntä on käsitteellinen abstraktio, joka kapseloi käyttöoikeustiedot (avaimet).

Kokemuksen digitaalisen Pass Manager -sovelluksen käytöstä tulisi olla hyvin samanlainen kuin pass-korttien fyysisen analogin. Käyttäjä vain saapuu palveluun (olipa kyse sitten web-sovelluksesta, natiivisovelluksesta, myyntipistejärjestelmästä tai kioskista) ja antaa passin kirjautuakseen sisään tai valtuuttamaan toiminnon. Tämä on kuin korkeakouluopiskelija, joka käyttää yliopistotunnustaan ​​pääsyyn kollegiaaliseen urheilutapahtumaan. Sitten kun se ostaa sisällään ruokaa osastollaan kampuksen ruokailutaseen kanssa, hänelle esitetään tilausvahvistukset ennen sitoutumista liiketoimiin.

Kotelon alla sekoitus tekniikoita voi toimia samanaikaisesti tuottaakseen parhaan mahdollisen turvallisuuden ja käytettävyyden käyttäjille, mukaan lukien salakirjoitukset, laitteistoavaimet ja biometriset tiedot valtuustietojen suojaamiseksi, samoin kuin kuljetus-agnostinen protokolla siirrettävyyttä varten.

Aina kun Pass Manager haluaa käyttäjän suostumuksen, käyttäjälle tulee näyttää ihmisystävälliset kuvaukset toiminnasta, ja kuvaus (tai sen salausvarmennettava johdannainen) tulisi sisällyttää Pass Manager -sovelluksen allekirjoittamaan vastaukseen. Avainten käyttö tarkoittaa, että lokit eivät ole kumottavia ja että ne voidaan tarkistaa kolmansien osapuolten toimesta. Ihmisystävällisen kuvauksen sisällyttäminen allekirjoitettuun vastaukseen voi toimia todisteena käyttäjän aikomuksesta. Nämä ominaisuudet ratkaisevat sekä Hearsay- että Blank Check -ongelmat.

Tämä malli tukee sekä nykyistä verkkoteknologiaa että tulevia blockchain-tekniikan käyttötapoja. Se pystyy myös tarjoamaan selkeän käyttökokemuksen sekä kirjautumisen että valtuutuksen käyttötapauksissa.

Mitä tarvitaan Pass Manager -päälliköiden menestymiseen?

yhteentoimivuuden

Ensinnäkin, Pass Manager -protokolla olisi rakennettava, jotta käyttäjät voivat vapaasti valita heidän tarpeitaan parhaiten vastaavan Pass Manager -sovelluksen. Tämä on tärkeää, koska se estää toimittajien lukkiutumisen ja luo vapaita markkinoita, jotka ovat välttämättömiä innovaatioiden edistämiseksi sekä tietoturvassa että käyttökokemuksessa. Tällä tavoin voittaa paras käyttäjäkokemus hyväksyttävällä suojauksella.

Tämän valinnanvapauden tarjoamiseksi tarvitaan vakioprotokollia rekisteröintiä, kirjautumista ja valtuutusta varten. Erityisesti valtuutus on mielenkiintoinen haaste, koska se edellyttää standardin määrittelemistä käyttäjien lupahakemusten kuvaamiseksi ymmärrettävällä, tarkastettavalla, todistettavalla ja siirrettävällä tavalla.

siirrettävyys

Toiseksi Pass Manager -protokolla olisi rakennettava siirrettävyyttä varten; merkitys: 1) tuki kaikentyyppisille sovelluksille tai palveluille, jotka toimivat missä tahansa alustassa, 2) tuki rajoitetulle tai ei lainkaan verkkoyhteydelle, 3) tuki useille laitteille ja 4) tuki laitteidenväliseen viestintään.

Käyttäjillä on pöytätietokoneet, kannettavat tietokoneet, puhelimet, tabletit, älykellot ja USB-avaimet. Joten yksinkertainen ja saumaton kokemus useiden laitteiden pääsyoikeuksien myöntämisestä ja peruuttamisesta on kriittinen. Käyttäjät ovat myös vuorovaikutuksessa myyntipistejärjestelmien, epäluotettavien julkisten tietokoneiden, myyntiautomaattien ja kioskien kanssa. Joten on välttämätöntä olla vuorovaikutuksessa laitteesta toiseen, verkkoyhteyksien kanssa tai ilman, ilman, että laitteita tarvitsee luottaa toisiinsa.

Nämä vaatimukset voidaan täyttää määrittelemällä Pass Manager -protokolla kuljetusagnostisiksi. Tämä tarkoittaa, että protokollan tulisi keskittyä määrittelemään substantiivit ja verbit, joiden täytäntöönpanojärjestelmien on kyettävä puhumaan sujuvasti ja antamaan kuljetusten, joiden kautta niitä puhutaan, vaihdella. Esimerkkejä kuljetuksista voivat olla mukautetun protokollan URL-osoitteet, Apple Universal Links, Android Intents, palvelinpyynnöt, QR-koodit, Bluetooth, NFC ja JavaScript-sovellusliittymät. Tällä joustavuudella Pass Managers voi olla todella kannettava.

Käytettävyys

Käyttäjien ei pitäisi joutua harkitsemaan vaikutuksia siihen, käyttävätkö ne verkkopalvelua tietokannan taustajärjestelmän tai blockchain-järjestelmän kanssa. Blokkiketjun tapauksessa heidän ei tarvitse tietää, mihin blockchain-alustaan ​​tai verkkoon heidän käyttämänsä sovellus on rakennettu. Heidän on vain harkittava käyttötapaustaan. Asioita kuten…

"Vedän varoja pankkiautomaatista."

"Kirjaudun sähköpostiini."

"Pidän postista sosiaalisessa mediassa."

"Ostan siruja automaatista."

"Siirrän 100 rahaketta Danista Brianiin."

Älä koskaan asioita kuten…

"Allekirjoitan tapahtuman R1-avaimella, joka on valtuutettu blockchain11-tililleni, esimerkki.com dapp -sovelluksessa, joka on rakennettu Telosin blockchainiin, joka on rakennettu EOSIO-alustalle."

turvallisuus

Sekä salasanojen että julkisen avaimen järjestelmien nykyiset toteutukset ovat turvallisia monista syistä. Päästöjohtajien on tehtävä paremmin.

Käyttäjien suojelemiseksi keskitetyihin valtakirjoihin liittyviä hyökkäyksiä vastaan ​​salaisia ​​käyttöoikeustietoja ei koskaan tulisi tallentaa keskitettyyn infrastruktuuriin missään muodossa (hajauttaminen ja suolaaminen eivät ole tarpeeksi hyviä). Suojataksesi käyttäjiäsi varastamaan tietoisuutensa tietojenkalastelusta, haittaohjelmista ja keskitie-keskuudessa tapahtuvista hyökkäyksistä, käyttäjien ei pitäisi koskaan tietää, mitkä heidän valtakirjansa ovat, eikä heitä saa koskaan syöttää manuaalisesti tai automaattisesti mihinkään palveluun. Suojataksesi käyttäjiä huijatuilta lisäämään haitallisia passia, käyttäjien ei pitäisi voida itse lisätä tai poistaa passeja. Sen sijaan luotettavan Pass Manager -sovelluksen tulisi käsitellä tätä automaattisesti käyttäjän puolesta vastauksena käyttäjän vierailuun uusiin palveluihin tai uusien laitteiden hankkimiseen.

Tulevaisuus on laaja avoin passipäälliköille

Tässä artikkelissa olemme esittäneet ratkaistavia ongelmia turvallisuus- ja käytettävyysongelmien ratkaisemiseksi nykyisten huipputeknisten menetelmien avulla käyttäjätilien turvaamiseksi. Olemme esittäneet salasanojen korvaavien passien konseptin ja digitaalisen Pass Manager -ohjelman keinona ratkaista nämä ongelmat. Olemme keskustelleet Pass Manager -protokollan onnistumisen välttämättömistä ominaisuuksista, mutta emme ole määritelleet protokollaa nimenomaisesti. Kannustamme yrittäjiä kehittäjiä ratkaisemaan ongelmat, jotka romahtavat sekä salasana- että avainpohjaisissa turvajärjestelmissä, ja harkitsemaan Pass-metafooria yhtenä tapana saavuttaa tämä tavoite.

Vastuuvapauslauseke: Block.one antaa osallistumisensa EOSIO-yhteisön jäsenenä vapaaehtoisesti eikä ole vastuussa ohjelmiston tai siihen liittyvien sovellusten yleisen suorituskyvyn varmistamisesta. Emme anna takuita, takuita tai sitoumuksia tässä kuvattujen julkaisujen, niihin liittyvän GitHub-julkaisun, EOSIO-ohjelmiston tai minkään muun asiaan liittyvän, joko ilmaisen tai epäsuoran, mukaan lukien, mutta rajoittumatta, takuut tai myyntikelpoisuus, sopivuus tietylle tarkoitus ja rikkomattomuus. Emme missään tapauksessa ole vastuussa mistään vaatimuksesta, vahingosta tai muusta vastuusta, joka johtuu sopimuksesta, vahingonkorvauksesta tai muusta, joka johtuu ohjelmistosta tai dokumentaatiosta tai sen yhteydessä tai sen käytöstä tai muusta ohjelmiston tai sen kaupasta tai dokumentointi. Mahdolliset testitulokset tai suoritusarvot ovat ohjeellisia eivätkä heijasta suorituskykyä kaikissa olosuhteissa. Mitkään viittaukset kolmansien osapuolien tai kolmansien osapuolten tuotteisiin, resursseihin tai palveluihin eivät ole Block.onen hyväksymiä tai suosituksia. Emme ole vastuussa näiden tietojen käytöstä tai luottamiseen näihin resursseihin. Kolmannen osapuolen resurssit voidaan päivittää, muuttaa tai lopettaa milloin tahansa, joten tässä olevat tiedot voivat olla vanhentuneita tai epätarkkoja. Kaikkien henkilöiden, jotka käyttävät tai tarjoavat tätä ohjelmistoa ohjelmistojen, tavaroiden tai palvelujen tarjoamisen yhteydessä kolmansille osapuolille, on ilmoitettava näille kolmansille osapuolille näistä lisenssiehdoista, vastuuvapauslausekkeista ja vastuun poissulkemisista. Block.one, EOSIO, EOSIO Labs, EOS, heptahedron ja siihen liittyvät logot ovat Block.one: n tavaramerkkejä. Muut tavaramerkit, joihin tässä viitataan, ovat omistajiensa omaisuutta. Huomaa, että tässä olevat lausunnot ovat ilmaus Block.onon visiosta, eivät takaa mitään, ja kaikki sen näkökohdat voivat muuttua kaikilta osin Block.onen yksinomaisella harkinnalla. Kutsumme näitä ”tulevaisuuteen suuntautuvia lausumia”, jotka sisältävät lausunnot tässä asiakirjassa, lukuun ottamatta lausuntoja historiallisista tosiasioista, kuten lausunnot EOSIOn kehityksestä, odotetusta suorituskyvystä ja tulevaisuuden piirteistä tai liiketoimintastrategiastamme, suunnitelmistamme, näkymistä, kehityksestä ja tavoitteista. Nämä lausunnot ovat vain ennusteita ja heijastavat Block.onen nykyisiä uskomuksia ja odotuksia tulevaisuuden tapahtumista; ne perustuvat oletuksiin, ja niihin liittyy riski, epävarmuustekijöitä ja muutoksia milloin tahansa. Toimimme nopeasti muuttuvassa ympäristössä. Uudet riskit ilmenevät ajoittain. Nämä riskit ja epävarmuustekijät huomioon ottaen sinua varoitetaan olemasta luottamatta näihin tulevaisuuteen suuntautuviin lausumiin. Todelliset tulokset, suorituskyky tai tapahtumat voivat poiketa olennaisesti tulevaisuuteen suuntautuvien lausumien ennusteista. Joitakin tekijöitä, jotka saattavat aiheuttaa todellisten tulosten, suorituskyvyn tai tapahtumien eroavuuksien huomattavasti tulevaisuudennäkymistä, ovat muun muassa markkinoiden volatiliteetti; pääoman, rahoituksen ja henkilöstön jatkuva saatavuus; tuotteen hyväksyminen; uusien tuotteiden tai teknologioiden kaupallinen menestys; kilpailu; hallituksen määräykset ja lait; ja yleiset taloudelliset, markkina- tai liiketoimintaolosuhteet. Kaikki lausunnot ovat voimassa vain ensimmäisestä lähettämispäivästä lähtien, ja Block.one ei ole velvollinen ja nimenomaisesti hylkää mitään velvollisuuksia päivittää tai muuttaa lauseita, joko uusien tietojen, myöhempien tapahtumien tai muuten. Mikään tässä ei ole teknistä, taloudellista, sijoitustoimintaa, oikeudellista tai muuta neuvoja, joko yleisesti tai minkään tietyn tilanteen tai toteutuksen suhteen. Kysy asiaankuuluvien alueiden asiantuntijoilta ennen tämän asiakirjan sisältämien asioiden toteuttamista tai hyödyntämistä.