Parolasız Bir Gelecek: Daha Güvenli ve Kullanılabilir Kimlik Doğrulama Sistemlerine Doğru İnşa Etmek

Anlaşılması kolay bir metafor olan şifreleri özel anahtarlarla değiştirme

EOSIO Labs ™ girişiminin tanıtımıyla birlikte, EOSIO'da oluşturulan blockchain teknolojilerinin geleceği konusunda açık alanda yeniliklere başladık. Bu inisiyatif kapsamındaki ilk sürümümüz, özel anahtar yönetiminin geleceğini ve güvenlik ve anahtar yönetimi üzerindeki etkilerini - Evrensel Doğrulayıcı Kütüphanesi (UAL) üzerine araştırıyor. Bu sürüm felsefesinin temelini oluşturan şey, şifreler ve kimlik doğrulamanın internet, blokchain veya başka şekillerde nasıl uygulandığına odaklanan daha büyük bir soruna yapılan keşif. Bu yazıya eşlik eden bir yazılım sürümü bulunmamakla birlikte, bu makale, mevcut kimlik doğrulama sistemlerini rahatsız eden sorunları ve bu tür sorunlara cevap veren modern şifrelerin ötesine geçme girişimlerini tartışmayı amaçlamaktadır. Özetle, bu sorunları güvenli ve kullanışlı bir şekilde ele almak için uçak bileti veya kütüphane kartı gibi “geçiş” metaforunu kullanan yeni bir model önereceğiz.

Hearsay Sorunu

Kullanıcıların kimliğini doğrulamak için geçerli yöntemler “Hearsay Sorunu” dediğimiz şeyden acı çekiyor. Hearsay, bir tarafın, ikinci bir tarafın yeterince doğrulanamayan ifadeleri veya eylemleriyle ilgili aldığı herhangi bir bilgidir. Duruşumuz, mevcut kullanıcıların en son yöntemlerini doğrulamak için kullanılan yöntemlere dayanan sistemlerden elde edilen tüm bilgilerin, ilgili taraflardan herhangi birinin söz konusu bilginin geçerliliği olduğunu söylemesi durumunda, sadece bir deneme olarak niteleneceğidir.

Göstermek için, söz konusu politikacının kariyerini imha etmekle tehdit eden iyi bilinen bir politikacının yazdığı iddia edilen kötü karşılanmış bir sosyal medya yayınını hayal edin. Aslında, politikacının, lanet olası görevi yazdığını kesin olarak nasıl biliyoruz? Yazar gerçekten söz konusu politikacı olsa da, politikacının sosyal medya hesabına erişimi olan herkes eşit olabilir. Bu akıl yürütmeyi uzatmak için, muhtemel “yazarlar” havuzu, politikacıya yakın herhangi bir sayıda kişiyi veya hedeflenen bir saldırıda düşman hackerları içerebilir. Yine de, politikacı ve sosyal medya servis sağlayıcısı dahil hiç kimse, politikacının söz konusu görevin yazarı olduğuna ya da kesin olarak yazdığına dair kesin olmayan, kesin olmayan kanıtlar sunamazdı.

Yasal ve teknik terminolojiyi kullanabilmek için bu özelliğe itibarlılık denir ve bu istenen bir özellik değildir. İki temel faktör, yukarıdaki sosyal medya örneğimizde bu itibarın bu özelliğine yol açar; ilk faktör, bu sırrın sahipliğini doğrulamak için bir sırrın açıklanmasını gerektiren bir kimlik doğrulama şemasıdır. Bu faktöre bağlı güvenlik şemalarında (şifreler gibi), parti ve karşı tarafın dışındaki herhangi biri tarafından doğrulanabilir kullanıcı etkinliği kayıtları oluşturmak mümkün değildir. İkinci faktör, sistemin aslında kullanıcının amacını temsil eden ve bizi “Boş Çek” olarak adlandırdığımız başka bir soruna götüren, kullanıcının amacını temsil eden bir verinin olduğunu kanıtlamak için yeterli olmamasıdır.

