Web3Auth exists to make digital ownership and identity human-centric and accessible to everyone

Web3Auth

web3auth

What's Inside Play to Earn

ইনসাইড কি আছে উপার্জন করতে খেলুন

Was ist drin? Spielen Sie, um zu verdienen

¿Qué hay dentro de Play para ganar?

Qu'y a-t-il à l'intérieur du jeu pour gagner

अंदर क्या है खेलो और कमाओ

プレイして稼ぐ内容

무엇이 들어있나요? 플레이해서 수익을 얻으세요

O que há dentro Jogue para ganhar

На чем можно заработать в Inside Play

Kazanmak İçin Oynamanın İçinde Neler Var?

Có gì bên trong Chơi để kiếm tiền

玩赚游戏有什么用

In an era where digital security is paramount, Shamir's Secret Sharing (SSS) stands as a revolutionary technique, offering robust protection for sensitive data. This cryptographic method, developed by , is not just a tool but a safeguard, ensuring that a secret is not just hidden but also shared securely. Adi Shamir In this article, we delve into the ingenious mechanics of SSS, exploring its foundations in polynomial mathematics and its practical applications in securing data, from corporate secrets to personal credentials. In our case, we will save credentials for the user account, aka mnemonic phrase. This article will be divided into several digestible parts. Ultimately, we will create one service for working with SSN, which includes the following microservices: Auth: for exchanging a JWT token for an internal identifier Generator: This gives the user addresses where he can get his parts of the key Shares: that is responsible for storing shares Metadata:  responsible for storing other information necessary for work Disclaimer: When I was creating this service, I was very much inspired by these guys: , so for production development, I would recommend them more and use a self-written service only if there is a security audit that will analyze each of your actions. Our company uses a self-written solution for several reasons, one is that it is better to have your own solution in conditions of modern uncertainty. We were audited by the Hallward company, and I hope that we will soon be able to open-source our implementation https://web3auth.io/safeauth.html In the first part (part 0), I want to dive into SSS in a basic way and show the basic formulas for working with polynomial mathematics using JavaScript as usual Part 1. will contain works with auth and generator microservices. We will change the user JWT token into our token, check some credentials for using our service, and choose where they will be stored user shares. Part 2. In this chapter, I’m going to dive into the storage part of our service First and most important - safely storing user's share into the blockchain Second, store other user's data into metadata microservice, aka blockchain 2. Principles Shamir's Secret Sharing (SSS), developed by Adi Shamir in 1979, is a cryptographic method that divides a secret into multiple parts, known as "shares." The fundamental idea behind SSS is that the secret can only be reconstructed when a sufficient number of these shares are combined. Here's a breakdown of how it works: : The process begins with creating a polynomial of degree , where is one less than the number of shares required to reconstruct the secret (known as the threshold). For example, if the threshold is 3, a polynomial of degree 2 (quadratic polynomial) is created. The secret is embedded as the polynomial's constant term (coefficient a_0), and the other coefficients (a_1 to ) are randomly generated. Polynomial Construction d d a_d : The polynomial is then evaluated at several points (other than zero) to generate the shares. Each share consists of two parts: the point at which the polynomial is evaluated (x-value) and the corresponding value of the polynomial at that point (y-value). For a threshold of , at least distinct points are chosen, and their corresponding polynomial values are calculated, forming shares. Generation of Shares n n n : These shares are distributed to the participants. No single participant can reconstruct the secret with their share alone. Distribution of Shares : When it's necessary to reconstruct the secret, a minimum of shares (as per the threshold) is brought together. The original polynomial is reconstructed using these shares, typically using a method like Lagrange interpolation. Reconstruction of the Secret n : Once the polynomial is reconstructed, the secret can be found by evaluating the polynomial at zero, which gives the constant term of the polynomial – the original secret. Retrieving the Secret Key Properties of SSS: : The threshold can be set according to the level of security needed. The secret can only be reconstructed if the threshold number of shares is combined. Threshold Flexibility : As long as the threshold is not met, even having access to −1 shares gives no information about the secret, assuming the polynomial coefficients are chosen randomly and securely. Security n : Loss of some shares does not compromise the entire system. The secret can be reconstructed if the threshold number of shares is available. Error Tolerance : Since the secret is not stored in a single location but instead distributed across multiple shares, the risk associated with a single point of failure is mitigated. No Single Point of Failure SSS is beneficial when security and reliability are paramount, such as securing cryptographic keys, safeguarding access to critical digital assets, or other cases you can imagine yourself. Formulation of the problem About number schemas: we can use different threshold values, but we need to know that the more parts of the key we create, the more likely a hacker will obtain the required number of key parts and assemble the original key. In our service, we will use the following schemas for storing data: On the user’s side, we will use scheme 3-2. This means that the private key will be divided into 3 different parts with indexes. And to restore the original private key, we need at least 2 of them. For further convenience, I suggest using the following names for our 3 parts: Social share: this share will be again divided into some parts and stored between different share nodes User share: this share should be stored on the user side (for example, if we use a browser, it can be localStorage or different storage), and we don’t need to encrypt it cloud share. This share can be saved everywhere by a user. We can present this share as a mnemonic phrase or store it on the web, but before we do it, we need to encrypt this share with a password or a different method that allows us to get the original value for the share. As mentioned, the user needs only 2 of 3 shares to work with a private key. For example, if a user has “user share” and “cloud share”, he doesn’t need to get “social share” for work, or if he restores on a new device or browser, he needs “social share” and “cloud share” On the backend for “social share” we will use 5-3. This means that we divide social share into 5 parts, and to restore the original key, we need only 3 of them. And all of them will be saved on different storages. As has been said earlier, our service is built from 4 microservices: Auth, Generator, Shares, and Metadata. Shares service can be stored by different participants of our service. In a perfect world, it should have different providers for deploy different storage like PostgreSQL, Ethereum smart contract, and others (in our solution, we will use only smart contracts), But no one is limited to choose their own storage. How it works First, users need a JWT token; for example, it can be taken from auth with Google or Apple auth services. After we get JWT, we exchange it for an internal JWT token. Why so hard? Good question. One of this service's central ideas is decentralization, which applies to the blockchain and the service for storing private key shares. However, we are not going to share the user's credentials with external services, and for this reason, we change the actual identifiers to internal. Also, we checked the credentials that only allowed OAuth providers to be limited. Now, we will check whether there is a saved key; if not, we suggest creating it. After creation, we divide one of the parts into five according to the same principle and distribute them between services and save the critical index, save another part, the locale, and offer the third part to be held somewhere by the user (there are a lot of options on how this can be done) If we understand that the user has already saved his private key, go to the shares service and get a list of services where the user shares and their indexes are stored. Get shares. After Lagrange interpolation, we have the first part of the share. But we don’t know its index. Here, the metadata service comes to our aid, from which, based on the key we receive, we will receive the index of this very key. The next step is to find the locally stored part or ask the user to provide it. We restore the original private key if we receive the required number of critical parts. A little bit of code Initially, I did not plan the code for this part of the article, but I still decided that the essential functions for working with Lagrange interpolation would look very nice here since it underlies the entire project. export class Polynomial {
    shares: BN[];
    polynomialId: string;

    static initialize(
        privateKey: BN | Buffer | null,
        threshold: number,
    ) {
        const pk = privateKey ? privateKey : randomBytes(32);

        const shares = [new BN(pk)];

        for (let i = 1; i < threshold; i += 1) {
            const share = randomBytes(32);
            shares.push(new BN(share));
        }

        const polynomialId = keccak256(...shares.map(bn => bn.toString()));

        return new Polynomial(shares, polynomialId);
    }

    static fromShares(shares: Share[]) {
        const unsortedPoints = shares.map<PolynomialPoint>(s => ({
            x: new BN(s.shareIndex, 'hex'),
            y: new BN(s.share, 'hex'),
        }));
        const sortedPoints = pointSort(unsortedPoints);
        const polynomial = generateEmptyBNArray(sortedPoints.length);
        for (let i = 0; i < sortedPoints.length; i += 1) {
            const coefficients = interpolationPoly(i, sortedPoints);
            for (let k = 0; k < sortedPoints.length; k += 1) {
                let tmp = new BN(sortedPoints[i].y);
                tmp = tmp.mul(coefficients[k]);
                polynomial[k] = polynomial[k].add(tmp).umod(curveN);
            }
        }

        const polynomialId = keccak256(...polynomial.map(bn => bn.toString()));

        return new Polynomial(polynomial, polynomialId);
    }

    constructor(shares: BN[], polynomialId: string = '') {
        this.shares = shares;
        this.polynomialId = polynomialId;
    }

    getPrivateKey(): BN {
        return this.shares[0];
    }

    getShare(x: string | BN): Share {
        const tmpX = new BN(x, 'hex');
        let xi = new BN(tmpX);
        let sum = new BN(this.shares[0]);
        for (let i = 1; i < this.shares.length; i += 1) {
            sum = sum.add(xi.mul(this.shares[i]));
            xi = xi.mul(tmpX);
        }
        return {
            share: sum.umod(curveN)?.toString('hex')?.padStart?.(64, '0'),
            shareIndex: tmpX.toString('hex'),
            polynomialID: this.polynomialId,
        };
    }
}

const pointSort = (innerPoints: PolynomialPoint[]): PolynomialPoint[] => {
    const pointArrClone = [...innerPoints];
    pointArrClone.sort((a, b) => a.x.cmp(b.x));
    return pointArrClone;
};

const generateEmptyBNArray = (length: number): BN[] =>
    Array.from({length}, () => new BN(0));

const denominator = (i: number, innerPoints: PolynomialPoint[]) => {
    let result = new BN(1);
    const xi = innerPoints[i].x;
    for (let j = innerPoints.length - 1; j >= 0; j -= 1) {
        if (i !== j) {
            let tmp = new BN(xi);
            tmp = tmp.sub(innerPoints[j].x).umod(curveN);
            result = result.mul(tmp).umod(curveN);
        }
    }
    return result;
};

const interpolationPoly = (i: number, innerPoints: PolynomialPoint[]): BN[] => {
    let coefficients = generateEmptyBNArray(innerPoints.length);
    const d = denominator(i, innerPoints);
    if (d.cmp(new BN(0)) === 0) {
        throw new Error('Denominator for interpolationPoly is 0');
    }
    coefficients[0] = d.invm(curveN);
    for (let k = 0; k < innerPoints.length; k += 1) {
        const newCoefficients = generateEmptyBNArray(innerPoints.length);
        if (k !== i) {
            let j: number;
            if (k < i) {
                j = k + 1;
            } else {
                j = k;
            }
            j -= 1;
            for (; j >= 0; j -= 1) {
                newCoefficients[j + 1] = newCoefficients[j + 1]
                    .add(coefficients[j])
                    .umod(curveN);
                let tmp = new BN(innerPoints[k].x);
                tmp = tmp.mul(coefficients[j]).umod(curveN);
                newCoefficients[j] = newCoefficients[j].sub(tmp).umod(curveN);
            }
            coefficients = newCoefficients;
        }
    }
    return coefficients;
}; Main class is which have 2 static methods: Polynomial : Creates a new polynomial with a specified number of shares. If is not provided, it generates a random one. Each share is a random 32-byte number, and the is computed using hash of the shares. initialize(privateKey, threshold) threshold privateKey polynomialId keccak256 : Constructs a polynomial from given shares. It sorts these shares, performs polynomial interpolation, and computes a . fromShares(shares) polynomialId in current scheme used for create unique identifier of our shares polynomialId And 2 Instance Methods: : Returns the first share, which is presumably the private key. getPrivateKey() : Computes and returns a specific share of the polynomial, given an input . getShare(x) x Helper Functions: : Sorts an array of objects based on their values. pointSort(innerPoints) PolynomialPoint x : Generates an array of objects initialized to zero, of the specified . generateEmptyBNArray(length) BN length : Helper for calculating the denominator in the Lagrange polynomial interpolation. denominator(i, innerPoints) : Computes the coefficients for the Lagrange interpolation polynomial for a given point. interpolationPoly(i, innerPoints) I understand that so far it all looks quite crumpled and chaotic, but still at least something =) For a better understanding of the theory, I recommend taking a look at (or another favorite source of information) Wikipedia Conclusion In this article, we took a superficial look at the operating principle of the future service and determined the scope of work that needs to be done in the following articles (tentatively, there will be two more) See you next time =)

Utilizing the Mechanics of Shamir's Secret Sharing Service

BENGALURU, India, November 2nd, 2023/Chainwire/-- (IBW), the country’s flagship series of blockchain and Web3 events held in Bangalore from Dec.4-10, is thrilled to announce the speaker lineup for the main IBW Conference. India Blockchain Week The conference’s headline speakers include Polygon Co-Founder Sandeep Nailwal, Aptos Co-Founder Mo Shaikh, Ava Labs Founder & CEO Dr. Emin Gün Sirer, TRON Co-Founder Justin Sun, and The Sandbox Co-Founder Sebastien Borget. Additional notable speakers will be Rene Reinsberg (Co-Founder of Celo) Prabhakar Reddy (Co-Founder of FalconX), Aniket Jindal (Co-Founder of Biconomy), Zhen Yu Young (Co-Founder of Web3Auth), Irene Wu (Head of Strategy at LayerZero), Manish Agarwal (CEO at IndiGG), Dr. Kang Li (Chief Security Officer at Certik), Simon Kim (CEO & Managing Partner at Hashed), Kelvin Koh (Co-Founder & Managing Partner of Spartan) among many others. Taking place at the Sheraton Grand in Bangalore on December 6-7, the IBW’23 Conference will have 100+ innovators, entrepreneurs, decision-makers and thought leaders across the entire spectrum of the blockchain industry engaged in keynote speeches, panel discussions, fireside chats, and moderated debates. For example: Sandeep Nailwal will engage in a fireside chat, discussing the current progress and future of Polygon 2.0, and sharing insights about the Indian Web3 ecosystem Mo Shaikh will deliver a keynote speech focused on the Move ecosystem and how Aptos enhances scalability and speed to enhance user experience Dr. Emin Gün Sirer will participate in a fireside chat, discussing strategies for fostering Web3 adoption through subnets and Avalanche's India strategy. Justin Sun will have a virtual fireside chat, delving into general crypto trends and offering perspectives on global regulation, stablecoins, and the Tron ecosystem. Sebastien Borget, in his keynote speech, will explore the future of the Metaverse and how brands can unlock value in digital worlds and their massive plans for India. “India is taking full advantage of Web3 technology across industries like social media, entertainment, commerce, and open financial systems”, said Mo Shaikh, Co-Founder & CEO of Aptos Labs. “The Aptos India ecosystem, growth and community is already expanding on a daily basis faster than most others. Our global enterprise partners are taking notice of the blend of market maturity and innovation happening across the country. We are dedicated to the expansion of Web3 in India and look forward to Aptos being a catalyst for the decentralized movement.” Besides the two-day headline conference, the week-long Web3 festival will feature other prime Web3 events such as ETHIndia, Polygon Connect, Polkadot Pulse, FILBangalore and many more. This is a unique opportunity to engage with emerging talent, attract new developers to the blockchain arena, and expand the blockchain ecosystem in India. "We're launching India Blockchain Week (IBW) because we see the synergy between India and Blockchain as not just a game-changer, but our collective destiny," said Tak Lee, CEO of Hashed Emergent, host of the India Blockchain Week (IBW) Conference. About India Blockchain Week (IBW) India Blockchain Week (IBW) is a series of blockchain and web3 events, spanning from 4-10 December 2023 across Bangalore, India. IBW is a week-long array of 50+ web3 events, including flagship events such as the headline IBW Conference, ETHIndia, Polygon Connect, Polkadot Pulse, FILBangalore and many other side-events, networking events, workshops, parties etc hosted by Indian & global blockchain industry stakeholders. The IBW Conference is the two-day headline event anchoring India Blockchain Week (IBW) on 6-7 December 2023 at the Sheraton Grand, Bangalore and hosted by Hashed Emergent - a team and brand dedicated to accelerating the mass adoption of Web3 in India. For more information about IBW, visit: | | | Website Twitter LinkedIn Telegram Contact Irshad Ahmed gm@indiablockchainweek.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program . here

