115 Matching Annotations
  1. Jan 2024
    1. less secure sign-in technology

      What does that mean exactly?

      All of a sudden my Rails app's attempts to send via SMTP started getting rejected until I enabled "Less secure app access". It would be nice if I knew what was necessary to make the access considered "secure".

      Update: Newer information added to this article (as well as elsewhere) leads me to believe that it is specifically sending password directly as authentication mechanism which was/is no longer permitted.

      This is the note that has since been added on this page, which clarifies this point:

      To help keep your account secure, from May 30, 2022, ​​Google no longer supports the use of third-party apps or devices which ask you to sign in to your Google Account using only your username and password.

    2. To help keep your account secure, from May 30, 2022, ​​Google no longer supports the use of third-party apps or devices which ask you to sign in to your Google Account using only your username and password.
    1. To keep your account more secure, Gmail no longer supports third-party apps or devices which require you to share your Google username and password. Sharing your account credentials with third-parties makes it easier for hackers to gain access to your account.
  2. Dec 2023
    1. Token-based authentication is stateless - it does not store anything on the server but creates a unique encoded token that gets checked every time a request is made.
    2. Token-based authentication (also known as JSON Web Token authentication) is a new way of handling the authentication of users in applications. It is an alternative to session-based authentication.
    1. A traditional account linking flow requires the user to enter their credentials in the browser. The use of App Flip defers user sign-in to your Android app, which allows you to leverage existing authorizations. If the user is signed in to your app, they don't need to re-enter their credentials to link their account.
  3. Nov 2023
    1. Authentication establishes who someone is, and is commonly referred to as user sign-up or sign-in. Authorization is the process of granting or rejecting access to data or resources.
  4. Sep 2023
  5. May 2023
    1. “Multi-factor authentication needs multi-factor enrollment,” noted Taku. It shouldn’t have been possible to enroll just using a stolen password. He listed numerous possibilities, among them credentials handed out in person, a one-time password, or a PIN sent to the employee’s registered email or mobile.
  6. Apr 2023
    1. Whereas U2F only supports multi-factor mode, having been designed to strengthen existing username/password-based login flows, FIDO2 adds support for single-factor mode.
  7. Mar 2023
    1. If you can unlink your address from a locked out account and then link it to a new account and add new 2FA factors to new account, and basically set it up again to be a replacement nearly identical to the original... how is that any different / more secure than just using a "reset account" feature that resets the original account (removes 2FA)?

      We're still back to the recurring original problem with account security where the security of your account comes down to the security of your linked e-mail account.

    1. Unique Passwords and U2F are not perfect, but they are good. Unique Passwords reduce the impact of phishing, but can’t eliminate it. U2F doesn’t prevent malware, but does prevent phishing.
    1. Most platforms that require OTP verification for ensuring security are targeted at the mobile phone only. But some payment gaterways send OTP to email address also simultaneously to doubly ensure that you get the OTP and that you have requested the OTP. There could be some delay in SMS or email reaching you. Many OTPs are time restricted - you have to use them quickly.
  8. Jan 2023
  9. Oct 2022
  10. Aug 2022
    1. We want to use the Doorkeeper gem to implement an OAuth provider in our app. However, we use 2 factor auth in the login process, so we need a way to modify the password grant to accept email, password and a 2fa token (and respond with an appropriate error if the 2fa token is required and missing).
    1. You are not currently logged in. This can be for a number of reasons: The system is temporarily unavailable You haven't logged into the system yet The Username or Password provided is not valid You may not have the required access level You didn't do anything for 30 minutes

      unusual to explain why "You are not currently logged in" -- esp. when you first land on a page and of course haven't even signed in yet.

      Would be more common to explain how you got signed out (assuming you were at one time signed in).

  11. Jul 2022
    1. it should be normal for production apps to add authentication and authorization to their ActiveStorage controllers. Unfortunately, there are 2 possible ways to achieve it currently: Not drawing ActiveStorage routes and do everything by yourself Override/monkey patch ActiveStorage controllers None of them is ideal because in the end you can't benefit from Rails upgrades (bug fixes, etc) so the intention of this PR is to let people define a parent controller (inspired by Devise, maybe @carlosantoniodasilva can tell us his experience on this feature) so that people can add authentication and authorization in a single place and still benefit from the default controllers.
  12. Jun 2022
    1. Users often forget to save their recovery codes when enabling 2FA. If you added an SSH key to your GitLab account, you can generate a new set of recovery codes with SSH:
  13. Apr 2022
  14. Feb 2022
  15. Jan 2022
    1. export const load: Load = async ({ page, session }) => { if (!isPublic(page.path) && !isAuthenticated(session)) { console.log('Unauthorized access to private page'); return { redirect: '/', status: 302 }; } else { console.log('Auth OK'); } return {}; };
    2. That whole setup works. If the user logs out, I can just write an empty JWT cookie and clear the $session.jwt value, redirect back to the home page, done.
    1. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.

      Meaning that 99% of the people use it are using it "wrong" because they're not using it for HTTP authentication and don't send a WWW-Authenticate header field with their 401 response?

      Hmm. That's a tough one. On the one hand, the spec does say they must send it.

      Initial opinion

      But on the other hand, one could argue that that requirement only applies if using 401 for HTTP authentication. And that saying it's wrong to do so (as they claim at https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses/14713094#14713094 and https://hyp.is/JA45zHotEeybDdM_In4frQ/stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses) is having a too strict/narrow/literal interpretation.

      HTTP is meant to be used widely in many very different uses and contexts, most of which do not use this very specific HTTP authentication scheme; my opinion is that they shouldn't be denied from using it, just because they don't have anything useful WWW-Authenticate header field. (Or (which is also fine with me), just put something "emptyish" in the field, like "Unused". Unless that would trigger a Basic auth modal in the browser, in which case we shouldn't, for practical reasons.)

      Why shouldn't we be able to repurpose this same status code for uses that are still authentication, but just not HTTP authentication per se?

      Is it really wrong to repurpose this useful status code for other contexts, like cookie-based app-defined authentication systems?

      I say that it's okay to repurpose/reuse 401 for any authentication system (that uses HTTP as a part of it, even though not using HTTP's own authentication system), as long as we try to maintain the same semantic as originally intended/described here. I think it's okay to use 401 as a response to a XHR request, and then have the client redirect to a login page, which provides a way to authenticate again (reattempt the authentication challenge), analogous to how it works for HTTP authentication.

      Revised opinion

      https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses/14713094#14713094 has made me change my mind and convinced me that...

      Authentication by schemes outside of (not defined by) RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication should not use HTTP status 401, because 401 Unauthorized is only defined (by current RFCs) by RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication, and has semantics and requirements (such as the requirement that "A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge.") that simply don't make sense or cannot be fulfilled if using a non-HTTP authentication scheme.

      403 Forbidden, on the other hand, is defined by the broader HTTP standard, in RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content and RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication.

      In conclusion, if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used.

      Couldn't a custom auth system use WWW-Authenticate header?

      The question was asked:

      Doesn't RFC7235 provide for "roll-your-own" or alternate auth challenges? Why can't my app's login flow present its challenge in the form of a WWW-Authenticate header? Even if a browser doesn't support it, my React app can...

      And I would say sure, if you want (and if the browser doesn't automatically show a Basic auth modal in this case and thwart your plans).

      They might be on to something here with that question!

      But that should probably be the test of whether you can/should use 401: are you actually using WWW-Authenticate header?

      Indeed I found an example where it is used for OAuth2.

    1. That comes in the form of the WWW-Authenticate header with the specific authentication scheme to use. For example, in the case of OAuth2, the response should look like the following:
    1. Authentication by schemes outside of RFC2617 is not supported in HTTP status codes and are not considered when deciding whether to use 401 or 403.

      What does "are not considered when deciding whether to use 401 or 403" mean exactly? What exactly should not be considered, and what exactly should be considered instead? In other words, how did someone arrive at the conclusion that "if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used."? Why is 403 okay to use for non-HTTP authentication, but not 401?

      Oh, I think I understand the difference now.

      They should have said:

      Authentication by schemes outside of (not defined by) RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication should not use HTTP status 401, because 401 Unauthorized is only defined (by current RFCs) by RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication, and has semantics and requirements (such as the requirement that "A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge.") that simply don't make sense or cannot be fulfilled if using a non-HTTP authentication scheme.

      403 Forbidden, on the other hand, is defined by the broader HTTP standard, in RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content and RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication.

      In conclusion, if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used.

      See also my comments in https://hyp.is/p1iCnnowEeyUPl9PxO8BuQ/www.rfc-editor.org/rfc/rfc7235

    2. Meaning if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used.
    3. If HTTP authentication is not in use and the service has a cookie-based authentication scheme as is the norm nowadays, then a 403 or a 404 should be returned.
    4. While this seems to me like it's probably an accurate interpretation of the old RFC 2616, note that RFC 7231 defines the semantics of a 403 differently, and in fact explicitly states that "The client MAY repeat the request with new or different credentials."
    5. The statement is "If the request already included Authorization credentials". That means if this is a response from a request which provided the credential (e.g. the response from a RFC2617 Authentication attempt). It is essentially to allow the server to say, "Bad account/password pair, try again". In the posed question, the user is presumably authenticated but not authorized. 401 is never the appropriate response for those circumstances.
    6. 401 is only appropriate for HTTP Authentication
    7. From your use case, it appears that the user is not authenticated. I would return 401.
    8. 401 'Unauthorized' should be 401 'Unauthenticated', problem solved !
  16. Dec 2021
  17. Aug 2021
    1. without requiring a learner to log in separately on the external systems, with information about the learner and the learning context shared by the LMS with the external systems
  18. Jun 2021
    1. Authentication is the process of determining what user is making the current request, for example, accepting a username and password, or finding a User in the database from session[:current_user_id].
    2. Instead, your controller should get the current user based on the HTTP request (eg, an HTTP header or a cookie) and provide that information to the GraphQL query.
    1. Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.
    1. I went for session cookies in a very lazy time-pressured "aha" moment some years ago. It's been working in production for 3-4 years on a well used site without issue. It wouldn't be appropriate for a back-end API like a payment gateway where there's no user with a browser to send to a log-in screen, but for normal web pages, and especially carving js apps out of / on top of an existing site, it's extending what we have instead of starting again.
  19. Feb 2021
  20. Dec 2020
    1. This is the accepted way to handle problems related to authentication, because user data has a couple of important characteristics: You really don't want to accidentally leak it between two sessions on the same server, and generating the store on a per-request basis makes that very unlikely It's often used in lots of different places in your app, so a global store makes sense.
  21. Oct 2020
    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.
    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.
  22. 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.
  23. 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.
  24. Jun 2020
  25. 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.
  26. 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.
  27. 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).
  28. 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.
  29. 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?

  30. Apr 2019
  31. Nov 2018
  32. 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.

  33. Apr 2017
  34. Feb 2017
  35. Oct 2016
  36. 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.
  37. 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.