Boş Çek Sorunu

Boş Kontrol sorunu, kullanıcının bu belirli işlem için açık bir onayına gerek duymadan, kullanıcı adına işlem yapabilen herhangi bir sistemde mevcuttur. Ayrıca, kullanıcının onayını alma araçlarının, kullanıcının her bir işlemin sonuçlarından haberdar olduğu ve her bir eylem için açıkça onaylandığı konusunda bir kanıt günlüğünden başka bir şey olmadığı durumlarda da mevcuttur.

Yukarıdaki örnekte, bu sorun, sosyal medya hizmetinin kendisini, çalışanlarının birçoğunu kahrolası postayı gönderebilecek tarafların listesine ekler. Sosyal medya servisinin veya çalışanlarından birinin politikacı adına “postaya” erişimini tehlikeye atmadığını nasıl kanıtlayabiliriz? “Boş Çek Sorunu” adının uygunluğunu gösteren daha yüksek riskli bir örnek, bir banka hesabına aittir. Teknolojik olarak konuşursak, bankanızın fonlarınızı tasfiye etmesini veya kilitlemesini engelleyecek hiçbir şey yoktur ve Banka görünüşte meşru işlemlerin kayıtlarını üretebildiğinden, herhangi bir yanlış işlem yapmanın hiçbir yolu yoktur. Bu, hiç şüphesiz, birçok paydaşı maddi şekilde etkileyen ciddi sonuçlara yol açacaktır.

İki Kişi Bir Olur

Akıllı bir gözlemci, bu sorunların aynı temel problemin gerçekten iki sonucu olduğunu fark etmiş olabilir: kanıtlanabilir denetim kayıtlarının olmaması. Mevcut sistemlerimizde bu temel eksikliği gideren teknolojiler var olsa da, asimetrik kriptografiye dayanan sertifika tabanlı sistemler gibi, henüz genel halkın erişimine açık kılan bir kullanıcı dostuluk düzeyi sağlamıştır. Aşağıda sunacağımız teorik bir çözüm için anlaşılması kolay metaforlarla bu zorluğu ele alarak, her tür kullanıcı için tüm sistemlerimizin güvenliğini ve kullanılabilirliğini geliştirme ve her süreçte kullanıcıların deneyimini geliştirme fırsatına sahibiz. .

Şifreler

Siber güvenlik tartışılırken, iki temel terim tanımlanmalıdır: “kullanıcının kimlik doğrulaması”, bir kullanıcının, tipik olarak bir kullanıcı adı ve şifreyle, belirli tanımlayıcı kimlik bilgilerine sahip olduklarını söylediklerini ispat ettiği süreçtir; ve ‘yetkilendirme’, bir yazılım platformunda bir kullanıcının eylemlerine kimliğine göre izin verilme veya kısıtlanma işlemidir.

1960'lı yıllardan beri, şifreler, kullanıcının kendilerini bir aygıta veya hizmete doğrulamasına izin veren fiili bir yöntemdir. Parola doğrulaması, şimdiye kadar, mühendisler için iyi anlaşılmış bir teknolojidir. Kullanıcılar için, şifreler kavraması kolay bir kavram haline gelmiştir; teknik olmayan kullanıcılar için bile rahat ve tanıdıklar. Ancak sadeliği ve aşinalıkları bir güç olsa da, şifreler de birçok zayıflıktan muzdariptir.