Sandeep Nailwal, Mo Shaikh, Dr. Emin And Justin Sun To Speak At India Blockchain Week

সন্দীপ নেইলওয়াল, মো শেখ, ডাঃ এমিন এবং জাস্টিন সান ইন্ডিয়া ব্লকচেইন সপ্তাহে বক্তৃতা করবেন

Sandeep Nailwal, Mo Shaikh, Dr. Emin und Justin Sun sprechen auf der India Blockchain Week

Sandeep Nailwal, Mo Shaikh, Dr. Emin y Justin Sun hablarán en la India Blockchain Week

Sandeep Nailwal, Mo Shaikh, le Dr Emin et Justin Sun prendront la parole à la semaine indienne de la blockchain

संदीप नेलवाल, मो शेख, डॉ. एमिन और जस्टिन सन इंडिया ब्लॉकचेन वीक में बोलेंगे

サンディープ・ネイルワル氏、モー・シャイク氏、エミン博士、ジャスティン・サン氏がインドブロックチェーンウィークで講演

Sandeep Nailwal, Mo Shaikh, Dr. Emin 및 Justin Sun이 인도 블록체인 주간에서 연설합니다

Sandeep Nailwal, Mo Shaikh, Dr. Emin e Justin Sun falarão na India Blockchain Week

Сандип Наилвал, Мо Шейх, доктор Эмин и Джастин Сан выступят на Неделе блокчейна в Индии

Sandeep Nailwal, Mo Shaikh, Dr. Emin ve Justin Sun Hindistan Blockchain Haftasında Konuşma Yapacak

Sandeep Nailwal, Mo Shaikh, Tiến sĩ Emin và Justin Sun sẽ phát biểu tại Tuần lễ Blockchain Ấn Độ

Sandeep Nailwal、Mo Shaikh、Emin 博士和孙宇晨将在印度区块链周上发表演讲

Content Overview What is dApp? What client-side technologies should be used for a dApp? Which type of domain should you choose? Authentication: MetaMask's Dark Side Blockchain Selection: Which Chains Are Best for dApps? Funding Your Idea Through Grants What is dApp? The commonly accepted definition of a is, in short, an application that can operate autonomously using a distributed ledger system. At first glance, it seems straightforward. But, when you begin to question and list examples of dApps, it appears most dApps wouldn't qualify. It may even seem as if true dApps don't exist. dApp If one developer tried to explain to another what a dApp is in 2023, they'd probably say, "Well, it's like a website that calls various APIs working with blockchain." Just like that, the magic of the term 'dApp' would vanish. The other developer would think, "What's the big deal? Why so much fuss about it?" The reason is that the genuine concept of dApps has long been sacrificed for user convenience. Originally, the term implied that every instance of the application runs on the user's device. You'd fetch wallet balances from your node, and you'd send transactions from it as well. The application itself should be stored on a distributed storage system resistant to censorship, outages, and attacks. All user-generated data should also be stored in such storage or directly in a blockchain smart contract. It's a captivating concept, but it clashes with reality. Blockchain data can weigh gigabytes or even terabytes. Decentralized storage requires specific software and space for distributed data, isn't as fast as AWS, and often needs specialized browsers. Interacting with smart contracts costs money in cryptocurrency, and purchasing it isn't straightforward for first-timers. Then, factor in the complexity of setup, the need for specialized knowledge, ample free time, and the myriad of blockchains out there. So, dApp developers started offloading the most complex parts for users to separate services, interfacing with them solely via APIs. Now, almost every blockchain has its API. This means dApps have to store settings for each network to cater to more users. While APIs for distributed storage exist, hosting the dApp on them isn't efficient. Most solutions can't compete with web2 in speed and convenience. Hence, such storage systems are only used for tasks where response time isn't a priority. Even on Hackernoon, Arweave is used only for backing up articles. What client-side technologies should be used for a dApp? Well, if we aim to reach the maximum number of people in 2023 and 2024, then client-side web technologies are the way to go for . True, backend technologies like PHP and Python won't cut it, but any framework based on JavaScript/Typescript will do the trick. You can pick from the top 3 frameworks: React, Angular, or Vue.js. However, in my experience, Web3 components for Angular are rarer. My personal choice is React with Typescript. Of course, nobody's stopping you from using plain JavaScript, but why would you? creating a dApp Further, to interact with smart contracts, you'll need some kind of library. The most popular ones are Web3.js and ethers.js. In my opinion, both aren't the most elegant. Their APIs frequently change, and code examples older than a year might not work straight away. My personal pick is ethers.js. Its structure feels more intuitive to me, and compared to Web3.js, the solutions tend to be more concise. In the documentation of various projects, examples are usually provided for at least these two libraries. First and foremost, create an empty project (React + Typescript). npx create-react-app project-name --template typescript Navigate to the project directory. cd project-name Install ethers. This will ensure you have the most up-to-date version. Keep in mind that older examples from the internet might not work without adjustments. npm i ethers Which type of domain should you choose? No, I'm not talking about top-level domains like .com, .org, and the like. I'm discussing whether one should opt for decentralized domains instead of traditional ones. Yes, domains can be decentralized, too. Instead of the usual top-level domains, you might come across ones like .eth, .nft, .wallet, .crypto, and .go. Unfortunately, using them in popular browsers (like Chrome and Safari) without additional extensions won't work. Various companies have been trying for years to establish a domain zone that functions both in web2 and web3. So far, agreements have only been reached with less popular browsers like Opera and Brave. In these browsers, Web3 domains work. So, if your target audience primarily uses the most popular browsers, the choice is clear: you need a Web2 domain. However, if your application becomes popular, domain squatters might purchase a domain with your project's name. When the Web3 revolution takes place and domains become accessible in all browsers, these squatters will likely demand a hefty price for that domain. From this, it emerges that Web3 domains might be worth purchasing as a safeguard against squatters or for a hardcore audience using specific browsers. Furthermore, such domains can serve as an alternative to unreadable wallet addresses. Instead of a complex address like 0x5301b241879e66EC45fD284D3D97A5C51472D6f3, you could use a domain like “mydapp.crypto” to send and receive funds. Authentication: MetaMask's Dark Side Currently, MetaMask stands as the most popular browser extension for storing people's wallet private keys. The private key is the most crucial element - "Not Your Keys, Not Your Crypto.” Entrusting such a vital component to anyone is a no-go, making it preferable to store it on one's device. MetaMask, in this context, allows users to keep their private key locally and doesn't share it with anyone, not even dApps, no matter how nicely they ask. Despite its millions of users, getting started with MetaMask isn't straightforward. One has to go through a myriad of not-so-simple steps to set up an initial empty wallet. And then an equal number of steps are required to fund that wallet. I can confidently say that the next billion users will opt for a different solution. But as of now, it's the industry standard, and . every dApp should support MetaMask But what if I told you there are over a hundred other wallets out there? It would be ideal to support those as well. But don't pull your hair out just yet! Solutions already exist that support all popular wallets. Typically, apart from browser extensions, these solutions also cater to mobile apps, significantly broadening the potential user base. Examples of services you can use are Web3Auth and WalletConnect. Blockchain Selection: Which Chains Are Best for dApps? If you delve into the website of nearly any blockchain project, you're often met with bold claims: their blockchain is the fastest, most user-friendly, cheapest, and boasts millions of users now or will very soon. So, with this vast array of blockchains and ecosystems, how do you pick the right one? In my view, the answer is clear-cut: if the blockchain is EVM-compatible, you're already halfway there. EVM, or Ethereum Virtual Machine, backed by the Ethereum Foundation, is a standard that any blockchain project can adopt. Critically, all tools for testing, debugging, deployment, linting, explorers, etc., will seamlessly integrate with this new chain. This means that if you create a dApp for one EVM-compatible project, it can, with minimal configuration, work across nearly all others. Sounds like magic, right? Regarding non-EVM compatible projects, for them, you must have a clear rationale. Recognize that targeting these chains may limit your user base, offer fewer tools, and present more unprecedented bugs. The smart contract languages also differ, sometimes drastically. Here are the languages used for smart contract development in the top 20 capitalization projects: Solidity, Plutus, and FunC. Each of these languages is tailored specifically for individual blockchains. Grasping each requires considerable time, as their operational principles vary substantially. when developing dApps Of course, you can architect your dApp to operate across a majority of these diverse chains. However, that's an advanced move and quite time-consuming. Straddling two worlds isn't always straightforward. Let's dive right back into building our dApp with the newfound knowledge at our disposal. For this walkthrough, I'll be using the Gnosis Chain as our EVM-compatible blockchain. It's an L2 network that boasts cost-efficient transactions. For several years now, I've deployed a public notes smart contract on it, allowing users to create textual notes under their usernames. You can find it at this address: `0xf6b270136Da7F8a2113B93a3b9Eeaf5160C45bA0`. To read data from this contract, you first need to instantiate a provider. A provider essentially acts as an RPC API to a specific blockchain node. The server delivering the data is already in sync with the blockchain network and provides the most up-to-date state. const provider = new JsonRpcProvider('https://rpc.gnosischain.com/'); To fetch data from our contract, we'll create an instance of `Contract` from `ethers`. const contract = new Contract('0xf6b270136Da7F8a2113B93a3b9Eeaf5160C45bA0', notesAbi, provider); If I had linked my contract address with a .eth domain, then you could access the contract like this. const contract = new Contract('myapp.eth', notesAbi, provider) In this instance, we're passing in my smart contract's address, the provider, and the ABI (Application Binary Interface). The ABI ensures that the node can interpret state data from binary correctly. The ABI content is quite detailed for this article, so I've moved it to a separate URL. Next, we need to prepare the username in the required format to use it for data retrieval: const usernameHash = keccak256(toUtf8Bytes('igor')); Then, you can fetch all the records I've saved in the smart contract like this: const items = await contract.getNotes(usernameHash); You can check out the entire code for `App.tsx` . here Also, a quick heads-up: In the example, I'm using a free provider. If you're scaling a dApp with a significant user base, it might not be suitable. In such cases, you'd either want to set up your node or opt for paid providers from services like Alchemy or Infura. Funding Your Idea Through Grants In the fast-paced world of dApps, innovative ideas can often operate at a loss for extended periods. It's great if you've got a plan to turn a profit swiftly and a few thousand dollars to sustain yourself in the meantime. But if you don't, fret not. Ideas with sound financial potential always catch the eye of venture angels and investors. But in the Web3 universe, innovation is additionally fostered through grants provided by major foundations such as Ethereum, Binance, and Optimism. These grants are often disbursed without any strings attached, either in phases or as a lump sum. Unlike venture capital, grants don't come with the business obligations typical of angel investors. Projects awarded grants from a specific foundation should, in the long run, positively impact that specific ecosystem. The conditions and allocated amounts vary from one foundation to another, with grant amounts ranging from hundreds to hundreds of thousands of dollars. These are often disbursed in the project's native tokens. To gauge if your project idea aligns with a particular grant program, study previously awarded grants and benchmark against your own. Do you think you can deliver something similar or even better? You're likely grant material. But bear in mind that securing a grant can be a long process. Despite being a fantastic avenue to bring your project to life, be prepared for stage to take weeks or even months. The stages you'll navigate are: each Application Preparation. Many grant applications are straightforward. You'll be detailing your idea and showcasing your team's expertise. Put forward a compelling pitch about both the project and the team. Lack of experience in Web3 might reduce your chances of securing a grant. Project Evaluation. After submitting your application, anticipate a long evaluation phase. The higher the grant amount requested, the longer the evaluation. Typically, you'll receive an approval or rejection email. However, some projects might ghost your application. A month post-submission, don't hesitate to follow up on the application status. And feel free to apply to multiple foundations. Some projects might even qualify for grants from various foundations. Just be wary of potential conflicts of interest and clarify the feasibility of securing multiple grants upfront. Contract Signing. Post-grant approval, you'll engage in a phase of document preparation and signing by all committee members. While you can often start working before the contract signing, there's no guarantee that the contract will get finalized. The hold-up isn't always on the foundation's end; sometimes, sanctions might prevent a grant's disbursement based on your citizenship or residency. Project Acceptance. Acceptance of your grant can be slow-paced. Every committee member will thoroughly vet your solution. Prep a top-tier demo of your project since some members might have less technical knowledge and will evaluate based solely on your demo resources: demo sites and video presentations. Grant Payout. Post a successful grant review, the approval decision goes to accounting. Here, too, payments can get held up, especially if multiple people's confirmations are required. Often, these individuals are engaged across various projects, not just grants. To obtain a list of nearly all projects offering grants, search for "List Web3 Grants" online. As you can see, if you have experience in web2 development, not all concepts in web3 will be clear at first. Many things might raise questions. Nevertheless, this article calls for a part 2, where we could build a full-fledged application using different networks, with the capability to store data in a decentralized manner, as well as interact with smart contracts either at the user's expense or the developer's. See you in the next part!

Dive Into dApps: Your Ultimate Guide to Start Crafting Them Today!

