47 Matching Annotations
  1. Last 7 days
    1. Another thing you can do is to add pain to the second part of it. Attackers want the list of valid usernames, so they can then try to guess or brute force the password. You can put protections in place with that as well, whether they are lockouts or multi-factor authentication, so even if they have a valid username, it's much harder to gain access.
  2. Oct 2020
    1. We can utilise the router() to check if there is a user variable stored, or if the user is authenticated, and then if not redirect to a login page.
  3. Sep 2020
    1. I have a middleware that extracts the bearer token from the session (on both client and server) and adds it as an authorization header in the fetch request. This approach isn't perfect but it works reasonably well. At some point I will probably use the cache from the server request to the client by passing it in the session object.
  4. Jul 2020
    1. For example, a parent or guardian could be asked to make a payment of€0,01 to the controller via a banktransaction, including a brief confirmation in the description line of the transaction that the bank account holderis a holder of parental responsibility over the user. Where appropriate, an alternative method of verificationshould be provided to prevent undue discriminatory treatment of persons that do nothave a bank account.
    2. The EDPBacknowledges that there may be cases where verification is challenging (for example wherechildren providing their own consent have not yet established an ‘identity footprint’, or where parentalresponsibility is not easily checked.
  5. Jun 2020
  6. May 2020
    1. With a few API endpoints you can use a GitLab CI/CD job token to authenticate with the API: Get job artifacts Pipeline triggers Release creation
    1. NOTE: Note: If you have 2 Factor Authentication enabled in your account, you need to pass a personal access token instead of your password in order to login to GitLab's Container Registry.
  7. Apr 2020
    1. Although it can be inconvenient, the two-factor authentication is the easiest and best way to keep your accounts from getting hacked. Whenever you log into an account from a new device, it will send an email or a text with a code that you input with your password.
    1. One of the drawbacks of waiting until someone signs in again to check their password is that a user may simply stay signed in for a long time without signing out. I suppose that could be an argument in favor of limiting the maximum duration of a session or remember-me token, but as far as user experience, I always find it annoying when I was signed in and a website arbitrarily signs me out without telling me why.
  8. Mar 2020
    1. Open Authentication (OAuth) coordinates with your “third party” accounts (think Facebook, LinkedIn, Twitter) and verifies your identify through an existing profile, which requires authentication, such as a CAPTCHA, to create in the first place. The result of OAuth, as it is known to developers, is “secure delegated access,”
    2. One article even proclaims the death of passwords for gaming apps because of this new trend. This could signal a big change for security (assuming every user has a mobile number).
  9. Dec 2019
    1. An authentication factor is a piece of information used to verify that you’re allowed to do something, like a keycard used to unlock a hotel door.
  10. Jul 2019
    1. Authentication (from Greek: αὐθεντικός authentikos, "real, genuine", from αὐθέντης authentes, "author") is the act of proving an assertion, such as the identity of a computer system user.

      The assertion does not need to be about an actor's identity per se?

  11. Apr 2019
  12. Nov 2018
  13. May 2017
    1. Antoine Amarilli fait remarquer le d ́es ́equilibre apparent de la situation actuelle, o`ul’association devrait payer ORCID pour avoir le droit de leur fournir des donn ́ees. L’AGdemande si d’autres acteurs se trouvent dans une situation analogue `a la nˆotre. Anto-nin Delpeuch rappelle que les outils de gestion de recherche vendus aux universit ́es lesplacent dans une sitation similaire `a la nˆotre ; `a leur ́echelle, cependant, le montant dela cotisation `a ORCID ne repr ́esente pas un probl`eme de la mˆeme ampleur.

      Solid which is a decentralised authentication protocol may be of interest.

  14. Apr 2017
  15. Feb 2017
  16. Oct 2016
  17. Apr 2016
    1. A delegated solution means that one site is simply outsourcing its authentication needs to another pre-selected site. If your site uses Facebook Connect, you are delegating your authentication facilities to Facebook. Visitors to your site cannot use any other accounts, only accounts from the vendors you have pre-selected. A federated solution means that visitors to your site can use any account they have, as long as it is compatible. It makes no difference to the site which account is being used, as long as it can interoperate. At its core, OpenID is a federated solution because its most important feature is the ability to use any OpenID account with any OpenID-enabled service. A good example is stores accepting credit cards. A store that accepts any Visa card is using federated payments – payments from any account that “speaks Visa”. But a store that accepts only credit cards issued by a specific vendor, for example, a department store branded card, use delegated payments. The reason why you no longer see many stores accepting only their own credit cards, is because it is bad for business. But not every OpenID implementation is federated, and this is the big dilemma OpenID has to resolve. The question is, can users use any account they want? If a site uses the Yahoo! OpenID service by using the Yahoo! button: but does not offer the ability to use other vendors, it is really just another delegated solution, even if it is powered by OpenID under the hood. In this case, OpenID becomes just a technical detail of the implementation, not part of its design. Much of the recent discussion about OpenID usability centers around using brands as a way to make the service more usable. But the problem with this approach is that is takes away most of the federated value out of OpenID, leaving it simply as a common protocol to implement proprietary delegated services. When implemented this way, OpenID adds no real value to services with an OAuth API. The question which solution to use for sign-in, OpenID or OAuth, is very much application specific. If you are building a brand new site that needs accounts, and want to leverage existing accounts from services such as Google, Yahoo!, and Microsoft, OpenID is a great option that will give your users a lot of flexibility. But if you are extending an existing service, implementing a specific API and building a site that has great dependencies on another service, OAuth gives you everything you need, for very little extra work. It is all about using the right tool for the job.
  18. May 2015
    1. Last week we talked about giving away your passwords and how you should never do it. When a website wants to use the services of another—such as Bitly posting to your Twitter stream—instead of asking you to share your password, they should use OAuth instead. OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password. This is a quick guide to illustrate, as simply as possible, how OAuth works. The Actors There are 3 main players in an OAuth transaction: the user, the consumer, and the service provider. This triumvirate has been affectionately deemed the OAuth Love Triangle. In our example, Joe is the user, Bitly is the consumer, and Twitter is the service provided who controls Joe’s secure resource (his Twitter stream). Joe would like Bitly to be able to post shortened links to his stream. Here’s how it works: Step 1 – The user shows intent Joe (User): “Hey, Bitly, I would like you to be able to post links directly to my Twitter stream.” Bitly (Consumer): “Great! Let me go ask for permission.” Step 2 – The consumer gets permission Bitly: “I have a user that would like me to post to his stream. Can I have a request token?” Twitter (Service Provider): “Sure. Here’s a token and a secret.” The secret is used to prevent request forgery. The consumer uses the secret to sign each request so that the service provider can verify it is actually coming from the consumer application. Step 3 – The user is redirected to the service provider Bitly: “OK, Joe. I’m sending you over to Twitter so you can approve. Take this token with you.” Joe: “OK!” <Bitly directs Joe to Twitter for authorization> Note: This is the scary part. If Bitly were super-shady Evil Co. it could pop up a window that looked like Twitter but was really phishing for your username and password. Always be sure to verify that the URL you’re directed to is actually the service provider (Twitter, in this case). Step 4 – The user gives permission Joe: “Twitter, I’d like to authorize this request token that Bitly gave me.” Twitter: “OK, just to be sure, you want to authorize Bitly to do X, Y, and Z with your Twitter account?” Joe: “Yes!” Twitter: “OK, you can go back to Bitly and tell them they have permission to use their request token.” Twitter marks the request token as “good-to-go,” so when the consumer requests access, it will be accepted (so long as it’s signed using their shared secret). Step 5 – The consumer obtains an access token Bitly: “Twitter, can I exchange this request token for an access token?” Twitter: “Sure. Here’s your access token and secret.” Step 6 – The consumer accesses the protected resource Bitly: “I’d like to post this link to Joe’s stream. Here’s my access token!” Twitter: “Done!” Recap In our scenario, Joe never had to share his Twitter credentials with Bitly. He simply delegated access using OAuth in a secure manner. At any time, Joe can login to Twitter and review the access he has granted and revoke tokens for specific applications without affecting others. OAuth also allows for granular permission levels. You can give Bitly the right to post to your Twitter account, but restrict LinkedIn to read-only access. OAuth Isn’t Perfect…Yet OAuth is a solid solution for browser based applications and is a huge improvement over HTTP basic authentication. However, there are limitations, specifically with OAuth 1.0, that make it far less secure and less user-friendly in native and mobile applications. OAuth 2.0 is a newer, more secure version of the protocol which introduces different “flows” for web, mobile, and desktop applications. It also has the notion of token expiration (similar to cookie expiration), requires SSL, and reduces the complexity for developers by no longer requiring signing.