Bu zayıflıklar doğada hem teknolojik hem de insandır. NIST Dijital Kimlik Kılavuzundaki ayrıntılı detaylar da dahil olmak üzere, bazıları geniş çapta tartışıldı, bu yüzden onları burada tekrarlamayacağız. Ancak hatırlanması gereken önemli olan, şifrelerin, kullanıcının izin verdiği eylemlerin güvenilir şekilde denetlenebilir günlüklerini sağlamadığıdır. Bir parola ile doğrulamak için, açığa çıkarılması ve bir kullanıcının parolasının geçerliliğini kontrol etmek için, servis sağlayıcıların bunları bir tür merkezi altyapı şeklinde saklamış olmaları gerekir. Bu, servis sağlayıcısından başka hiç kimsenin tuttuğu herhangi bir denetim kaydının bir kullanıcının işlemlerinin doğru gösterimi olduğuna güvenemeyeceği anlamına gelir. Bu nedenle, kimlik doğrulama için şifrelere dayanan sistemler yukarıda açıklanan Hearsay Problemine ve Blank Check Problemine tabidir.

Parolaları iyileştirme veya değiştirme girişimleri

Yıllar boyunca şifreleri aşamalı olarak iyileştirmek veya değiştirmek için birkaç girişimde bulunuldu. Aşağıda, en başarılı vakalardan bazılarını güçlü ve zayıf yönleriyle birlikte inceleyeceğiz.

Şifre Yöneticileri

Parola Yöneticilerinin varlığı, parolaların temel kusurlarının bir çoğunun kabul edildiğini gösterir. Kullanıcıyı yeterince karmaşık şifreler oluşturmak ve hatırlamak zorunda bırakmadan özgürleştirerek durumu iyileştirmeye çalışırlar, böylece çok daha yüksek bir güvenlik titizliği sağlayan tek amaçlı şifreler sağlar.

Doğru kullanıldığında, Parola Yöneticileri güvenliği ve sınırlı ölçüde parola tabanlı kimlik doğrulamalı sistemlerin kullanılabilirliğini arttırır. Ancak, günümüzün şifre yöneticisi yazılımı yinelemelerini kullanmak için ebeveynlerine, çocuklarına veya teknik olmayan arkadaşlarına öğretmeye çalışan herhangi biri, ne yaygın bir şekilde benimsemiş olduklarına ya da yeterince kullanılamaz olduklarına acı çekiyor.

Teknik açıdan bakıldığında, şifre yöneticileri için standartlar yoktur. Bir kullanıcı ne zaman hesap oluşturduğunu, giriş yaptığını veya şifresini daha kolay olması için güncellediğini tahmin etmeye çalışır, ancak genellikle başarısız olurlar. Gelişmiş bir çözüm için temel sağlarlar, ama sonuçta, onlar hala sadece şifrelerdir ve hala Hearsay Problemine ve The Blank Check Problemine tabidirler.

İki Faktör Kimlik Doğrulama

Parolaların zayıflığının farkına varılması için, parolanın kendisinin tek bir başarısızlık noktası olmadığından emin olmak için ek güvenlikle ilgili girişimlerde bulunulmaya çalışıldı. Bu yaklaşım genellikle ikinci bir faktör veya iki faktörlü kimlik doğrulama (2FA) olarak adlandırılır. 2FA'nın çeşitli uygulamaları vardır ve hepsi şifre tabanlı kimlik doğrulama sistemlerine farklı derecelerde artımlı güvenlik eklerken, kurulum ve son kullanıcı çalışması açısından ek karmaşıklık ile telafi ederler. Yaygın bir 2FA çözümü, zamana dayalı bir kerelik şifreler (OTP) sağlamak için SMS mesajlarına dayanır. Parolaların kendileri gibi, iki faktörlü çözümler de denetlenememeleri ve cihazınıza SMS mesajlarını ileten telefon taşıyıcılarının güvenlik uygulamalarına açık olma sorunlarından muzdariptir.

Bu kanıtlanabilir denetlenebilirlik eksikliği, 2FA'nın Hearsay Problemini veya Blank Check Problemini hala çözemediği anlamına gelir.

WebAuthn Standardı