Crypto adoption is on the up – even amidst the bear market of 2022, the market saw an increase in wallets and transactions. In June 2023 we saw 15 million active wallets, more than twice as many as two years ago when prices were still elevated. Such interest spawns out of a number of reasons – from lower fees, higher speed, and better security, to its nature as a shield against the forces of inflation and its provision of greater opportunities on the global stage. But, we’re still in the early days of the development of the crypto industry. If we compare the growth rates of Internet users and crypto users, the resulting trend will be very similar. If the crypto industry develops effectively, simultaneously solving all the problems that place the masses in adoption, then by the end of this decade we should theoretically expect the first billion crypto users. Nevertheless, noting the benefits, adoption isn’t as widespread as we should expect, especially in the non-custodial market. The reason? The gaping education gap. Blockchain technologies are simply very difficult to get your head around. In order to use an EOA, or an ‘Externally Owned Account’ such as an account from wallet, the average user needs to understand terms such as ‘seed phrase’, ‘private and public keys’, ‘smart contracts’, ‘gas fees’ – there’s no getting around it either, as if mistakes are made, funds are lost. Metamask Sad stories about self-custody wallets https://twitter.com/david_e_olsson/status/1592971853962039296?embedable=true https://twitter.com/MissBlackOG/status/1333805445685899265?embedable=true https://twitter.com/boshen1011/status/1595265219898789888?embedable=true As a result, for years, the community has been on a quest for simplification. Indeed, now, with the concept of ‘Account Abstraction’, we’re almost there. That’s why, today, we’ll be exploring the wheres, the whats, and the whys, while evaluating the two different categories of solutions. What is Account Abstraction? As we covered briefly, the main barrier to the widespread adoption of cryptocurrencies lies in their complexity of use. EOAs are effectively public-private key pairs, where the user acts as both the ‘Signer’ of transactions and the ‘Account’. They’re responsible for both the validation and execution of transactions – in other words, that’s a lot of weight to put on the old lady looking to send money to her grandson for his birthday. Aside from the amount of conceptual knowledge that is needed to perform a transaction on the blockchain, use needs to be void of error. As there’s no third-party custodian to deal with lost passwords and two-factor authentication, if the password is lost, the funds are lost in tandem. As such, most people who are interacting with the blockchain do so on a custodian-only basis, instructing centralized platforms such as Binance to hold their private keys on their behalf. Of course, there are privacy concerns here – especially when we consider the recent FTX debacle. Centralization was never the dream of the blockchain, so a solution regarding the usability of non-custodial platforms has always been a priority. That’s where account abstraction comes in. In layman’s terms, this is the practice of decoupling the relationship between the account holding the assets and the signer by making the account itself a smart contract. Of course, such an idea isn’t new, and was always on the Ethereum roadmap, being proposed back in different EIPs since 2016. Recently, however, with EIP-4337 being announced in 2021, the dream is finally becoming a reality with application layer solutions. Any dApp developer would be able to utilize the proposal to do things such as: sponsoring user transaction fees; enabling additional security features such as on-chain transaction monitoring; utilizing social logins to introduce non-custodial guardians and providing account recovery. Recently, on March 2nd, 2023, the community deployed the smart contracts necessary for the implementation of EIP-4337 to the main Ethereum network. Then major infrastructure players such as Alchemy, Biconomy, Gelato Network and etc. released core account abstraction infrastructure components. Moreover, with the advent of advanced layer-2 mechanics, ZK-Rollup solutions such as StarkNet and ZKsync offer native account abstraction on the protocol layer. In theory, account abstraction and the flexibility it provides is an ideal solution to the aforementioned barriers to blockchain entry. However, there’s one main reason why a solution hasn’t been crowned, and that lies in the increased security risks. The extensibility of transactions increases the attack vector surface area, owing to the fact that every component ought to be secured individually and holistically. Nevertheless, every day, our heroes crawl closer to the finish line, and the risks facing account abstraction are diminishing day by day. As such, it’s worthwhile digging deeper into the kinds of solutions available. Application-level solutions on L1s: smart contract plus off-chain infrastructure We’ve spoken to some degree regarding the Ethereum Improvement Proposals that change the way the network works. Since 2016, the idea of Account Abstraction has certainly been a desirable integration. Notably, in 2018, smart-contract wallets were introduced to secure user assets. At this point, social recovery became possible for the first time, with on-chain fraud monitoring – all without providing custody to a third party. In 2020 with EIP-2938, a new kind of transaction was developed that would enable smart contracts to act as top-level accounts. Not long after came EIP-3074 which made existing EOAs behave similarly to smart contracts, allowing users to simply delegate EOA control to a smart contract. Then, in 2021, EIP-4337 hit the Ethereum roadmap, which is where we are today. The main idea of the proposal was to standardize the off-chain infrastructure required to write and operate smart-contract wallets. Notably, with a clear separation of validation and execution when it comes to non-custodial user actions on the blockchain. Source: The road to account abstraction by Vitalik Buterin So, what’s going on behind the scenes when it comes to EIP-4337? Firstly, the transaction pathway involves the UserOperation being sent to a high-level mempool (effectively, a queue where transactions are sorted and stored before being added to a new block). Then, a bundler wraps up a group of UserOperations into a bundle transaction, which is then sent to the EntryPoint contract with fees being paid by the bundler. Then, the EntryPoint contract does two things. First of all, it verifies the target wallet’s transaction and then it executes the call. As we looked at it, there’s a clear separation between validation and execution here – something incredibly important for account abstraction. Such an approach can be used for building new-generation crypto wallets for EVM blockchains, where users will be able to take advantage of advanced security features such as social recovery, key-changing, and etc. multi-sig Using a real-world example, Safe Wallet by Gnosis – a multisig smart contract wallet that runs on EVM blockchains. The wallet itself requires transaction confirmation from not one but several wallet holders, each holding a different signature. It is worth noting that Safe is probably the very first smart contract wallet that has become widespread and at the moment about 60 billion assets are stored in more than 3 million wallets. The official Safe wallet cannot be called a very powerful account abstraction wallet that implements all the features that this new concept gives, it basically has only multi-sig functionality. Safe positions itself more as an open protocol on the basis of which it is possible to build a next-generation crypto wallet thanks to its extensible design. More recently, Safe has supported EIP-4337 as a standard and released the Safe {Core} account abstraction SDK for external developers. However, application-layer technologies on the Ethereum mainnet come with noticeable drawbacks. Smart contracts, for example, don’t just expand the applications of blockchain technology, but they also increase the surface area for attack. These contracts are usually written in a high-level language such as solidity, before being compiled into bytecode and deployed to the blockchain by the contract owner, where they’ll run on various virtual machines. The complexity means that novel attack vectors arise, increasing the likelihood of transaction order dependence attacks, false top-up attacks, and replay attacks – all usually occurring on the application layer. Secondly, since the entire Ethereum ecosystem is built around EOAs, many Dapps are incompatible with smart contract wallets. This is largely a result of smart contract wallets being seen somewhat as ‘second-class’ citizens on Ethereum. Account abstraction infrastructure for application level (Smart Account Contract, Bundler, Paymaster, SDK) Biconomy (Smart Account Contract, Bundler, Paymaster, SDK) StackUp (Smart Account Contract, SDK) Safe (Key management) Web3Auth Wallets built on top (based on Safe) Safe (based on Safe) Worldcoin Ambire Sequence (beta, based on Safe) Pluser (beta, based on Safe) Sout wallet And more… Protocol-level solutions on L2s: native account abstraction The solutions to application layer vulnerabilities lie in the development of a layer-2 solution, designed to be used with account abstraction. In other words, a sidechain that can move the process of account abstraction to the protocol layer. StarkNet and ZkSync are fantastic examples of L2s with native account abstraction realization inspired by erc-4337.  The main difference from EIP 4337 on L1 is that native accounts here are first-class citizens of the protocol. Let's deep dive into the implementation of account abstraction on StarkNet. Just like with EIP 443, there’s a meta to validate each transaction. Indeed, the function makes sure that any submitted transaction was initiated by the account owner, and won’t take up any additional resources during execution, while the function abstracts away the remaining actions performed by a transaction. Validate execute Another key task of these layer-2 solutions is to verify off-chain signatures – something that was proposed on the mainnet with EIP-1272. Indeed, that’s something that StarkNet does quite well with Argent X, a browser wallet based on StarkNet’s existing infrastructure – the account in the signed data coming from off-chain messages makes sure that if multiple account contracts are using the same key, the signature requested by a dApp for a specific account cannot be used for the purpose of alternate account authentication. As a matter of fact, the app is the first wallet to exist on StarkNet, and has a browser extension for Chrome and Firefox. It’s multi-account, enables users to send and receive NFTs, and is 100% . In layman’s terms, Argent X realizes the benefits of the StarkNet infrastructure on the front end. open source Moreover, just like application-layer infrastructure, these layer-2 applications also enable the connection of guardians, where accounts can be re-programmed to suit new keys. Social recovery is 100% non-custodial as you can decide who the guardian is and change it any time you wish. There are also some fantastic benefits when it comes to gaming. For example, session keys being available with logic customizability means that variables such as time and contracts to be interacted with can be altered depending on the use case. Native account abstraction implementation ZKSync Starknet Wallets built on top (ZkSync and Starknet) Argent (beta, ZkSync) Raise Finance The current state of account abstraction It is difficult to count how many account abstraction wallets there are on the market, but I found 2 Dune dashboards with statistics. The first one features 400k+ ERC-4337 wallets from different EVM networks (Base, Avalanche, Optimism, BSC, Arbitrum, Ethereum, Polygon), the second shows that there are 4m+ Safe wallets from different EVM networks (all supported by Safe chains). Source: https://dune.com/niftytable/account-abstraction Source: https://dune.com/safe/all Speaking about Safe. Most recently, the sensational Worldcoin project released its World app to the public with a built-in non-custodial crypto-wallet and World Orb device through which the identity verification process is organized around the world. Thus, in just a few weeks, they onboarded 2+ million users who received proof-of-personhood Id from Worldcoin to their crypto wallets created in the World app. The project developers decided to apply the concept of account abstraction in the development of the World App. Under the hood, this smart contract wallet uses Safe{Core}, an account abstraction stack by Safe. Now, through account abstraction, they organize only a gas-less experience for their users, but in future releases, they are going to support account recovery and other interesting features that the AA concept allows them to implement. To date, the World App is the largest deployer of Safe wallets, among 4m+ Safe wallets, 1.5m was created by Worldcoin for their users. Source: https://dune.com/hashed_official/worldcoin-dashboard Considering the amount of infrastructure and the number of created smart wallets, the figure is not yet impressive, we will write off the fact that it is now a crypto winter and a certain maximum number of crypto users has been reached. But it cannot be denied that will be ready for the next bullish trend and the flow of new crypto users will be onboarded through account abstraction wallets, and not through EOA wallets. And I think the example of a Worldcoin launch will make account abstractions wallets even more popular. Final thoughts In terms of a conclusion – one thing is clear. solutions are in no way inferior to the mainnet Ethereum Improvement Proposals, and instead, largely build upon them. Much like layer-2 solutions are designed with greater speed and lower transaction fees in mind, native account abstraction with these features in-built are great alternatives to the shortcomings of the Ethereum mainnet. Layer-2 With crypto adoption increasing day by day, it’s important that we solve the problems associated with a confusing interface so that a bad taste is not left in the mouths of regulators and ordinary users alike. That’s why realizing true account abstraction – be it through the application-level powers of the Ethereum mainnet or the up-and-coming layer-2 projects that bring this concept to the protocol level – has never been more important for the widespread adoption of blockchain technologies. Lead image by on Unsplash Shubham Dhage

Account Abstraction: Solutions for L1 & L2 Layers and Current State of Adoption

অ্যাকাউন্ট বিমূর্ততা: L1 এবং L2 স্তরগুলির জন্য সমাধান এবং গ্রহণের বর্তমান অবস্থা

Kontoabstraktion: Lösungen für L1- und L2-Ebenen und aktueller Stand der Akzeptanz

Abstracción de cuenta: soluciones para capas L1 y L2 y estado actual de adopción

Abstraction de compte : solutions pour les couches L1 et L2 et état actuel de l'adoption

खाता अमूर्तन: L1 और L2 परतों के लिए समाधान और अपनाने की वर्तमान स्थिति

アカウントの抽象化: L1 および L2 レイヤー向けのソリューションと導入の現状

계정 추상화: L1 및 L2 계층을 위한 솔루션 및 현재 채택 상태

Abstração de conta: soluções para camadas L1 e L2 e estado atual de adoção

Hesap Soyutlama: L1 ve L2 Katmanları için Çözümler ve Mevcut Benimseme Durumu

Trừu tượng hóa tài khoản: Giải pháp cho các lớp L1 & L2 và tình trạng áp dụng hiện tại

帐户抽象：L1 和 L2 层的解决方案以及采用现状

Why NFTs? The use of non-fungible tokens (NFTs), sometimes also known as 'digital collectibles', in web2 games has been a hot topic in the gaming industry lately. NFTs are unique digital assets built using blockchain technology, offering several benefits for game developers and players. One of the biggest advantages of NFTs is that they can be used to create truly unique and valuable in-game items. In traditional web2 games, players often rely on in-game currency or other abstract forms of value to purchase or trade items. This can be frustrating for players, as it can be difficult to accurately assess an item's value or truly have ownership over it. NFTs, on the other hand, provide a transparent and verifiable form of ownership for in-game items. This gives players greater control over their virtual possessions and makes it easier to trade and sell items with other players. This can create more robust and active in-game economies, which can be a major draw for players. How can my game integrate NFTs? Despite these benefits, many game developers have been hesitant to adopt NFTs due to the steep learning curve. Blockchain technology can be difficult to understand and use, and it can be challenging for developers to integrate it into their existing games. Fortunately, several tools and platforms are making it easier for developers to experiment with NFTs, such as , , , and others. Ankr Altura Metalinq Chainsafe, , for example, is a blockchain-as-a-service platform that provides a suite of tools and services for developers who want to incorporate NFTs into their games. The platform offers a range of features, including a marketplace for buying and selling NFTs, a customizable wallet for storing and managing NFTs, and support for multiple blockchain networks. Ankr , on the other hand, is a platform that provides a range of API tools and services for developers who want to integrate NFTs into their games. The platform offers a range of features, including an NFT creator tool and a marketplace for buying and selling NFTs, while supporting several blockchain networks. Altura is a web3 gaming toolbox that helps game developers create non-custodial game wallets using state-of-the-art solutions like web3auth. The players won't even know they are using blockchain tech in the background or doing NFT transactions when buying and selling their in-game items. Metalinq In addition to tools and platforms like Ankr, Altura, and Metalinq, other solutions are making it easier for game developers to incorporate NFTs into their games. For example, is a platform that can remove the biggest friction for blockchain transactions - gas fees! Biconomy One of the key features of Biconomy is gasless transactions, which makes it easier for game developers to abstract away the complexities of blockchain even further. Biconomy can help enable meta-transactions, such that the onus of paying and dealing with gas fees falls on the game developer rather than the player, thus making it for a seamless UX end-to-end. Conclusively Using NFTs in web2 games can revolutionize how players interact with and value in-game items. While the technology can be challenging to understand and use, some tools and platforms are making it easier for developers to experiment with NFTs and see the benefits for themselves. As more and more games adopt NFTs, we can expect to see exciting developments and innovations in the world of online gaming.

NFT Tools for Building a web3 Game