WebAuthn, World Wide Web Konsorsiyumu (W3C), uluslararası bir üye kuruluşlar topluluğu, tam zamanlı bir personel ve kamuoyu tarafından Web standartlarını geliştirmek için birlikte çalışan yeni bir kimlik doğrulama standardıdır. WebAuthn, web tabanlı işlemler için tüm bu sorunların şifreler yerine asimetrik şifreleme kullanarak çözülmesine çok yaklaştı ve ana hatlarıyla belirttiğimiz sorunların üstesinden gelmek için gerekli bileşenlerden birini sağladı. Ancak, cihazlarını kaybeden kullanıcıların her hizmetten kilitlenmelerini önlemek için, WebAuthn değiştirme yerine şifrelerle birlikte kullanılmak üzere tasarlanmıştır.

WebAuthn'un bir diğer önemli önemli kısıtı, onayın kanıtı olarak değil, bir varlık kanıtı olarak tasarlanmasıdır. Eşler tarafından denetlenebilir işlem başına yetkilendirme isteklerine izin vermek tanımlanmamıştır. Dolayısıyla, bir kez daha, WebAuthn’a dayanan sistemler kanıtlanabilir denetim kayıtlarına sahip değildir ve hem Hearsay Problemine hem de The Blank Check problemine tabidir.

Potansiyel Bir Çözüm Olarak Blockchain

Blokajlar, bu amaca ulaşmak için işlemlerin ortak anahtar şifreleme imzasını kullanarak, yetkilendirdikleri her işlem için kullanıcının kimliğini doğrulama fikrini popüler hale getirmiştir. Bu, şifreler üzerinde büyük bir gelişme ve WebAuthn’un sağlayabileceğinin ötesinde bir adımdır. Ayrıca, Hearsay Problemini ele almak için gereken ilk faktörü de karşılar: kanıtlanabilir denetlenebilirlik.

Maalesef, günümüzün blok zinciri kullanıcı arayüzleri, kullanıcılara yetkilendirme taleplerini kullanıcı dostu bir şekilde açıklamak için bir standart tanımlamamaktadır, böylece kullanıcı onayı için güvenilir bir bağlamda gösterilebilirler. Bu insan dostu istek oluşturma standardı olmadan kullanıcılar neyi kabul ettiklerini bilemezler. Bu, blokajların ispatlanabilir bir denetlenebilir kütük oluşturmasına rağmen, bir sistem içindeki verilerin gerçekte kullanıcının amacını temsil ettiğini kanıtlama araçlarının bulunmadığı anlamına gelir. Bu nedenle, hala Hearsay ve Blank Check sorunlarına maruz kalmaktadırlar.

Sosyal medya örneğimize geri dönersek, eğer bir blokaj üzerine bir sosyal medya platformu inşa edildiyse, söz konusu politikacının aslında postta sonuçlanan eylemi imzaladığını ispatlayabileceklerini ancak ispatlayamayacaklarını ispatlayabileceklerdi. Onların (ya da başka bir partinin) politikacıyı yanlış beyan ederek eylemi imzalamaları için kandırmadılar.

Teorik Bir Çözüm: Anahtarlar veya Şifreler yerine “Başarılı”

Sistemlerimizin güvenliğini arttırmak için, şifreleri bile aşan bir basitlik ve kullanılabilirlik seviyesi ile birlikte, kullanıcı onay belgesine ihtiyacımız var. Bu, asimetrik kriptografi gibi karmaşık teknolojileri, yalnızca teknoloji uzmanları için değil, her kullanıcı için hemen anlaşılabilir bir metafor aracılığıyla iletmemiz gerektiği anlamına gelir. Bu kriterleri karşılayan bir kavram “geçiş” kavramıdır. Bir geçiş kavramını açıklarken, bir Geçiş Yöneticisi Uygulamasında kullanılan bir geçişin bu teorik çözümünün hem Hearsay Problemini hem de ana hatlarıyla belirttiğimiz Boş Kontrol Problemini nasıl karşılayabileceğini göstereceğiz.

Kullanıcılar için bir geçiş, bir kimlik bilgisine sahip olduğunu kanıtlamanın tanıdık ve somut bir yolunu temsil eder. Her gün günlük rutinlerimizin bir parçası olarak fiziksel geçişlerle etkileşime geçiyoruz. Bir kütüphane kullanıcısı olarak kütüphane kartınızı gösterip sunarsınız. Bir havayolu yolcu olarak, biletinizi gösterip sunarsınız. Bunlar, tek amaçlı geçiş örnekleridir, tek amaçlı geçiş sağlamayan hizmetler için kimliğinizi kanıtlamak için Sürücü Belgenizi sunabilirsiniz.

Kimlik doğrulama ve yetkilendirme kullanım durumlarını desteklemek için, dijital “Geçiş Yöneticisi” kavramını tanıtıyoruz. Bir Geçiş Yöneticisi, kayıt, kimlik doğrulama ve yetkilendirme kullanım durumları için şifresiz bir paradigmadır.

Bir Pass Manager ile ne yapabilirdiniz?

İhraç ve İptal

  • Servis Sağlayıcılar Geçiş Yöneticisinden bir kullanıcı için yeni bir geçiş düzenlemesini talep edebilirler.
  • Kullanıcılar geçiş kartlarını gruplara ayırabilir. (örneğin işim geçer ve kişisel geçerim)
  • Kullanıcılar birden fazla cihazdan geçişleri yetkilendirebilir ve yetkileri kaldırabilir.

Kimlik Doğrulama

  • Servis Sağlayıcılar, bir kullanıcının bir pasa sahip olduğuna dair kanıt isteyebilir.
  • Kullanıcılar bir pasa sahip olduklarını kanıtlayabilirler.

yetki

  • Servis Sağlayıcılar, kullanıcının sahip olduğu bir geçiş yetkisi üzerine, kullanıcının belirli bir işlemi gerçekleştirme yetkisinin kanıtını isteyebilir.
  • Kullanıcılar, insan dostu bir şekilde açıkça ifade edilen yetkilendirme isteklerini görebilir ve sahip oldukları bir geçiş yetkisi üzerine eylemi onaylayıp onaylamamayı seçebilirler.

Bir Pass Manager nasıl çalışır?

Bir Geçiş Yöneticisi, geçişlerin düzenlenmesi ve iptali, kimlik doğrulaması ve geçiş belgelerinin onaylanması için standartlaştırılmış bir protokol uygular. Bir Geçiş, kimlik bilgilerini (anahtarlar) içeren kavramsal bir soyutlamadır.

Dijital Geçiş Yöneticisi kullanma deneyimi, geçiş kartlarının fiziksel analoguna çok benzer olmalıdır. Kullanıcı basitçe bir servise ulaşır (ister web uygulaması, ister yerel bir uygulama, bir satış noktası sistemi veya bir kiosk olsun) ve bir oturum açmak veya yetkilendirmek için bir onay sunar. Bu, bir üniversite öğrencisine spor etkinliğine kabul etmek için Kolej Kimliğini kullanarak, daha sonra bir kez içeride, kampüs yemek bakiyesi ile standında yiyecek satın almak, işlemleri gerçekleştirmeden önce sipariş onaylarını almak amacıyla bir üniversite öğrencisi gibidir.

Davlumbazın altında, teknolojilerin bir karışımı, şifreleme imzası, donanım anahtarları ve kimlik bilgisi güvenliği için biyometri ve ayrıca taşınabilirlik için taşıma için agnostik bir protokol de dahil olmak üzere, kullanıcılar için üstün güvenlik ve kullanılabilirlik üretmek için birlikte çalışabilir.