Are JWTs really dead, or are they just misunderstood? I’ve seen quite a few articles lately suggesting that the advent of Web3 and the spreading usage of wallets will lead to users ditching traditional email/password-based account systems, and instead, logging in using their wallet. To be honest, after using a few dApps, the super simple workflow of a click or two of your wallet that pops up is indeed a superior experience. Many of these articles go on to say “yay we don’t need JWTs anymore!”. This is where I disagree. JWTs, while a bit confusing at first, are incredibly useful for backend engineers, especially those of microservice systems. , considering that these systems - a great number of them - already exist and already integrate with JWTs! Ethereum is great and all, but we really do not need to reinvent the wheel. It’s good to be able to continue using the same backend tools you are used to when you need to. Especially Logging in with MetaMask proves it’s you - but how do you prove to future API calls it is you? The “screw-JWT” crowd suggests using simple Session IDs, but this is a step backward to the early 2000s, mind you, when simple layered architectures were the standard, which did not have the complexities of today’s backend systems. Unfortunately, Session IDs can not be verified without an additional round trip to the database to determine whether or not the Session ID granted belongs to a valid session. This means when the backend service receives the request that contains the session ID, it then makes a request itself to the auth server asking “is this active” - and then every other service in the Microservice system asks the same. If there are several services involved, that could be several additional round trips to the auth service. In order to remedy this situation, cryptographic experts got thinking. What they came up with was JWTs - now part of the OpenID standard, you know, the one that Keycloak, Auth0, and others help you to implement. JWTs, y’all The solution was to grant a set of tokens - JSON Web Tokens to be precise. That set consists of an , a , and an . These tokens were then “signed” by a secret - usually called the . Signing, just so we’re on the same page, is a cryptographic hashing algorithm, in the case of JWTs – usually (the default for Auth0).  In the case of the is used as the input and hence, becomes the key needed to successfully decipher that hash - or “verify” it.  With and a public/private key pair are used, i.e. signed by private key, and verified with public key on the client. AccessToken RefreshToken IdToken ClientSecret HS256 HS256 ClientSecret RS256 ES256 This means if a backend service receives one of these tokens, and it knows the , it can verify that the token was actually issued by the auth service which signed that token. The token used when attempting to access a backend service is the . These tokens specifically contain information about who the user is as well as their “claims”, or in other words, what they are allowed to do formatted for the system that cares about it. ClientSecret AccessToken For microservice systems, this means each service that cares about verifying identity just needs to know about the as they can verify the JWT is authentic using it, rather than a roundtrip to the database. In a system with many microservices, this can reduce many additional round trips to the database, making the entire system more scalable. ClientSecret Access tokens, if stolen, can be used maliciously, and for that reason, it’s important to take the appropriate precautions when designing a system to use them. The set of precautions, on top of signing and verifying the tokens consist of: minimum Setting an expiration date on the Access Token JWT of 5-15 minutes and making sure tokens are not expired when received Don’t store the Access Token except for in memory Issue Refresh Tokens that can be stored and sent to a server for verification, and refreshed along with using the and that issued it. ClientSecret ClientId Only use when transmitted over TLS connections (HTTPS) Use HTTP Only cookies so they can not be modified on the browser side CORS settings A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm. - , note: bits for HS256. RFC7518 Auth0 uses 512 A confidential client needs an intermediary server, such as Node.js - this server is a proxy to the auth service so the client need not know about the client secret. A public client exposes the client secret, and there isn’t a proxy server between the browser and the auth service. This can be restricted further with CORS settings so only requests from certain domains are allowed. Additional precautions include: Use Rotating Refresh Tokens – each one can only be used once. When used it is exchanged for a whole new set of tokens, and the exchanged refresh token is revoked. If this strategy is employed it’s worth noting that users with a poor internet connection can sometimes not receive the response to the refresh request and try again. For this reason, a short grace period of 30 seconds or so will allow for them to hit refresh and try again. Allowing user to revoke all of their existing refresh tokens by logging out. And probably more - for example, if you detect someone attempting to use a revoked refresh token, you could revoke all of that user’s active refresh tokens. All of these precautions, admittedly, can make getting it right a bit tough. There’s a lot to understand. There’s also usability concerns. A user becoming logged out of your site every 5 minutes would feel pretty annoying to them. To avoid this, a silent refresh loop must be implemented in the consuming application to continually refresh the token set. That said, on the other side of getting it right, is being able to securely integrate with all of your backend systems in a scalable way, as well as many existing tools - such as , which can autogenerate all your APIs for you based on a connected Postgres’ DB schema. Thus, being able to integrate easily with existing tooling can save a lot of development time. Hasura If you use OpenId already, it’s likely you already have these things in place. It is, after all, an authentication standard. So how can we keep the convenience of using JWTs in a Web3 and login with MetaMask world? JWTs and Web3? Let’s start by understanding the OpenId authentication flow used for SSO. You visit a website and want to login with your account - you click the login button You are redirected to the SSO login page - you login with an email/username and password You are redirected back to the original application with a set of JWTs which are stored appropriately and used in silent refresh background flows. In the web3auth world, we are replacing step two with using your wallet’s private and public key pairs to sign a challenge. The redirect is not needed or desired. You visit a website and want to login with your account - you click the login button You are receive a challenge from the auth server which pops open your wallet asking you to “Sign” the challenge. Press sign. The auth server verifies your signature and issues you a set of JWTs which are stored appropriately and used in silent refresh background flows. We’re simply replacing the SSO style redirect flow with a challenge that is signed by your wallet. The flow after receiving the tokens remains the same as OpenID. That means you could for example, switch from using OpenID to using web3auth with a JWT issuing server, and nothing about using those tokens after they are granted would need to change. All your existing backend integrations with tools like Hasura remain exactly the same. This is exactly what I want as a Full Cycle developer. I don’t want to reinvent the wheel. I want to replace OpenID with web3auth and still be able to use all of the powerful tools that I am used to. Unfortunately, I couldn’t find a web3auth server that did this as well as the security precautions. I found a few projects demonstrating techniques in the process, but not the whole flow end to end. So I got to building… I built this here auth server: https://github.com/CloudNativeEntrepreneur/web3auth-service And this here integration to go with it, that implements all the things - silent refresh, yada yada - all those things I mentioned above: SvelteKit https://github.com/CloudNativeEntrepreneur/sveltekit-web3auth Of course if there was gonna be a GraphQL client and example, then there needed to be a GraphQL server and database as well, so I also provided examples of that: + https://github.com/CloudNativeEntrepreneur/example-hasura https://github.com/CloudNativeEntrepreneur/example-readmodel This example uses the and , so all you need to do is declare your DBs and describe your schema in YAML, and Hasura will autogenerate all the GraphQL APIs you need. AND, I made the auth server with Hasura in mind, so it has the proper claims to integrate with Hasura's RBAC and permissions, which are quite robust. Zalando Postgres operator SchemaHero And of course, you need a place to run all that, and so, a local dev cluster that sets up all the tooling like istio, and the operators, and SchemaHero for you! https://github.com/CloudNativeEntrepreneur/local-dev-cluster But who knows how to even use all that? So that's why I made this repo: meta https://github.com/CloudNativeEntrepreneur/web3auth-meta Using that meta repo will clone all the projects you need down into the right places, and run them all together. Finally, to run all the projects together, you need tools installed, and installing tools is annoying - so I made this repo here that will install them all for you! https://github.com/CloudNativeEntrepreneur/onboard I also published on npm, and made a template out of a SvelteKit project that uses it and has GraphQL set up and integrated with authentication to a Hasura instance so when you're ready to make your own projects, you can use that as a template! sveltekit-web3auth https://github.com/CloudNativeEntrepreneur/sveltekit-web3auth-template If you're not ready for the web3 auth world yet, you can also use , which comes preconfigured to connect to your local dev cluster, and a Keycloak instance that's set up within it. Seeing as how both projects issue JWTs, the goal is for the auth system to be interchangeable - use web3auth or classic OIDC - upstream usage of the tokens are the same. https://github.com/CloudNativeEntrepreneur/sveltekit-oidc Now go and make some hybrid dApps with autogenerated GraphQL APIs and robust RBAC and permissions and subscriptions and authenticated SSR pages and silent refresh loops and rotating refresh tokens and stuff! Conclusion In conclusion, no, JWTs and login with Ethereum/metamask are not mutually exclusive. In fact, if you like developer productivity and integrating with existing tools, I think you’ll do quite well using JWTs AND web3auth. Cheers! I’m available for consulting! If you’re interested in my help on a project you’re working on, send me a message on Twitter!

HELP! There’s a JWT in my Metaverse!

¡AYUDA! ¡Hay un JWT en mi metaverso!

AIDER! Il y a un JWT dans mon Metaverse !

मदद! मेरे मेटावर्स में एक JWT है!

ヘルプ！メタバースに JWT があります。

AJUDA! Há um JWT no meu Metaverso!

CỨU GIÚP! Có một JWT trong Metaverse của tôi!

帮助！我的元宇宙中有一个 JWT！

The time has come to build the next era of technology, to build the community-owned web, to build a decentralized future. It’s time to shift lanes, to not only experience the future but to build it. It’s time for Web3. Polygon presents Road to Web3 - a global hackathon in partnership with EthGlobal from Feb 3 - 9. Build your ideas and stand a chance to win prizes worth ! Road to Web3 is your chance to onboard yourself to Web3 and to shift gears from the Web2 world. 250,000 USD Why Polygon? is the leading platform for Ethereum scaling and infrastructure development. Its growing suite of products offers developers easy access to all major scaling and infrastructure solutions: L2 solutions (ZK Rollups and Optimistic Rollups), sidechains, hybrid solutions, stand-alone and enterprise chains, data availability solutions, and more. Polygon’s scaling solutions have seen widespread adoption with 7000+ applications hosted, 1B+ total transactions processed, ~100M+ unique user addresses, and $5B+ in assets secured. Polygon Bringing you the opportunity to build the decentralized future of tomorrow Take your Web3 experience to new heights and build your first project interacting with decentralized games, DeFi, NFTs, or take something you already love in Web2 and decentralize it! The 96-hour hackathon will also feature multiple talks and workshops for which we've gathered the best speakers, mentors, and thinkers such as , , , Patrick Collins, , and many more distinguished personalities in the space to help you learn and build with over 1000s of new friends around the world. ** Matthew Ball Ryan Wyatt Justin Kan Austin Griffith We’ve partnered with some of the most well-known protocols in the industry such as Web3Auth, Covalent, Uniswap Grants Program, Moralis, Chainlink, Superfluid, and The Graph to give you ample tools and resources to build any dApp you could possibly dream of and win additional prizes! Hackathon Timeline: Registrations Open - NOW! Registrations Close - 02 Feb 2022 Hackathon Begins - 03 Feb 2022 Project Submission Deadline - 07 Feb 2022 Finale - 09 Feb 2022 How to Participate? Apply via EthGlobal . You will receive further details about the hackathon once you finish the application process here Join the to stay up to date on the latest hackathon news and receive on-demand assistance. Discord server You can form your team (up to 5 members) or go solo. FAQ: Does Road to Web3 cost money? Road to Web3 is 100% free for hackers. All that we ask of you is that you focus on building your project, check-in with us on your progress regularly, and participate in the community we build around this hackathon. What is the stake? We require hackers to "stake" a little bit of money to lock in their position at the event. This stake serves as an extra incentive to build and it is returned after you have completed your project. There are many reasons why someone may have trouble staking, please reach out to us directly if you do.** How many people can be on a team? You can form teams of up to 5 people. There are no restrictions for team members, so you can team up with hackers of any country or experience level!** Is there a Code of Conduct? Yes! For years, EthGlobal’s core ethos has been to make it easy for anyone to dream big. To that end, we've developed a __ __All attendees must agree to and abide by the Code of Conduct at all times.** Code of Conduct. I'm new to Polygon and/or Ethereum. Can I participate? Absolutely! This event is specifically for you!** It doesn’t matter that you’re a beginner, everyone needs to start somewhere, and Road To Web3 is the perfect platform to begin your dApp building journey!  This one is for the changemakers, the doers, the builders. Someone has to build the next version of the internet, and that someone could be you. What are you waiting for? Registrations are open until February 2nd - Register NOW!

Introducing the Road to Web3 Hackathon Powered by Polygon

**NEW YORK CITY, New York, February 16th, 2024/Chainwire/-- Introducing Kadena SpireKey, a human-friendly and secure way to seamlessly interact with any application by removing complex signing processes. Kadena Spirekey “Unlike complex Web3 wallets today where you have to remember every wallet you’ve ever created, Kadena’s SpireKey uses WebAuthn, a technology that has been developed by Google and Apple over the last 20 years, to help anyone securely digital assets directly on your phone or computer. It’s as easy as receiving a prompt on your mobile device and providing a fingerprint as a signature. Even that uncle who asks you about crypto every family holiday dinner can do it. With Kadena, we've made using applications accessible to everyone, no matter if you’re an experienced "degen" or using blockchain for the first time,” Said Kadena CMO, Mike Herron. SpireKey creates a seamless interaction between humans and technology, providing a Web2 experience with Web3 innovation. With SpireKey, users can sign transactions and Web3 applications, just like how it works on Apple Pay or Google Pay. However, it can be done directly on the user's device without opening multiple windows or copying and pasting keypairs, which eliminates potential vulnerabilities seen in traditional wallets. Added Security with Built-in Multi-sig “Kadena's built-in multi-sig signing enables an additional layer of security for SpireKey that only we can provide through our original language, Pact. With multi-sig, SpireKey allows for multiple signatures to be required for certain transaction types. For example, if you want to send over $10,000, you can set up parameters to require signatures from three different devices – your phone, laptop, and cold storage wallet. The multi-sig feature reduces the risk of compromised accounts because a bad actor would need access to three devices. It mitigates the risk of another attack vector, and adds to the overall security,” Said Stuart Popejoy, Kadena Co-Founder and CEO. SpireKey displays how Kadena thinks about the level of usability that Web3 technology should be at. At its core, SpireKey connects humans to interact with the blockchain and with one another. SpireKey believes that showing working examples will inspire all humans alike to see how Spirekey can impact the rest of the world beyond Web3. https://www.youtube.com/watch?v=paweE0nxAZU&embedable=true About Kadena is a blockchain technology protocol that was founded in 2017 by Stuart Popejoy and Will Martino. Kadena is the industry’s only scalable Layer-1 Proof of Work (PoW) blockchain. This scalability enables Kadena to deliver infrastructure-grade performance for any blockchain project. Kadena Along with Kadena's own smart contract language Pact, Kadena’s platform provides the world with the tools and environment to turn ideas and ambitions into reality. Founded by Stuart Popejoy and William Martino, who created JP Morgan’s first blockchain and led the SEC’s Crypto Committee, Kadena aims to allow for true blockchain mass adoption. For more information, users can follow Kadena's: | | | Twitter Telegram Discord YouTube Contact Kadena Press press@kadena.io This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here.

Kadena SpireKey Integrates With WebAuthn To Provide Seamless Web3 Interactions

Storing Passwords In A Database: A Better Way to Do So

What is Authentication? 🔐 Authentication is the process of verifying the identity of users, ensuring they are who they claim to be before granting access to a system or application. In the context of web applications, this is crucial for protecting sensitive information and resources. Authentication involves: User Credentials:🔑 Users provide credentials, such as usernames and passwords. Verification Process:✔️ The system verifies the provided credentials against stored data. Successful verification grants access; otherwise, access is denied Spring Security🍃 For developers building Spring-based applications, Spring Security serves as the de-facto standard for securing their creations. This comprehensive framework provides robust authentication and authorization mechanisms, ensuring your application’s data and functionality remain safe from unauthorized access. Java JWT (JSON Web Token)Authentication: A Secure and Scalable 🔐📈 Approach JWT stands for JSON Web Token, a self-contained token that contains information about the user and is signed by the server for verification. It has become a popular choice for authorization due to its numerous advantages. Use Cases: JWTs are widely used in various scenarios: Public APIs: Securely access public APIs without requiring frequent logins. Mobile Applications: Store user information and authorization details within the token for offline use. Single Sign-On (SSO): This allows users to seamlessly access multiple applications with a single login. Practical application of JWT by implementing it in a Spring Boot application to secure our API endpoints⛏👷 Now, we will configure the in-memory user and JWT. We will create an API endpoint and secure it using Spring Boot security. Create a Spring Boot Project Use Spring Initializr to create a new Spring Boot project with the following dependencies: For Web: <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency> For Security <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency> Lombok: <dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <optional>true</optional>
</dependency> For JWT: <dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-api</artifactId>
    <version>0.11.5</version>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-impl</artifactId>
    <version>0.11.5</version>
    <scope>runtime</scope>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-jackson</artifactId> 
    <version>0.11.5</version>
    <scope>runtime</scope>