Bir kullanıcının izni ne zaman bir Geçiş Yöneticisi tarafından aranırsa, eylemin insan dostu tanımlamaları kullanıcıya gösterilmeli ve bu açıklama (veya şifreli olarak doğrulanabilir bir türevi) Geçiş Yöneticisinin imzalı cevabına dahil edilmelidir. Anahtarların kullanımı, günlüklerin geri çevrilemez olduğu ve üçüncü taraflarca doğrulanabileceği anlamına gelir ve imzalı yanıttaki insan dostu açıklamanın dahil edilmesi kullanıcının amacının kanıtı olabilir. Bu özellikler hem Hearsay hem de Blank Check sorunlarını çözer.

Bu model hem mevcut web teknolojisini hem de gelecekteki blockchain teknolojisi kullanım durumlarını destekleyebilir. Aynı zamanda hem giriş hem de yetkilendirme kullanım durumları için açık bir kullanıcı deneyimi sunma yeteneğine de sahiptir.

Başarılı Yöneticileri başarılı kılmak için neler gereklidir?

Birlikte çalışabilirlik

Öncelikle ve en önemlisi, kullanıcıların ihtiyaçlarına en uygun Pass Manager'ı seçme özgürlüğünü sağlamak için bir Pass Manager protokolü oluşturulmalıdır. Bu önemlidir, çünkü hem güvenlik hem de kullanıcı deneyiminde yeniliği teşvik etmek için gerekli olan serbest piyasayı yaratarak satıcının kilitlenmesini önler. Bu şekilde, kabul edilebilir güvenlik ile en iyi kullanıcı deneyimi kazanacaktır.

Bu seçim özgürlüğünü sağlamak için, kaydolma, giriş yapma ve yetkilendirme için standart protokoller olması gerekecektir. Özellikle, yetkilendirme ilginç bir zorluktur, çünkü kullanıcılara yetkilendirme taleplerini anlaşılabilir, denetlenebilir, kanıtlanabilir ve taşınabilir bir şekilde tanımlamak için bir standart tanımını gerektirir.

taşınabilirlik

İkinci olarak, Geçiş Yöneticisi protokolü taşınabilirlik için oluşturulmalıdır; anlam: 1) herhangi bir platformda çalışan her türlü uygulama veya hizmet için destek, 2) sınırlı veya hiç ağ bağlantısı için destek, 3) birden fazla cihaz için destek ve 4) çapraz cihaz iletişimi için destek.

Kullanıcıların masaüstü bilgisayarları, dizüstü bilgisayarları, telefonları, tabletleri, akıllı saatleri ve USB anahtarları vardır. Bu nedenle, birden fazla cihazdan geçiş erişimini vermek ve iptal etmek için basit ve kesintisiz bir deneyim önemlidir. Kullanıcılar ayrıca satış noktası sistemleri, güvenilmeyen kamu bilgisayarları, satış makineleri ve kiosklarla etkileşime girer. Bu nedenle, cihazların birbirine güvenmesine gerek kalmadan, bir cihazdan diğerine, ağ bağlantısıyla veya ağ bağlantısı olmadan etkileşimde bulunabilmek gerekir.

Bu gereksinimler, taşıma için agnostik olacak Pass Manager protokolü tanımlanarak karşılanabilir. Bu, protokolün, uygulama sistemlerinin akıcı biçimde konuşabilmesi gereken isimleri ve fiilleri tanımlamaya odaklanmalı ve konuşulan nakliyelerin değişmesine izin vermelidir. Aktarma örnekleri arasında özel protokol URL'leri, Apple Evrensel Bağlantıları, Android Amaçları, sunucu istekleri, QR kodları, Bluetooth, NFC ve JavaScript API'leri bulunabilir. Bu esneklik sayesinde, Geçiş Yöneticileri gerçekten taşınabilir olabilir.

Kullanılabilirlik