</dependency> Let’s start with creating an endpoint to be secured: @RestController
@RequestMapping("/home")
public class Controller {
  @Autowired
    private UserService userService;
  @GetMapping("/users")
    public List<User> getUsers(){
      System.out.println("getting users");
      return userService.getUsers();
  }
} Create a user: @Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@ToString
public class User {
    private String userId;
    private String name;
    private String email;
} Create a service class: @Service
public class UserService {
    private List<User> store=new ArrayList<>();
    public UserService() {
        store.add(new User(UUID.randomUUID().toString(), "Bhushan", "bhushan@gmail.com"));
        store.add(new User(UUID.randomUUID().toString(), "Ramesh", "ramesh@gmail.com"));
        store.add(new User(UUID.randomUUID().toString(), "Suresh", "suresh@gmail.com"));
        store.add(new User(UUID.randomUUID().toString(), "Paresh", "paresh@gmail.com"));
    }
    public List<User> getUsers(){
        return this.store;
    }
} Create an in-memory user with UserDetailService bean: @Configuration
public class AppConfig {
    @Bean
    public UserDetailsService userDetailsService() {
        UserDetails userDetails = User.builder().
                username("Bhushan")
                .password(passwordEncoder().encode("Nemade")).roles("ADMIN").
                build();
        return new InMemoryUserDetailsManager(userDetails);
    }
    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
    @Bean
    public AuthenticationManager authenticationManager(AuthenticationConfiguration builder) throws Exception {
        return builder.getAuthenticationManager();
    }
} Start with creating the class JWTAthenticationEntryPoint that will be implementing : Used to handle authentication-related exceptions. Specifically, it is responsible for returning an unauthorized (401) response to clients who attempt to access protected resources without proper authentication. AuthenticationEntryPoint @Component
public class JwtAuthenticationEntryPoint implements AuthenticationEntryPoint {
    @Override
    public void commence(HttpServletRequest request, HttpServletResponse response, AuthenticationException authException)
            throws IOException, ServletException {
        response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
        PrintWriter writer = response.getWriter();
        writer.println("Access Denied !! " + authException.getMessage());
    }
} The helper class is often created to encapsulate the logic related to the generation, parsing, validation, and manipulation of JWTs in a more modular and maintainable way. It provides a set of methods and utilities to interact with JWTs. Create a JWT helper class: @Component
public class JwtHelper {
    public static final long JWT_TOKEN_VALIDITY = 5 * 60 * 60;
    private String secret = "afafasfafafasfasfasfafacasdasfasxASFACASDFACASDFASFASFDAFASFASDAADSCSDFADCVSGCFVADXCcadwavfsfarvf";
    public String getUsernameFromToken(String token) {
        return getClaimFromToken(token, Claims::getSubject);
    }
    public Date getExpirationDateFromToken(String token) {
        return getClaimFromToken(token, Claims::getExpiration);
    }
    public <T> T getClaimFromToken(String token, Function<Claims, T> claimsResolver) {
        final Claims claims = getAllClaimsFromToken(token);
        return claimsResolver.apply(claims);
    }
    private Claims getAllClaimsFromToken(String token) {
        return Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody();
    }
    private Boolean isTokenExpired(String token) {
        final Date expiration = getExpirationDateFromToken(token);
        return expiration.before(new Date());
    }
    public String generateToken(UserDetails userDetails) {
        Map<String, Object> claims = new HashMap<>();
        return doGenerateToken(claims, userDetails.getUsername());
    }
    private String doGenerateToken(Map<String, Object> claims, String subject) {

        return Jwts.builder().setClaims(claims).setSubject(subject).setIssuedAt(new Date(System.currentTimeMillis()))
                .setExpiration(new Date(System.currentTimeMillis() + JWT_TOKEN_VALIDITY * 1000))
                .signWith(SignatureAlgorithm.HS512, secret).compact();
    }
    public Boolean validateToken(String token, UserDetails userDetails) {
        final String username = getUsernameFromToken(token);
        return (username.equals(userDetails.getUsername()) && !isTokenExpired(token));
    }
} Extending the class for a JWT authentication filter in Spring Security is a common approach to ensure that the filter is only executed once per request. This helps prevent unnecessary duplicate processing and ensures that the filter logic is applied consistently. Create a JwtAuthenticationFilter class which will extend OncePerRequestFilter: OncePerRequestFilter @Component
public class JwtAuthenticationFilter extends OncePerRequestFilter {
   private Logger logger = LoggerFactory.getLogger(OncePerRequestFilter.class);
    @Autowired
    private JwtHelper jwtHelper;
    @Autowired
    private UserDetailsService userDetailsService;
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        String requestHeader = request.getHeader("Authorization");
        logger.info(" Header :  {}", requestHeader);
        String username = null;
        String token = null;
        if (requestHeader != null && requestHeader.startsWith("Bearer")) {
            token = requestHeader.substring(7);
            try {
                username = this.jwtHelper.getUsernameFromToken(token);
            } catch (IllegalArgumentException e) {
                logger.info("Illegal Argument while fetching the username !!");
                e.printStackTrace();
            } catch (ExpiredJwtException e) {
                logger.info("Given jwt token is expired !!");
                e.printStackTrace();
            } catch (MalformedJwtException e) {
                logger.info("Some changed has done in token !! Invalid Token");
                e.printStackTrace();
            } catch (Exception e) {
                e.printStackTrace();
            }
        } else {
            logger.info("Invalid Header Value !! ");
        }
        if (username != null && SecurityContextHolder.getContext().getAuthentication() == null) {
            UserDetails userDetails = this.userDetailsService.loadUserByUsername(username);
            Boolean validateToken = this.jwtHelper.validateToken(token, userDetails);
            if (validateToken) {     
                UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities());
                authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request));
                SecurityContextHolder.getContext().setAuthentication(authentication);
            } else {
                logger.info("Validation fails !!");
            }
        }
        filterChain.doFilter(request, response);
    }
} Create a SecurityConfig class as spring security in the configuration file: @Configuration
public class SecurityConfig {
    @Autowired
    private JwtAuthenticationEntryPoint point;
    @Autowired
    private JwtAuthenticationFilter filter;
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.csrf(csrf -> csrf.disable())
                .authorizeRequests().
                requestMatchers("/test").authenticated().requestMatchers("/auth/login").permitAll()
                .anyRequest()
                .authenticated()
                .and().exceptionHandling(ex -> ex.authenticationEntryPoint(point))
                .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS));
        http.addFilterBefore(filter, UsernamePasswordAuthenticationFilter.class);
        return http.build();
    }
} Create a login API to accept the username and password: @RestController
@RequestMapping("/auth")
public class AuthController {
    @Autowired
    private UserDetailsService userDetailsService;
    @Autowired
    private AuthenticationManager manager;
    @Autowired
    private JwtHelper helper;
    private Logger logger = LoggerFactory.getLogger(AuthController.class);
    @PostMapping("/login")
    public ResponseEntity<JwtResponse> login(@RequestBody JwtRequest request) {
        this.doAuthenticate(request.getEmail(), request.getPassword());
        UserDetails userDetails = userDetailsService.loadUserByUsername(request.getEmail());
        String token = this.helper.generateToken(userDetails);

        JwtResponse response = JwtResponse.builder()
                .jwtToken(token)
                .username(userDetails.getUsername()).build();
        return new ResponseEntity<>(response, HttpStatus.OK);
    }
    private void doAuthenticate(String email, String password) {
        UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(email, password);
        try {
            manager.authenticate(authentication);
        } catch (BadCredentialsException e) {
            throw new BadCredentialsException(" Invalid Username or Password  !!");
        }
    }
    @ExceptionHandler(BadCredentialsException.class)
    public String exceptionHandler() {
        return "Credentials Invalid !!";
    }
} : Creating a JWT request and response involves defining structures for sending and receiving JWTs during the authentication process. Typically, a JWT request is used to send user credentials (e.g., username and password) to the server for authentication, and a JWT response is used to deliver a token upon successful authentication. Create a JWT Request and JWT Response to receive data and send login details @Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
@Builder
@ToString
public class JwtRequest {
    private  String email;
    private String password;
} @Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
@Builder
@ToString
public class JwtResponse {
    private String jwtToken;
    private String username;
} Test the API using Postman to generate a JWT token, then use that token as a header in subsequent requests to access the protected API and verify successful authentication. Dive Deeper : youtube.com/watch?v=q2l91Ffc_8U&t=3299s https://springframework.guru/jwt-authentication-in-spring-microservices-jwt-token/ Thank you for reading😊 Also published here.

Mastering JWT Authentication & Authorization in Spring Boot 3.1

TULUM, Mexico, November 17th, 2023/Chainwire/--CKB, the blockchain of the Nervos Network, is set to mark a significant milestone with its first halving on November 19th. This event will cut CKB’s hard-capped base issuance rate in half, bringing real inflation down from 7.92% to 3.77%, among the lowest across major Layer 1 blockchains. In nominal terms, the base issuance will drop from 4.2 billion to 2.1 billion CKB per year, whereas the secondary issuance, which is uncapped and follows a fixed emissions schedule, will remain unchanged, 1.344 billion CKB annually. The uncapped secondary issuance prevents excessive state growth and ensures a predictable, long-term source of income for CKB miners that is independent of transaction volume. Notably, the inflation from the secondary emissions is narrowly targeted and affects only state occupiers, meaning CKB acts as a disinflationary token for its long-term holders. The Common Knowledge Base The network’s powerful Layer 1, known as the Common Knowledge Base ( ), employs Proof-of-Work for consensus, a groundbreaking generalized model and a instruction set-based virtual machine for transactions and smart contract execution. CKB UTXO RISC-V CKB’s unprecedented flexibility allows it to support all kinds of diverse scaling and application solutions built atop it, while security via Proof-of-Work ensures that the network’s global digital infrastructure remains resilient, neutral, and permissionless. Beyond Account Abstraction CKB sets a new industry standard for flexibility in regard to account abstraction. Its novel accounting model, dubbed the Cell model, is a generalization of Bitcoin’s UTXO model and gives developers complete control over the structure of data stored on-chain, as well as transaction authorization logic, making CKB “accounts” abstract by definition. Moreover, CKB leverages an utterly abstract, low-level virtual machine, dubbed CKB-VM, which allows developers to deploy various signature and hashing algorithms as if they’re mere plug-ins, without the need for hard forks. Unlike other platforms, where cryptographic primitives are hard-coded via the protocol, this allows transaction signing using the signatures from any blockchain system (or even more widely supported standards, such as or ), genuinely redefining what a blockchain can do. protocol-level abstraction Passkeys DKIM Products such as , a convenient WebAuthn wallet, and , a chain-agnostic decentralized identity provider, are already using CKB to offer transformational blockchain experiences to thousands of users. JoyID d.id Solving the Challenge of State Bloat The design of the Nervos Network addresses the head-on. It adopts a multi-layered architecture and ties state growth to the network’s native token, one CKB equals the right to store one byte of data on-chain. issue of state bloat This architecture reduces on-chain storage requirements by pushing computation off-chain, while restricting the blockchain’s state growth via issuance of CKB minimizes node hardware requirements, ensuring network decentralization. Moreover, state rent is implemented through narrowly targeted inflation, incentivizing responsible state management on-chain and providing a sustainable, predictable long-term source of income for miners. First Halving As CKB approaches its first halving event, it stands as a beacon of innovation and long-term sustainability in a too-often myopic blockchain industry. Marking this pivotal moment in the network’s journey calls for celebration. The Nervos Foundation is organizing an online party, tune in on , on November 19th @ 10 am EST! YouTube Contact CMO Annalese Nervos media@nervos.org This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program . here

The Nervos Community Prepares for Its First CKB Halving

Let's learn about via these 64 free stories. They are ordered by most time reading created on HackerNoon. Visit the to find the most read stories about any technology. Passwords /Learn Repo 1. How to Crack a Password Using Hashcat In this article, I discuss the best ways to crack passwords. 2. Exposing Secrets on GitHub: What to Do After Leaking Credentials and API Keys As a developer, if you have discovered that you have just exposed a sensitive file or secrets to a public git repository, there are some very important steps to follow. 3. How Password Managers Can Protect You From Phishing Password managers are a convenient way to use strong, unique passwords everywhere. Another good thing about password managers is that they help protect you from malicious websites that attempt to "phish" passwords. 4. PSA: LastPass Does Not Encrypt Everything In Your Vault As a software engineer and long time LastPass user, I’ve always been an advocate of password managers. With data breaches becoming more and more common these days, it’s critical that we take steps to protect ourselves online. However, over the past year LastPass has made some decisions that have made me question their motives and ultimately has recently caused them to lose my business. 5. Implementing 2FA: How Time-Based One-Time Password Actually Works [With Python Examples] If you care about your security on the web, you probably use a Two-Factor authentication (2FA) method to protect your accounts. There are various 2FA methods available out there, a combination of password + fingerprint, for example, is one of them. However, since not so many people have a fingerprint reader available all the time, one of the most popular 2FA methods today is to use an authenticator app on your cellphone to generate a temporary password that expires within a minute or even less. But, how does this temporary password, called Time-Based One-Time Password (TOTP) works, and how can I implement that on my own service? 6. Build your own User-friendly Cross-platform Password Manager I use a local password manager on my computer:  I just stick with a password, which is the only password I memorize. 7. How To Create Secure Registration Flow with PHP and Password Hashing Building a secure user registration form with PHP seems like a scary task. How do I protect myself from MySQL injection and other methods of hacking. Surprisingly, with only a few steps and precautions, you can greatly reduce the chance of success for attacks. 8. Why Your Browser's Built-In Password Manager Isn't Enough You may ask, "My web browser already has a built-in password manager, why do I need to install a new one?" There's actually a number of good reasons to install a password manager. 9. The Elimination of Cybersecurity's Status Quo – Passwords According to a report by the World Economic Forum, in the year 2020, cybercrime cost the world economy a staggering $2.9million every minute. According to another report, every single day, enterprises lose about 5 million records containing sensitive data due to vulnerability in their system or a human factor failure. 10. HMAC and MAC Explained: How To Build Secure Authentication With JWTs HMACs and MACs are authentication codes and are often the backbone of JWT authentication systems. Let's take a look at how they work! 11. Security.org Knows 15 Million Americans Will Be Buying Cryptocurrency in the Next Year Twelve years after the Bitcoin network came into existence in 2009, we asked nearly 1,300 U.S adults about their familiarity, ownership, and confidence in cryptocurrencies, from Dogecoin to Ethereum, and everything in between. One highlight?  Nearly 15 million Americans plan to purchase crypto for the first time in the next year. 12. Cryptography Trends and News for 2020 Quantum Computing 13. An Introduction to Key Derivation Functions: Argon2, Scrypt, and PBKDF2 A key derivation function, or KDF, derives one or many secret keys from a secret value. Therefore, If you've ever needed to store a password in a database or create a private key from a password, you may have used a KDF. 14. How Big Tech is Working Towards a Password-Free Future A 2019 research conducted by HYPR showed that 78% of people forgot their passwords and required a reset within the last 90 days. Passwords aren’t just difficult to manage, they are inconvenient, insecure, and expensive because passwords are just too easy to guess, hack or intercept and what’s more, the legacy of password reuse is leading to constant attack and account vulnerabilities. 15. Password Managers Should be A Mandatory Part of Everyone’s Digital Life Everyone knows it’s a good idea to use strong, unique passwords, and as employees around the world have been forced to work remotely, logging in from multiple devices and multiple locations, the need for strong password security has only grown. But last year’s Verizon Data Breach Investigations Report (DBIR) revealed that weak or compromised credentials still cause 80% of hacking-related breaches. Throughout the current pandemic, attackers have been scouring remote workforce applications to gather and sell user credentials on the dark web, even targeting healthcare organizations such as the National Institutes of Health and the World Health Organization. 16. How Machine Learning Prevents Identity Theft With the Big Data gathering precious information, and us leaving our digital footprints all over the internet, it appears that hackers have their hands full. Only in 2018, there were over 3 million identity theft cases in the US. In 25% of them, the amount of money was lost. 17. The Importance of Proper Password Security in 2022 A look at the importance of proper password security in 2022 18. How to Protect Folders And Files in Windows using Passwords Sometimes, we need to apply a bit of extra protection to the data on our computers. We might want to protect our tax records from prying eyes, or lock away business plans from our competitors. Or we might just want to ensure that any children with access to our device can't access inappropriate content. 19. 7 Ways How Hackers Crack Your Passwords DISCLAIMER: The article is intended to be used and must be used for informational purposes only. 20. Passwords Are a Weak Security Link and Stolen Credentials Is Big Business Stolen credentials are big business thanks to poor password management from users and even nefarious actors on the Dark Web creating demand for stolen passwords 21. Mechanism of Password Protection While there are security risks associated with the use of password protection, it is very important to know that there have been cases of stolen passwords. 22. Password Security in 2022 — A Complete Guide A comprehensive guide to password security for all IT managers (and everyone else!). Learn why it is important, the risks of insecure passwords and how you can 23. How Much Has Your Password Grown Up With You? If you are growing up with technology, your password should be grown up too. 24. From Passwords to Passwordless Authentication Passwordless authentication is gradually replacing the password-based authentication practice. The CIA triad of Cybersecurity is changing rapidly. Learn how. 25. Common Web Security Vulnerabilities In the movies, hacking is like fast keyboard typing and hitting the Enter but in the real world, hackers find and exploit vulnerabilities to hack websites. 26. Configure Your Linux With Passwordless Sudo For A Specific User Linux follows tough rules when it comes to permission. Being a root user or sudo user gives you permission to do almost anything which normal user don’t have. Several commands need sudo keyword to run and each time you try to run sudo, Linux asks for a password, today we will configure a passwordless sudo. 27. Saving Passwords with Relative Security [A Guide for Dummies] There is a mystical aura around password creation. Some kind of occult knowledge reached only by the distant cryptographic hermits who ascended to nirvana after decades of meditation on the Patagonian glaciers and liters of instant coffee. In this article, we will try to translate a few drops of this ancient wisdom so that we, mere mortals, have secure accounts to store pictures of cats and e-books that we will never read. 28. The Growing Cyber Risks of a Work From Home  Workforce A recent Threatpost poll found that 40 percent of the companies transitioning to WFH experienced a spike in cyberattacks. The survey concluded that patching and updating are among the top challenges for employees when securing their remote footprint. 29. How Password Issues Plague Help Desk Calls A article on passwords, password security, and how businesses can train employees to handle passwords themselves. 30. How to Go Passwordless with idemeum JavaScript SDK One SDK, 10 minutes of your time, and you can bootstrap passwordless auth for your single-page app. With one SDK, you get all the flows: one-click, WebAuthn, an 31. How Hackers Can Brute-Force Passwords And Find A Correct Key? Brute force attackers guess passwords, passphrases, and private keys in an attempt to eventually get the right answer and crack the security of a system, but how do they know when they have the right key? 32. 3 Ways to Crack WinRAR Password Protected Files This article will explain the 3 best methods to recover WinRAR password protected files. 33. GitHub Security: How To Protect Your Company From Credential Leakage Disclaimer: I am the CEO of GitGuardian, which offers solutions for detecting, alerting and remediating secrets leaked within GitHub, therefore this article may contain some biases. GitGuardian has been monitoring public GitHub for over 3 years which is why we are uniquely qualified to share our views on this important security issue. 34. How to Protect Your Instagram Account from Being Hacked An Overview 35. 63% of data breaches exploit weak credentials - Cybersecurity to support remote workers A look at how to update the old passwords model to support the future of distributed work. 36. Not All Password Managers Are Created Equal: Which is the Best? Web-based password managers have emerged as a response to the proliferation of web applications. 37. Death, Taxes, and Password Negligence: The Inevitability of Pwned Passwords The internet security slang pwned-- pronounced ‘poned’-- is mainly used to indicate administrative control over someone’s computer account or computer. A password that has been pwned is one that has been compromised in some kind of breach, and it means that it’s no longer safe to use. 38. Express.js Integration Guide for Passwordless Authentication with DID.app Just want the code? Find this example on github 39. What Could Have Prevented 2020's Massive Twitter Hack? Attacks and account take-overs like the recent Twitter hack are completely avoidable. Enterprises must implement biometric multi-factor authentication to ensure that only the right users have access to the right systems at all times. If they don’t, users will continue being vulnerable to hacks and scams. 40. How Passwords Get Hacked Fernando Corbato pioneered the first computer password in 1960, being used as a personal point of entry on MIT's Compatible Time-Sharing System (CTSS). Just 2 years later, the CTSS was hacked and has been inspiring hackers ever since. There have been immense technological advancements since 1962 - how is it that today's hackers can get through 2-step authentication, biometrics, and security questions? Cryptographers predict a future that moves beyond passwords, but the issue seems to lie between cybersecurity and human nature. 41. Three Things the Coronavirus Confirmed About Enterprise Security With virtually every non-essential business forced to rely on new technology and embrace different ways of working, the coronavirus pandemic has presented organizations with numerous obstacles. While much attention has been paid to how companies can best navigate these challenges, it’s important that we also recognize another truth emerging from our new normal: enterprise security still leaves much to be desired. 42. The Anatomy of A Strong Passphrase That Is Easy To Remember We all have hundreds of online accounts. Ideally, as many of those accounts as possible have unique passwords. Unique passwords however present a difficult problem: No one can remember hundreds of strong passwords. 43. MFA Vs. 2FA: Which Is Better And More Secure Your 8-character password with numbers, symbols, lowercase, uppercase, and special letters are not enough to shoo away hackers! What to do then? Find out here. 44. The Business Costs of Compromised Passwords Passwords and Their Ability to Bring Down Even the Largest of Enterprises 45. Great Methods To Create A Password File To Prevent Brute-Force Attacks Brute-forcing a really important method that a hacker or a pentester must be aware of and he will use in various places. 46. Authentication Vs. Authorization [Infographic] In online protection systems, authentication and authorization play an important role. They confirm the user's identity and grant your website or application access. In order to decide which combination of web tools best fits your security needs, it is important that you notice their differences. 47. A Guide to Password Hashing: How to Keep your Database Safe Hashing algorithms are one-way functions. They take any string and turn it into a fixed-length “fingerprint” that is unable to be reversed. This means that if your data in your database is compromised, the hacker cannot get the user’s passwords if they were hashed well because at no point were they ever stored on the drive without being in their hashed form. 48. Introduction to Cryptography: Vigenère Cipher [Part 2] Hi again and welcome back to part 2 of the basic cryptography. Previously we discuss about what is cryptography and how fundamental and ancient problem it is in communication science. We talk about ceaser's cipher and how easy it is to break. We also talk about Substitution Cipher which was slight improvement to Ceaser' cipher but can easily be cracked using Frequency analysis technique. 49. A Very Basic Intro to Hash Functions: SHA-256, MD-5, etc This is going to be a basic introduction to hash functions. I will assume most of my audience is here to gain an understanding of why hash functions are used and the basic idea of why they work. My goal is to explain it in a general sense, I will be omitting proofs and implementation details and instead focusing on the high-level principles. 50. Salts and Hashes For the time being, I want you p33ps to ignore the general meaning of these words used in daily context and give a new meaning to them for the current time being. 51. Data Breaches: Why You Should Never Share Your Passwords Data Breaches: Why You Should Never Share Your Passwords 52. Do Passwordless Technologies Have an Impact on Cybersecurity? Contrary to popular belief, traditional passwords are not the best way to protect sensitive information on our digital devices. 53. How to Find Your Saved WiFi Password on iPhone and iPad Learn how to quickly find saved WiFi passwords on your iPhone. Our simple guide helps you retrieve forgotten passwords in just a few steps. 54. Protecting Your Data Online Using Strong Passwords and Two-Factor Authentication: A Guide There's a growing need for better online security, with strong passwords and two-factor authentication. As more of our daily life moves online, more of our personal information is also being stored on the web, along with access details for our personal bank accounts and confidential work data. With cyberattacks on the rise, all of this information needs to be protected from unauthorized access by hackers. 55. The Only 15 Apps I Downloaded and Keep on My MacBook 👨‍💻 Today we'll be looking at my personal top 15 Mac apps. I'm actually quite a minimalist in installing and keeping apps, so these 15 are the only "extra" apps I'm using on my device. 56. The Future of Authentication Strong authentication's war is fought not in the trenches of password management along with more complex passwords, passphrases, or even better multifactor authentication. Instead, this war must start with
fundamental authentication processes as none of the current options will become a long-lasting silver bullet. 57. Web Auth Standard: Guide to Web Authentication API Secure context
This feature is available only in secure contexts (HTTPS), in some or all supporting browsers. 58. BIP 32 Watch-Only Wallets Bitcoin improvement proposal 32 is, in my opinion, one of the most important BIPs we have. (Thanks Peter Wuille!) BIP 32 gave us Hierarchical Deterministic Wallets. That is, the ability to create a tree of keys from a single seed. 59. What devs need to know about Encoding / Encryption / Hashing / Salting / Stretching This is a typical exchange about encryption with someone willing to learn. 60. Passwords Suck: Here Are 4 Ways We Can Fix Them Passwords are a critical part of cybersecurity that individuals and businesses use every day. 61. Things You Must Know About git-crypt To Successfully Protect Your Secret Data Many software projects use secrets - usually, keys to external APIs or credentials to access an external resource such as a database. Your application needs these keys at runtime, so you need to be able to provide them when you deploy your application, or as a step in preparing your deployment environment. 62. 5 Cybersecurity Mistakes You Probably Make Every Day (and How to Fix Them) A look at common cybersecurity mistakes that you are likely doing every day, and what you can to prevent them. 63. Public Key Cryptography: RSA keys I bet you created at least once an RSA key pair, usually because you needed to connect to GitHub and you wanted to avoid typing your password every time. You diligently followed the documentation on how to create SSH keys and after a couple of minutes your setup was complete. 64. 7 Ways to Protect Your Company from Insecure Credentials Verizon’s 2020 DBIR reports that more than 80% of hacking-related breaches involve brute force or the use of lost or stolen credentials— here’s how to prevent weak or compromised credentials from being used in your company’s applications and network Thank you for checking out the 64 most read stories about Passwords on HackerNoon. to find the most read stories about any technology. Visit the /Learn Repo

64 Stories To Learn About Passwords

An Introduction for the Rest of Us In traditional web3 interactions, users often face the burden of performing repetitive tasks to  enable smart contracts to execute specific actions, such as signing transactions and granting approvals. This manual process can become tedious and time-consuming. However, by utilizing programmable key pairs, an additional layer of abstraction is introduced. With programmable key pairs, developers can incorporate logic into a pair of public/private key systems, allowing smart contracts to autonomously carry out advanced actions like executing transactions and automating tasks. This eliminates the need for constant user interaction, streamlining the user experience and enhancing the capabilities of smart contracts. With this innovation, developers can enhance the onboarding experience for web2 users entering web3 by utilizing seedless phrase wallets, web2 authentication for easy sign-on, and automation services for streamlined interactions with decentralized applications. PKP (Or What We Call Programmable Key Pairs) The creation of programmable key pairs (PKP) involves a technique called Distributed Key Generation (DKG). In DKG, multiple parties or nodes contribute to calculating a shared public and private key set. Each node holds a share of this key for signing purposes. DKG was first introduced in 1991 by Torben Pedersen and later improved upon in 1999 by Rosario Gennaro, Stanislaw Jarecki, Hugo Krawczyk, and Tal Rabin. https://en.wikipedia.org/w/index.php?title=Distributed_key_generation&oldid=1171811810 Lit protocol has popularized the application of DKG in creating PKPs. Lit actions, which are smart contracts written in JavaScript, allow developers to code logic into PKPs and customize applications according to their specific goals. This process provides more flexibility compared to self-custody wallets. In the implementation of pkp from Lit protocol, the distributed key pair is controlled by minting it as an ERC 721 NFT. This process is facilitated through Lit's platform( ). The ERC 721 NFT serves as a "symbol" for controlling the distributed key within the Lit network. https://explorer.litprotocol.com/mint-pkp Only the wallet address or smart contract holding this NFT has the authority to determine its usage, set access permissions, revoke permissions, and control what can be signed using the distributed key. PKP and Self-Custodial Wallets (A Differential Look) Prior to PKPs, self-custodial wallets like Metamask were the main way for users to interact with smart contracts and the blockchain. These wallets give users direct control over their actions and assets, but they are not distributed and can be vulnerable to security flaws. They operate on a one-user-to-one private key system and are not programmable. PKPs represent a groundbreaking approach to smart contracts and blockchain interaction, introducing a wide array of innovative possibilities. These include the design of multi-signature wallets that require multiple signatures before transactions can be executed and the automation of smart contracts, enabling them to take actions without the need for end-user involvement. This opens up opportunities for creating subscription-based decentralized applications (dApps) and enhancing the user experience in Decentralized Finance (DeFi) – a suite of blockchain-based applications providing lending, borrowing, and other financial services within the Web3 ecosystem. In their fundamental form, PKPs are distributed, programmable, and immutable. Through the utilization of Lit Actions, which become unmodifiable once published, PKPs maintain a high level of data integrity. Applying PKPs (A Peek Into Their Goodies) With the added advantage of being programmable, pkps hold a lot of potential to further enhance the web3 experience in building innovative applications and enhancing available ones. These use cases include: Defi Automation When it comes to leveraging cryptocurrency in the world of finance, centralized exchanges offer significant advantages. They are easier to set up and provide a wide array of trading tools, making the process more convenient. One crucial tool is the availability of a limit order system, which allows orders to be executed at specific times or price points. PKPs have the potential to bring this functionality to decentralized exchanges and DeFi platforms. By programming such services into dApps and contracts that leverage the programmability of PKPs, these platforms can achieve similar functionalities. Another important use case for PKPs is the ability to handle recurring payments and subscription-based services, similar to what we see in traditional web2 platforms. With PKPs, the execution of transactions can be automated, making it feasible to implement a system that handles recurring payments seamlessly. This feature brings convenience and efficiency to decentralized applications, allowing users to subscribe to services and make regular payments without manual intervention. Infrastructure Decentralized Key Custodian Due to their distributed nature, PKPs are ideal for creating multi-signature wallets that require multiple signatories to confirm a request before a transaction can be fully executed. This feature enhances security and reduces the risk of unauthorized transactions. Additionally, PKPs open up opportunities for designing wallet systems that utilize a multiple seedless approach, where the private keys are not stored in a single location, further enhancing security. One notable project that offers such a solution is Magic Wallet. Magic Wallet ensures that there is no single point of failure or compromise of private keys, providing users with a robust and secure wallet experience. PKPs also play a crucial role in building cross-chain bridges, facilitating the seamless transfer of tokens between different blockchains. These bridges enable interoperability and liquidity across multiple blockchain networks, allowing users to bridge a specific token from one blockchain to another. PKPs provide the programmability and flexibility necessary to create smart contracts and protocols that facilitate the secure and efficient transfer of assets between blockchains. This functionality is vital for the growth and development of decentralized finance (DeFi) ecosystems, as it enables the integration of different blockchain networks and expands the possibilities for asset utilization and liquidity provision. Web3 Social Token-Gated-Content PKPs are ideal for social platforms that offer exclusive content and rewards based on specific criteria like owning a particular NFT. With their programmability, PKPs allow for conditional logic and executions, automating the distribution of rewards and access to exclusive features. This enhances user engagement, gamification, and transparency while reducing reliance on centralized intermediaries. Account Abstraction with support for Web2 Auth methods and on-chain reputation-building PKP, through Account Abstraction with lit action, provides a way for users to access dApps and applications built on web3 using traditional sign-in methods like Google authentication and more. This approach allows for a seamless onboarding experience for users into web3, eliminating the complexities of handling private keys, while still maintaining the secure and decentralized nature of web3. They can also be utilized to track users' activities on apps that aim to rank users based on their participation and diligence, such as regular posting, liking, or commenting activities. By using PKPs, app developers can securely and transparently monitor and record user actions, which can then be used to calculate user rankings and distribute rewards accordingly. This helps incentivize active user engagement, promote community involvement, and fairly distribute rewards based on user contributions. Gaming Wallet Abstraction and Condition-Based Automation Aside from its potential to seamlessly onboard new gamers that are unfamiliar with web3 wallets They can drastically reduce the time players spend manually claiming in-game rewards and selling in-game assets by automating such actions. Quick Start Guide (A Developer’s Approach) Getting started with PKP is as easy as following the developer documentation on ( ) https://developer.litprotocol.com/v2/ For the purpose of this article, I will take you through a quick start on how to use PKP as a wallet. Minting a PKP To begin working with pkps and using them in application logic, one first needs to mint one. Lit protocol provides various ways of minting a PKP. Let’s explore how to mint via webAuthn which works by presenting valid webAuthn credentials generated by your browser to the lit relayer server. To do this, head over to and follow the provided instructions. https://pkp-walletconnect.vercel.app/ Obtaining an AuthSig To initialize a pkpetherswallet, an AuthSig will be needed in order to authorize signing requests. This can be obtained in the browser using the which can be used to obtain an AuthSig from an Externally Owned Account. checkAndSignAuthMessage() import { checkAndSignAuthMessage } from '@lit-protocol/lit-node-client';