Kullanıcıların, bir web servisini bir veritabanı arka ucuyla mı yoksa bir blok zinciri sistemiyle mi kullandıklarının sonuçlarını göz önünde bulundurmaları gerekmemelidir. Blockchain söz konusu olduğunda, kullandıkları uygulamanın hangi blockchain platformunu veya ağını kurduğunu bilmeleri gerekmemelidir. Sadece kullanım durumlarını göz önünde bulundurmaları gerekir. Gibi şeyler…

“Bir ATM'den para çekiyorum.”

“E-posta adresime giriş yapıyorum”

“Sosyal medyada bir yazıyı beğeniyorum.”

“Otomat makinesinden cips alıyorum.”

“Dan'den Brian'a 100 jeton aktarıyorum.”

Asla gibi şeyler…

“Blockchain11 hesabım için yetkilendirilmiş bir R1 anahtarıyla, EOSIO platformunda kurulan Telos blockchain üzerine kurulu example.com dapp üzerinde bir işlem imzaladım.”

Emniyet

Hem şifreler hem de ortak anahtar sistemlerinin mevcut uygulamaları çeşitli nedenlerden dolayı güvensizdir. Geçiş Yöneticileri daha iyisini yapmalıdır.

Kullanıcıları merkezi kimlik bilgileri honeyPots saldırılarına karşı korumak için, gizli kimlik bilgileri hiçbir zaman merkezi altyapıya hiçbir şekilde depolanmamalıdır (karma ve tuzlama yeterli değildir). Kullanıcıların kimlik bilgilerini kimlik avı, kötü amaçlı yazılım ve ortadaki adam saldırılarıyla çalınmasını önlemek için, kullanıcılar kimlik bilgilerinin ne olduğunu asla bilmemeli ve hiçbir zaman el ile veya otomatik olarak herhangi bir hizmete girilmemelidir. Kullanıcıları kötü amaçlı geçişler eklemeye kandırılmaktan korumak için kullanıcılar kendilerine geçiş ekleyemez veya kaldıramazlar. Bunun yerine, güvenilir bir Pass Manager bunu, kullanıcının yeni hizmetleri ziyaret etmesine veya yeni cihazlar almasına yanıt olarak kullanıcı adına otomatik olarak işlemelidir.

Gelecek Geçiş Yöneticileri İçin Geniş Açık

Bu yazıda, kullanıcı hesaplarını güvence altına almak için mevcut son teknoloji yöntemlerle güvenlik ve kullanılabilirlik konularını ele almak için çözülmesi gereken sorunları ortaya koyduk. Bu problemleri çözmenin bir yolu olarak şifreleri değiştiren Passes ve dijital Pass Manager konseptini sunduk. Başarılı olmak için bir Pass Manager protokolünün gerekli özelliklerini tartıştık, ancak protokolü açıkça tanımlamadık. Girişimci geliştiricilerin hem parola hem de anahtar tabanlı güvenlik sistemlerini rahatsız eden sorunları çözmelerini ve Geçiş metaforunu bu amacı gerçekleştirmenin bir yolu olarak görmelerini teşvik ediyoruz.