const authSig = await checkAndSignAuthMessage({
  chain: "ethereum",
}); When called, triggers a wallet selection popup in the user's browser. The user is then asked to sign a message, confirming ownership of their crypto address. The signature of the signed message is returned as the authSig variable. checkAndSignAuthMessage() Using PKP as a Wallet A comprehensive breakdown of this process can be obtained from the lit documentation ( ) https://developer.litprotocol.com/v2/pkp/usage/ For a basic walkthrough, an installation of the package is required pkp-ethers npm install @lit-protocol/pkp-ethers After installation, the is then initialized with the AuthSig received earlier, and the PkP public key is generated when a pkp is minted. pkpetherswallet import { PKPEthersWallet } from "@lit-protocol/pkp-ethers";

const pkpWallet = new PKPEthersWallet({
  controllerAuthSig: "<Your AuthSig>",
  // Or you can also pass in controllerSessionSigs
  pkpPubKey: "<Your PKP public key>",
  rpc: "https://chain-rpc.litprotocol.com/http",
});
await pkpWallet.init(); This initialized can then be used to sign messages and transactions pkpwallet Sign a Message const message = "Free the web";
const hexMsg = ethers.utils.hexlify(ethers.utils.toUtf8Bytes(message));
await pkpWallet.signMessage(hexMsg); Sign a Transaction const from = address;
const to = address;
const gasLimit = BigNumber.from("21000");
const value = BigNumber.from("10");
const data = "0x";

// @lit-protocol/pkp-ethers will automatically add missing fields (nonce, chainId, gasPrice, gasLimit)
const transactionRequest = {
  from,
  to,
  gasLimit,
  value,
  data,
};

const signedTransactionRequest = await pkpWallet.signTransaction(
  transactionRequest
); The Present Versus the Future The concept of Web3 and the process of creating a secure wallet can initially seem daunting to the average person, as it may appear to require a high level of expertise or even genius-like intelligence to understand. The idea of protecting keys without any means of recovery can be quite intimidating at first glance. Programmable key pairs seek to eliminate this barrier and make accessing Web3 systems as user-friendly as their Web2 counterparts. Furthermore, PKPs empower developers by providing them with the tools to implement complex logic that would have otherwise been challenging to achieve without their use. Although still in their early stages of development, PKPs are paving the way for a more user-friendly Web3 interaction system. This, in turn, is poised to facilitate the wider dissemination and adoption of Web3 technologies.

Understanding Programmable key Pairs From Lit Protocol: A Guide

In an , we learned the basic concepts of identity, authentication, and authorization — important terms that are easily confused by hackers and technologists. earlier post In this post, we will dive deeper and demystify how apps actually implement authentication. Do it right, and you barely notice it. But do it wrong, and you lock users out or open major security holes. We'll see how apps authenticate you, from old-school passwords to slick new standards like WebAuthn, and we’ll get our hands dirty discussing security and usability trade-offs, encryption, individual sovereignty, and more! By the end, you'll have a solid grasp of how real-world apps tackle authentication using the methods we've covered. Let's get started! Authentication 🪪 The first thing you do when you log into an app is identify yourself. This might be using some kind of identifier — typically an email address or phone number — or logging in through Google, Facebook, or some other third-party service, and using their knowledge of your identity instead. Taking that identification and ensuring that it is yours is the process of authentication [1]. Once you’re authenticated, you can use the app! In the , we explained that authentication can be achieved in one of three different ways. You can demonstrate that you: earlier post something know something, or own something are Only the person you're identifying as would know or own this information, or have that identity. All modern apps use a technique that boils down to one of these three methods to authenticate you. So, let’s look at each in turn! Knowledge-Based Authentication 🧠 Password-based authentication uses the first of these authentication methods — it verifies that you something only the user you're logging in as would : their password, pin, passphrase, or any other secret shared between the user and the service. know know To prevent attackers from being able to access your account in case an app’s authentication data is leaked through a hack, the app doesn’t actually store the password, but a hashed [2] version of it. Roughly speaking, the hash of your password is like an encrypted version of your password, except that given your password’s hash, it’s very hard (near-impossible, if hashed correctly) to retrieve the original password [3]. Limitations of Passwords Implementing password-based authentication yourself is fraught with difficulty. Some of the “fun” challenges you can anticipate are: — You need to manage salting, hashing, and encryption, and then store them securely in your database. Properly implementing passwords — You’ll also need to implement email-based password recovery. But what if your password-recovery emails go to spam? Having angry users contact customer support because they can't log in is not fun. Password recovery flows — You'll quickly realize that people like to use weak and easy-to-guess passwords. Handle "password1@3" This could allow hackers to find a password through a [ ] — something they can do if they get access to a leaked version of the database, for example — before later gaining access to the running system. dictionary attack 4 — Users also like to reuse passwords [5], so you might have hackers attacking your system because of a data breach on a completely different website. Blocking these hackers when they’re attacking your site from many different IP addresses is a major challenge [6]. Block bots really - There will be quite a few users who won't have the patience to go through the password-recovery flows after forgetting their password. Instead, they just give up and go do something else. Additional friction Forcing your user to remember something to log-in can add additional friction and increase churn. And much more [7] Each of these steps is hard and requires scarce engineering resources, which is why authentication providers such as , , and offer managed versions, at a cost. Supabase Auth0 Clerk But most significantly, users may forget their password and never even use your site in the first place! To summarize: passwords are a poor authentication mechanism. They’re hard to implement, unsafe, and lead to a poor user experience! So, is there a way to authenticate users without relying on something that only they would know? I wouldn’t still be writing if there wasn’t, so let’s get into that! Ownership-Based Authentication 🔒 Ownership-based authentication is our second authentication method — it involves verifying that you something that only the user you are attempting to log in as would , such as their email inbox or phone number. own own One-Time Passwords For instance, when you log in, an app might send you a one-time password (OTP [8]) via email. This is typically a random short, server-generated, alphanumeric code like , but it can also be a , which is a URL containing the OTP as part of it. ZXY1 magic link The OTP is a temporary secret that is only shared between the app and the user's email inbox, is valid for that specific interaction, and is invalidated once used. If you log in using this OTP, then you’ve successfully demonstrated ownership of the email address connected to the user account, and so you must be that user — you’re successfully authenticated! SMS-based logins can also be used, but SMS is not encrypted and can easily be discovered by anyone on the network by sniffing for text messages [9]. SMS-based logins can also be gamed for — a big reason why many apps no longer solely rely on SMS for authentication, or even only offer SMS-based authentication for premium or paying users. profit But worst of all, SMS and emails may take minutes to be delivered, or may never be delivered at all [10]! Is there a way for the user and service to coordinate on a shared, time-based secret, without sending it over an insecure, slow, and unreliable communication channel? I haven’t stopped writing, so yes! Time-Based One-Time Passwords Authentication apps, such as Google Authenticator, provide OTPs (TOTP [11]). time-based These authentication apps are set up well in advance of logging in, typically during the first onboarding session. Instead of using SMS or email to send the OTP to the user, an app on the user’s device generates a TOTP using the current time and a secret shared between the user and the web app. This is much safer than SMS or email OTP delivery, as it does not rely on the security of external communication channels. The TOTP is generated locally on a device the user possesses and controls, making phishing and interception attacks much more difficult. Hardware Authenticators Finally, hardware security keys, such as a YubiKey [12], are a physical authentication device that a user can carry around with them. These are often used in high-security environments, such as in an enterprise, and can also create OTPs. These are really powerful devices, and we’ll dig into them more soon. Whilst ownership-based authentication methods are often more secure, easier to use (no need to remember a password!), and easier to implement than passwords, they still require the user to do to authenticate. something cumbersome This is an opportunity to switch devices, get distracted, churn, and never use your app at all! For this reason, authentication methods that require the user to switch devices are used sparingly, only for sensitive operations such as when logging in on a new device for the first time. So — can we authenticate a user without requiring them to use two devices? Absolutely! WebAuthn 🕸️ WebAuthn [13] is an awesome, new(ish) protocol that allows users to authenticate themselves whilst browsing the web. Instead of using emails, passwords, YubiKeys, or OTPs, the information needed to authenticate a user is stored in an — typically the browser or device. authenticator Public-Key Cryptography The method used for authentication is public key cryptography. It’s the same technology used in Transport Layer Security (TLS) — a networking protocol that is used for nearly all traffic on the internet. It’s fundamental to security, so let’s take a quick aside to dig in: The idea behind public-key cryptography, or asymmetric encryption, is pretty simple: each person has two keys — a public and private key. The public key is shared with everyone, and the private key is kept to themselves. Seems pretty simple so far. But we can now do two things: magical Anyone can send the user a message by encrypting it with the user’s public key. Only the owner of the private key — the user — is able to decrypt that message. The user can use their private key to a message. Anyone with the public key can verify that that user signed the message, and no one other than the user is able to sign it as that user. sign Public-Key Cryptography in WebAuthn The browser or device, acting as an authenticator, a new public/private key pair as the user onboards onto a web service. The private key is kept hidden, potentially stored securely in a hardware security module (HSM [14]) on the device, and the public key is shared with the web service. generates When the user later wishes to log in, the website asks the browser to a specific message. The browser or device does so using the private key, the website verifies it is indeed the same user using the previously shared public key, and the user is now authenticated! sign has an awesome demo of this — try it out! https://webauthn.io With WebAuthn, the user doesn’t need to type their username or remember a password and can log in with a single click — very impressive! And excitingly, the prompt to log in with WebAuthn will only appear on the correct site, thereby preventing the phishing attacks that were possible with passwords 🎉. But logging in with a single click also makes it easy for friends, enemies, and attackers to log in with a single click if they get close enough to your machine. So, can we ensure it’s actually doing the clicking? Surely! you Multi-Factor Authentication The HSM can actually prompt the browser for before it allows access to cryptographic operations, such as generating a public and private key or signing a message. And the browser can prompt the user for this data in turn. something The prompt can ask for a password — another example of knowledge-based authentication — or, even better, ask for , such as your fingerprint or face. biometrics Laptops and mobile phones commonly support fingerprint readers, so this is a fast, easy, and secure [15] way for users to authenticate. Clicking a button to sign in and using your fingerprint is multi-factor authentication since it requires forms of authentication for you to log in: ownership of the device with the HSM and your inherent identity and ownership of your fingerprint. two And because you attest to your own identity, this is a form of — we’ll talk about this more in the next post. self-sovereign identity Cross-Device Authentication WebAuthn does pose a problem, though. Users typically use a website on multiple devices: their phone, tablet, and laptop. It’s easy to share a password between devices — does WebAuthn offer something similar? Yes! Well, sort of. You can the authentication to a roaming device — which could be your phone, laptop, or YubiKey — anything that is accessible via Bluetooth, NFC, or USB. In turn, that device can sign the message on behalf of the main device. delegate This is an additional layer of protection since malware on a site would need to infect an entirely different device than the main one you’re using to steal your private key — neat! However, this means that we’d always be reliant on that first device for logging into that service, or we would need to set up a private key on device we want to log in from — hardly a good user experience, and potentially worse than multi-factor login using passwords and OTPs. each Limitations of WebAuthn WebAuthn isn’t a panacea, and does come with some notable downsides: — If you lose a device, you’ll lose access to of your logins that that device stores the private keys for. Recreating those logins would take , and would be a massive pain! Single point of failure all ages Passkeys [16] are an exciting new feature to help plug this gap and share private keys across devices, allowing for ease of access and easy recovery. The fun part is that Google [17] and Apple’s iCloud would sync these private keys for you — it’s built into the platform! As excited as I am about Passkeys, they are new and controversial [18, 19], and it’s unclear if they’ll achieve mass adoption. Passwords are flexible enough to support most flows that users need [20]. In contrast, WebAuthn only supports a subset of flows. Inflexibility — For example, sharing access to a single account (e.g., to access the bills of an energy provider) with a friend is straightforward with passwords but much tricker with WebAuthn. — Perhaps most important is that users aren’t familiar with the passwordless world. Uncertain adoption Will they onboard? Will they log in again on a new device? Will they understand the user flow? We don’t know yet — and it’s a risk to try out something as innovative as this. Whilst I really want a passwordless future and think WebAuthn and Passkeys could be our savior, there’s one more form of authentication that is widely used and worth learning about. Identity-Based Authentication 🙋 The third way we can authenticate is to use something we — our identity. Biometric authentication is one example of this, and we briefly covered it in the last section. are But we can also implement this by outsourcing identity verification to a third party that users already have an account with — an [22]. identity provider When you see “Login with Google” or “Login with Facebook”, that's identity-based authentication in action. The identity provider tells the app that you are indeed the person you claim to be by providing it with a ID token. signed When the app you’re signing into gets this token, it uses the signature to verify that the identity provider did indeed create that token — and now you’re fully authenticated! OpenID Connect OpenID Connect (OIDC [22]) is the underlying protocol used for this flow. OIDC is a layer on top of OAuth 2.0 — a protocol used for access delegation [23] — that standardizes identity data like your name and email address. Big tech giants like Google, Facebook, Twitter, and Microsoft all offer identity services that implement OIDC. It's easy and convenient for users since they can leverage their existing accounts. And it saves a ton of headaches for developers since they no longer need to build secure authentication systems. Instead of authenticating a user yourself, just plug into Google, and you're done! This is an example of identity [24], where a user’s identity is used across multiple systems — Google, Facebook, and all the apps that rely on these identity providers — instead of just one. federated Limitations of Identity Federation However, identity federation has a fundamental flaw: the identity provider can revoke access at any time, instantly locking you out of all sites. You don’t your identity — it’s stored on Google’s servers, not yours. own You may think it’s rare, but it’s surprisingly common [25, 26] to find posts on Hacker News of users being denied access to their Google or Facebook accounts due to one reason or another, and totally unable to access any service that they used Google or Facebook as an identity provider for. The quest for true user-owned identity is an active area of innovation which I'll cover in an upcoming post! Subscribe now to be updated when it’s released 👇 Thanks for reading Mindful Musings! Subscribe for free to receive new posts and support my work. I would love to hear folks’ thoughts on this — feel free to comment below or me! DM Have a great week all — stay tuned for Part 3! Authentication is, in fact, broader than simply validating your identity — it can refer to proving assertion, such as your age being greater than some threshold, that you have a valid driving license, or that you have enough funds in your bank. 1 any . 2 https://en.wikipedia.org/wiki/Cryptographic_hash_function We can make the hash even harder to crack by adding salt to the original — random data that prevents attackers from using pre-computed data to guess your original password. 3 . 4 https://en.wikipedia.org/wiki/Dictionary_attack About 64% of people reuse at least one password across multiple services: . 5 https://auth0.com/blog/what-is-credential-stuffing . 6 https://en.wikipedia.org/wiki/Bot_prevention There are a few other reasons why passwords are challenging — and many of these are outside of your control as an app developer. 7 Malware can log the keys the user presses whilst typing the password to secretly exfiltrate it, an enemy (or friend!) could watch over your shoulder as you type it in (this is known as ), and phishing attacks could prompt the user to enter their password when they’re on a similarly branded but malicious website. shoulder surfing . 8 https://en.wikipedia.org/wiki/One-time_password . 9 https://security.stackexchange.com/questions/112111/capturing-text-messages-on-the-fly . 10 https://messageiq.io/sms-deliverability . 11 https://en.wikipedia.org/wiki/Time-based_one-time_password . 12 https://en.wikipedia.org/wiki/YubiKey . 13 https://webauthn.io . 14 https://en.wikipedia.org/wiki/Hardware_security_module Your biometrics are stored securely, and never leave your device — they’re only used to unlock the HSM used to store your private keys. 15 . 16 https://simplewebauthn.dev/docs/advanced/passkeys . 17 https://blog.google/technology/safety-security/the-beginning-of-the-end-of-the-password . 18 https://auth0-com.cdn.ampproject.org/v/s/auth0.com/blog/amp/our-take-on-passkeys 19 https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/ 20 https://jrhawley.ca/2023/08/07/blocked-by-cloudflare. . 21 https://en.wikipedia.org/wiki/Identity_provider . 22 https://en.wikipedia.org/wiki/OpenID#OpenID_Connect_(OIDC) . 23 https://en.wikipedia.org/wiki/OAuth#OAuth_2.0 . 24 https://en.wikipedia.org/wiki/Federated_identity . 25 http://zuckbannedme.com . 26 https://www.google.com/search?q=lost+access+google+account+site%3Anews.ycombinator.com 😆 This piece was originally posted on the Koodos Labs engineering — follow there for updates on what we’re working on! blog Also published here

Identity, Authentication, and Authorization: An Extensive Guide to Get You Up to Speed

Some effective PWA security practices include HTTPS and SSL/TLS implementation, reliable user authentication, certificate pinning, up-to-date security protocols, RASP solutions, and strict content review protocols. Incorporating these solutions in the app is the best way to protect the application from the most common and harmful security risk, data breach. For example, Meta (Facebook) witnessed a data breach in 2021 where the personal information (like profile bio, birthdate, full name, previous location, and relationship status) of users was stolen and leaked on a hacking forum for free. 533 million Preventing such legally and financially harmful security threats requires the expertise and assistance of an Application Security Manager (ASM) and a small or big team of security engineers, depending on your application. Application security managers and engineers have the necessary training required to safeguard a progressive web app from various security threats like cookie hijacking (session hijacking), cross-site scripting (XSS), data breach, cross-site request forgery (CSRF), injection attacks, broken access control, cryptographic failures, unauthorized and non-consensual redirects or forwards, security misconfigurations, and insecure direct object references (IDOR). Hiring them can help you build established and reliable platforms like well-known PWA apps such as Tinder, Twitter, Pinterest, and Starbucks by preventing damaging PWA security threats, which can lead to customers. Consequently, it will make it easy for you to benefit from the rapidly growing progressive web app market (Its value is estimated to reach by 2027). $10.44 billion Keeping that in mind, here you can learn about several highly effective security practices to understand how to protect a PWA-based platform and business. 9 PWA Security Best Practices The most crucial thing to remember about PWA security is that they always have vulnerabilities if you do not regularly implement new protocols, update them, and test their capabilities toward system security. And as mentioned above, you must hire an application security manager (ASM) in your PWA development team to incorporate the security protocols effectively. Implement Secure and Tested Authentication Poor authentication is a security vulnerability that leads to data theft and leaks in PWA applications. Avoiding this threat requires highly advanced authentication protocols like passwords, certificate-based authentication, multi-factor authentication, and biometric authentication. For that, you may use authentication APIs and follow the standards of (WebAuthn) and UAF. Web Authentication Organizations using a PWA app for business operations and employee management can use identity and access management (IAM) solutions for authentication. It will enable them to limit and compartmentalize access to the PWA app according to their positions/titles. Such solutions prevent unauthorized access and protect sensitive/confidential information from leaking or falling into the wrong hands. Use HTTPS and SSL/TLS Sending, receiving, processing, and managing data is a crucial function of many progressive web apps. Therefore, securing this process is essential to protect customer and organizational data from theft and leakage. HyperText Transfer Protocol Secure ( ) enables secure communication and data transmission between a web browser and a web server using encryption, preventing unauthorized access and data security issues. HTTPS Over of all websites currently use the HTTPS protocol. 82.7% HTTPS implementation requires the installation of SSL/TLS certificates on your PWA server. Google, Facebook, and Youtube are among the top websites using HTTPS. HTTPS offers Improved data security and protection from MITM and phishing attacks. Similar to HTTPS, Transport Layer Security (TLS) and Secure Sockets Layer (SSL or Certificate Pinning) are cryptographic protocols that improve the security of communications and data transmissions between applications, web browsers, and servers. You can use or based on your budget. However, paid SSL certificates are usually more reliable and provide better validation and protection guarantee against data breaches than free certificates. free paid SSL certificates Use a Web Application Firewall (WAF) With continuous monitoring and filtering, A can protect a progressive web app from various security threats like malicious HTTP/S traffic, cross-site scripting (XSS), SQL injection attacks, file inclusion, cross-site request forgery (CSRF), and cookie poisoning. What makes WAF a uniquely effective solution is its ability to monitor, identify, and deal with security threats in real-time. web application firewall The top web application firewalls to choose from are: Azure Web Application Firewall Cloudflare WAF AWS WAF Imperva Web Application Firewall (WAF) F5 WAF HAProxy WAF Conduct Penetration and Security Testing Penetration and security testing is the best way to evaluate the security of PWA applications. These testing solutions are necessary for with top-of-the-line and reliable security protocols. However, QA engineers can conduct these tests before and after development from time to time to monitor, identify, and deal with security vulnerabilities before they turn into a threat. Penetration and security tests involve simulated cyber attacks against your application to evaluate the capabilities and vulnerabilities of its security protocols. building a PWA A recent found that 75% of organizations use penetration testing protocols for compliance, while 57% implement them for vulnerability management. cybersecurity survey You need skilled and experienced QA engineers in your PWA development team to conduct these tests effectively. They will safeguard a PWA platform from several security issues that can cause many legal and financial problems (such as payment data and personal information theft/leaks). Keep Security Protocols Up to Date Every app can have security solutions for protecting user and organizational data. For example, Tinder has extensive for detecting, preventing, and dealing with security vulnerabilities. But these protocols can lose effectiveness with time due to changing security needs and an increased number of skilled hackers/cybercriminals. Such outdated, untested, and weak security protocols can lead to several security issues in a progressive web app (data theft/leakage being the most common). security protocols recognizes as one of the top 10 security risks in web applications. Therefore, a PWA app owner must regularly test the reliability of all its security solutions and update them, whether the security solution is a web application firewall or biometric authentication. OWASP Vulnerable and Outdated Components Penetration testing is a great way to ensure the reliability of old, new, and updated security solutions. It helps identify PWA security threats and vulnerabilities from the perspective of attackers/hackers. Enforce Strict Content Review Protocols Incorporate strict review protocols for all content (text-based, visual, and digital) that will be received, processed, and stored in the database of the progressive web app. App owners can use automated systems and manual protocols to conduct such content review protocols. They help identify potentially harmful/risky content from getting added to the PWA application database, which helps prevent and destroy various security threats at their roots. You can get your application security manager and web content management system (Web CMS) manager to review and monitor all content on your progressive web app. Incorporate Captcha Security and Secure Cookies security protection has become a necessary solution due to the rise of bot attacks (malicious bots). It helps verify that the user accessing the progressive web app is an actual person and not a programmed/automated malware bot. Captcha As mentioned above, all security solutions require updates and pen testing to confirm their effectiveness. And captcha security is a solution that will require more frequent updates and testing since the capabilities of bot attacks keep increasing with automation. The easiest way to implement captcha security in your PWA platform is by . creating a reCAPTCHA account help progressive web app owners protect user and organizational data through encryption and better authentication, preventing data theft/leakage and unauthorized access. You can check out the quick guide by OWASP to incorporate the in your PWA app. Secure cookies secure cookie attribute Create a Content Security Policy (CSP) Content Security Policy (CSP) is a standard that helps protect applications from security threats like cross-site scripting (XSS) and injection attacks. The policy helps control resources (like scripts and images) that can be allowed to load for a given page, depending on the sources of that content. CSP helps protect a PWA application from many easily overlooked security issues and improves its overall performance. A quick guide for CSP implementation: Create directives, policies, or source values to determine which resources will your PWA platform allow or restrict. Integrate CSP with HTTP response header. Implement and enforce the content security policy with an HTTP header. Or add your CSP through meta tags. You can also check out some for more information and guidance. CSP examples Implement RASP Solutions Runtime Application Self-Protection (RASP) solutions can analyze applications (user behavior) and traffic to identify, report, and block threats that could lead to cyber-attacks. This solution will closely monitor the PWA application system to identify and report security vulnerabilities. It can help the app owner deal with security issues before they cause unrecoverable damage to the PWA platform. For RASMP implementation, you may use widely recommended tools like , , , , , and . Imperva Fortify Application Defender Signal Sciences Hdiv OpenRASP Contrast Security What makes RASP better than other security solutions is its focused approach toward behavior and traffic monitoring, which can reveal the causes of most security attacks in PWA applications. Real-time protection, increased transparency/visibility in application security protocols, improved accuracy, and zero-day attack prevention are well-known benefits of RASP solutions. Conclusion Incorporating various security solutions in a progressive web application will require the expertise of app developers, application security managers, and engineers. It is the only way to ensure the solutions can protect the application as effectively as necessary. An application security manager can evaluate the PWA app, implement new solutions, and update the old ones to meet the changing security requirements. Other than that, a few other things you can do are - create a user-driven privacy policy and minimize excessive sensitive/confidential data in the progressive web app. Ambiguous/poor privacy policies and too much sensitive data create vulnerabilities, easily avoidable in almost any application. In short, securing a PWA app is about consistency in ensuring and verifying application security, managing expectations, regular updates, and hiring app developers that follow a value and security-driven strategy.

9 PWA Security Practices to Safeguard From Cyber Threats

161 Stories To Learn About Authentication

Since the three digital leaders, Apple, Google, and Microsoft, are pushing passkeys as the new login standard, the current technical support for passkeys is already very high. In this article, we will share our insights on the current data we gained over the past six months. Passkeys are the new standard for authentication. Passkeys are the latest technological advancement in login standards: Due to their technical concept, they are very secure by design and provide the best customer experience currently possible in logins. The three big platform and operating system leaders, Apple, Google, and Microsoft, enforce passkeys as the new standard. What does “passkey-ready” mean? (e.g., via facial recognition, fingerprint scan, or PIN pattern). In general, there is a further distinction between passkeys that are available on a single device and passkeys that are automatically synced in a cloud account (e.g., via Apple iCloud KeyChain, Google Password Manager, or Microsoft account). In the following, we include both types of passkeys for the analysis. Passkey-ready means a device can create and use passkeys for authentication The current technical support in practice is already very high, with over 80% of all devices supporting passkeys (see data below). All three major platforms have announced their full support meaning passkeys will be available on all new devices and thus will be available on most devices soon. Apple’s Passkey Push: Synced passkeys: available on iPhones with iOS 16+, iPads with iPadOS 16+, and MacBooks with macOS Ventura, Monterey, and Big Sur Non-synced passkeys: available for iPhones with iOS 15+, iPads with iPadOS 15+, and MacBooks with macOS Catalina+ Google Passkey Push: Synced passkeys: available on Android devices with Android 9+ Non-synced passkeys: available on Android devices with Android 7+ Microsoft Passkey Push: Synced passkeys: available soon with a new Windows Hello update Non-synced passkeys: available for devices with Windows 10 (activated Windows Hello) and Windows 11 In 2023, >80% are already “passkey-ready.” To validate if the vast majority of your customers are "passkey-ready,” Corbado built a free tool that analyzes how many of your users are technically ready to use passkeys. Thereby, the following data is gathered and used for the analysis: support: the device and browser combination’s support for WebAuthn, the underlying technology of passkeys WebAuthn support: the existence of a device’s built-in authenticator (e.g., Face ID, Touch ID, or Windows Hello) Platform auth support: the device and browser combination’s support for Conditional UI allows to automatically fill in passkey, including the identifier in login forms, which is another significant advancement in authentication Conditional UI ‍ In our , , and , users have been able to test passkeys over the past six months. We have evaluated anonymous, technical data regarding their passkey readiness. Overall, the number of visitors was a medium-sized four-digit number in the analyzed months. demo developer panel website Based on that, the following insights were gained: Almost of devices and browsers . This was expected as mainly digital users with modern devices and browsers visited our services. Checking the raw data, there was just a tiny fraction (less than 0.1%) using an outdated browser or device. 100% support WebAuthn is available on 80% of the devices, and the trend is increasing. This was very interesting to see that most devices already have the hardware to use passkeys (e.g., facial recognition, fingerprint scanner, or PIN pattern). This also proves that a lot of desktop devices already support passkeys. We expect this number to increase as old devices are replaced over time. Platform auth support of device and browser combinations . From the data, it is evident that the support increased drastically when Chrome and Safari announced their support and made it available for all users (before, it was only available for developers, which explains the low support). Over 70% support Conditional UI To sum these findings up: most (>80%) user devices are passkey-ready today (based on the visitors from our sites). We keep analyzing the data and expect platform auth and Conditional UI support to increase steadily over time. Determine your users’ passkey-readiness with Corbado’s free passkeys analyzer. To prove that the vast majority of users are "passkey-ready," we have developed a free tool that analyzes how many of your users’ devices are technically able to use passkeys. As passkeys are the new login standard on the web, everyone offering some form of login should consider integration into websites and apps soon. If you are unsure how many of your users are passkey-ready, you can find out with our free passkey analyzer. It’s riskless and has no lock-in. With two lines of code added to your website or app, you can start analyzing. The passkeys analyzer is fully GDPR-compliant, anonymous, and uses no cookies. It can be integrated in less than five minutes and has no impact on the user experience. <script src="https://analyze.corbado.com/assets/bundle.js"></script>

<script>tracking.visit(window, PublicKeyCredential, pro-xxx)</script> Start analyzing now and then offer passkey logins to these users. Trust us: once they experience passkey, they will use and demand them. Besides insights regarding passkey readiness, the passkey analyzer also provides data regarding total visitors and used browsers and operating systems. Use our and find out your users’ passkey-readiness! passkey analyzer

80% Devices in 2023 Are Already Passkey-Ready: Apple, Microsoft, and Google Pushing It Even Higher

El 80% de los dispositivos en 2023 ya están listos para Passkey: Apple, Microsoft y Google lo impulsan aún más

80 % des appareils en 2023 sont déjà prêts pour les clés : Apple, Microsoft et Google vont encore plus loin

2023 में 80% डिवाइस पहले से ही पास-की-रेडी हैं: Apple, Microsoft और Google इसे और भी अधिक बढ़ा रहे हैं

2023 年にはデバイスの 80% がすでにパスキーに対応: Apple、Microsoft、Google がそれをさらに押し上げています

80% dos dispositivos em 2023 já estão prontos para a senha: Apple, Microsoft e Google avançando ainda mais

80% thiết bị vào năm 2023 đã sẵn sàng cho Passkey: Apple, Microsoft và Google sẽ đẩy nó lên cao hơn nữa

2023 年 80% 的设备已经准备好密码：苹果、微软和谷歌将其推得更高

Stories, News & Mentions about WEB3AUTH

Web3auth’s Stories on HackerNoon