Feragatname: Block.one, EOSIO topluluğunun bir üyesi olarak gönüllü olarak katkıda bulunur ve yazılımın veya ilgili uygulamaların genel performansını sağlamaktan sorumlu değildir. Burada açıklanan sürümler, ilgili GitHub sürümü, EOSIO yazılımı veya herhangi bir garanti, satılabilirlik de dahil olmak, ancak bunlarla sınırlı olmamak kaydıyla, açıkça belirtilmiş veya zımni olarak herhangi bir beyan, garanti, garanti veya taahhütte bulunmamaktayız. amaç ve ihlal etmemek. Hiçbir durumda, herhangi bir sözleşmeden, yazılımdan veya dokümantasyondan, yazılımdan veya dokümantasyondan kaynaklanan veya bunlardan kaynaklanan veya bunlarla bağlantılı veya herhangi bir şekilde yapılacak herhangi bir iddia, tazminat veya diğer sorumluluktan sorumlu değiliz. dokümantasyon. Herhangi bir test sonucu veya performans rakamları gösterge niteliğindedir ve her koşulda performansı yansıtmaz. Herhangi bir üçüncü tarafa veya üçüncü taraf ürüne, kaynağa veya hizmete yapılan herhangi bir referans, Block.one tarafından bir onay veya öneri değildir. Bu kaynaklardan herhangi birini kullanma veya bunlara güvenmenizden sorumlu değiliz ve hiçbir sorumluluk kabul etmiyoruz. Üçüncü taraf kaynakları herhangi bir zamanda güncellenebilir, değiştirilebilir veya sonlandırılabilir, bu nedenle buradaki bilgiler güncel olmayabilir veya yanlış olabilir. Bu yazılımı üçüncü taraflara yazılım, mal veya hizmet sağlamakla bağlantılı olarak kullanan veya sunan kişi, bu lisans koşullarının üçüncü taraflarına, feragatnamelere ve sorumlulukların hariç tutulmasına ilişkin tavsiyelerde bulunacaktır. Block.one, EOSIO, EOSIO Labs, EOS, heptahedron ve ilgili logolar Block.one'un ticari markalarıdır. Burada referans verilen diğer ticari markalar ilgili sahiplerinin mülkiyetindedir. Lütfen buradaki ifadelerin, Block.one’un vizyonunun bir ifadesi olduğunu, hiçbir şeyin garantisi olmadığını ve tüm yönlerinin Block.one’un tamamen kendi takdirine bağlı olarak değişebileceğini unutmayın. Bu belgede, EOSIO’nun gelişimi, beklenen performansı ve gelecekteki özellikleri ile ilgili açıklamalar veya iş stratejimiz, planlarımız, umutlarımız, gelişmelerimiz ve hedeflerimiz gibi tarihsel gerçeklerin ifadeleri dışında bu belgede bulunan ifadeleri içeren bu “ileriye dönük ifadeler” olarak adlandırıyoruz. Bu ifadeler yalnızca öngörülerdir ve Block.one’un gelecekteki olaylarla ilgili mevcut inanç ve beklentilerini yansıtır; varsayımlara dayanırlar ve herhangi bir zamanda risk, belirsizlik ve değişime maruz kalırlar. Hızla değişen bir ortamda çalışıyoruz. Zaman zaman yeni riskler ortaya çıkar. Bu riskler ve belirsizlikler göz önüne alındığında, ileriye dönük ifadelere güvenmemeniz konusunda uyarılırsınız. Gerçekleşen sonuçlar, performans veya olaylar ileriye dönük açıklamalarda öngörülenlerden önemli ölçüde farklı olabilir. Gerçek sonuçlara, performansa veya olaylara ileriye dönük ifadelerden önemli ölçüde farklılık göstermesine neden olabilecek faktörlerden bazıları, bunlarla sınırlı olmamak üzere: piyasa oynaklığı; sermaye, finansman ve personel mevcudiyetine devam edilmesi; ürün kabulü; herhangi bir yeni ürün veya teknolojinin ticari başarısı; rekabet; devlet düzenlemeleri ve yasaları; ve genel ekonomik, pazar veya iş koşulları. Tüm beyanlar yalnızca ilk gönderim tarihi itibariyle geçerlidir ve Block.one, yeni bilgiler, sonraki olaylar veya başka herhangi bir ifadenin sonucu olarak veya herhangi bir beyanda bulunma, güncelleme veya değiştirme yükümlülüğü altında değildir. Buradaki hiçbir şey, genel olarak veya herhangi bir özel durum veya uygulama ile ilgili olarak teknolojik, finansal, yatırım, yasal veya başka bir tavsiye niteliğinde değildir. Bu belgede yer alan herhangi bir şeyi uygulamadan veya kullanmadan önce lütfen uygun alanlardaki uzmanlara danışın.