I recently started getting notifications about the GitHub deprecation of basic authentication using a password to Git - see their blog post https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/.
In this post, they say the following:
For developers, if you are using a password to authenticate Git operations with GitHub.com today, you must begin using a personal access token over HTTPS (recommended) or SSH key by August 13, 2021, to avoid disruption.
A short while ago, I started using SSH keys on some of the machines I use anyway to avoid entering my password regularly or storing it unencrypted with credential helper. However, as per above, they say personal access tokens are "recommended".
What I would like to know is what are the key differences between each of these methods? This is to get some insight into why tokens are "recommended" and whether it is worth switching to this method of authentication.
From the blog post you linked, I can see at least one benefit of tokens over SSH keys: while tokens and SSH keys both share the Unique, Revocable, and Random benefits quoted in the blog post below, tokens are also Limited in comparison to SSH keys in that they come with their own scoped permissions baked in:
While SSH keys can be read-only or read-write enabled, or scoped to specific repositories, personal access tokens do have an edge in terms of their finer-grained permissions model in comparison. This is likely why GitHub recommends tokens over SSH keys.
Tokens offer a number of security benefits over password-based
authentication:
Unique – tokens are specific to GitHub and can be generated per use or
per device
Revocable – tokens can can be individually revoked at any
time without needing to update unaffected credentials
Limited – tokens
can be narrowly scoped to allow only the access necessary for the use
case
Random – tokens are not subject to the types of dictionary or
brute force attempts that simpler passwords that you need to remember
or enter regularly might be
Related
I understand JWT can be used to authenticate a user but not much info seems to available on how you can secure the connection between frontend and backend api to ensure the website is not a fake duplicated used to lure users and steal their creds.
Maybe I'm just not wording my searches properly or understanding the topic, but how would you ensure that the client trying to connect to your API backend is authorized to and denied if it's not, even if the correct creds are used? This is for JWT.
I know it can be secured using API keys but this question is specific to JWT.
There isn't a great deal you can do against social engineering attacks. If data is sensitive then giving users regular warnings about how people might try to trick them with fake websites is fairly common.
Wikipedia lists a number of techniques that can be used to customise the UI to make it easier for the user to recognise that they are on the right site.
2 factor authentication can also help. While incorrect credentials could result in a token being passed to the attacker (allowing them access to the site), it will expire after whatever time limit you put on it and they will need to refresh it or be unable to reuse the password (since they won't have the new 2FA code).
You can also monitor for logins from large numbers of different users from the same IP address.
This question already has an answer here:
Automatic Login from one web site to Moodle web site?
(1 answer)
Closed last year.
I have an user details stored in my web site database and Moodle database. I logged my website with that credentials , Moodle also auto login with that credentials is there any way? Or any Code is available?
If you're handling credentials correctly (and Moodle does), you DO NOT STORE THE ACTUAL PASSWORD! Instead, you store a salted hash of the password.
When someone tries to log in, you salt and hash the attempted password using the same salt and hashing algorithm. This will give you the same result as the value in the database, and so instead of comparing passwords directly you now compare hash values. In this way your users are protected from having their passwords leaked if someone breaches your application.
If you're not doing it this way on your own site, you're doing it WRONG and need to fix it ASAP. This is big deal!
Here's the thing: the two web sites aren't necessarily using the same hashing algorithm, and certainly aren't using the same salt. Therefore the user credentials you have saved for your web site are NOT the same credentials saved in Moodle, even if all the users have the same password.
But what you're really asking about is SSO (single-sign-on). There are (safer!) ways to support this. SAML, CAS, Shibboleth, and OAuth come to mind, and Moodle definitely supports these. You can also have Shared (as opposed to Single) Sign-On, where both your app and Moodle use a third party such as AD or LDAP for identity verification, so the username/password credentials are the same but you still have to sign into both applications separately.
Unfortunately, you will need to build this into your own app, as well, and perhaps even add an additional authentication portal server to your organization to act as the trusted intermediary between each of these applications. There are a number or products you can use, including some that are open source or may already be included with other licensing, so you don't have to start from scratch or necessarily make an expensive purchase here.
The good news here is these products generally also put you into a good position to start supporting Multi-Factor Authentication, which is also an important feature to provide.
If I enable SSH authentication for an Azure DevOps organization, will that enforce (only allow) SSH key pairs to be used for Git authentication requests, explicitly? Or will existent OAuth tokens still work as-intended after enabling SSH keys? In my scenario, currently, SSH authentication is disabled and Third-party application access via OAuth is enabled going into this question. Thanks for your time. ( Options found under: Azure DevOps > Organization Settings (bottom left) > Policies (left middle) )
I am assuming enabling both allows for either to be used, but want to confirm before potentially blocking developers from being able to push code.
I would like all developer workstations to use SSH key authentication instead of OAuth, and don't want to put a wrench in their system in the meantime. Also I much prefer using private key authentication simply because of the inherent security benefits of using asymmetric cryptography.
It's safe to enable. We have it enabled in our organization, and almost none of us actually have added SSH keys. We're pretty much exclusively OAuth.
By default, your organization allows access for all authentication methods(OAuth, SSH authentication, PATs). You can limit access, but you must specifically restrict access for each method. When you deny access to an authentication method, no application can access your organization. Any app that previously had access gets an authentication error and has no access to your organization.
So enabling SSH authentication will not affect OAuth authentication.
Here is the official document you can refer to.
Suppose I have a simple node backend application which when ran needs to connect to a specific GSuite instance, query some things (users, groups, etc.) and then close and not run again until needed, which can mean either a very long time or a few seconds. From what I gathered from Google's documentation there may be multiple ways of doing this, including having an OAuth client and follow the whole flow in setting it up, managing token lifecycle, etc.
However I do NOT want to go with this option for now for various reasons and I am wondering if there is any way of getting access by means of an API Key / secret, like many other 3rd party services allow nowadays. Simply put I would like to generate a key pair somewhere on GSuite, no idea where, and use those keys for auth instead of OAuth, something Google suggests is possible, both on the GSuite Admin app (with a broken link that leads nowhere - not surprising) and on GCloud API and Credentials subpage where you setup credentials (however there it says that API Keys can only be used for very limited resources, none of them having anything to do with GSuite).
I think your best option is to see if what you want to do can be done by a service account. You can create a service account, grant administrator privileges to it in GSuite, enable some APIs, and then that account can do a lot of things without using OAuth directly. The credentials for the service account can then be provided to your application as a json key file, which it can use to authenticate to GSuite. You can also grant service accounts permissions to specific objects like files in Drive, but it doesn't sound like that would be sufficient to your needs.
A guide that may be helpful in the details of how to do this is https://m.fin.com/2017/10/04/navigating-the-google-suite-directory-api/
So this question is delving into security and encryption and the problem potentially hasn't been encountered by many. Answers may be theoretical. Let me outline the scenario...
A website frontend is driven via a backend API. The backend has an endpoint handling a generic registration form with username and password. It's using SSL.
The backend API handles registration via an async job queue. The queue does not return responses to the API server. It's a set and forget operation to queue up the registration.
Queued jobs are picked up by workers. The workers take care of creating the user account. These workers need access to the plaintext user password so that they can trigger a third-party API registration call with the password.
So the real crux of the problem is the syncing of the password to the third party API while not revealing it to prying eyes. The queue poses the problem of not having direct access to the plaintext password from global POST data anymore, meaning it needs to be stored in some fashion in the queue.
The queue can easily store the hashed password and copy it directly to the users table. This solution does not allow for syncing of the password with the third party API, however, as it's already encrypted. I toyed with two-way encryption, but am whole-heartedly concerned with leaving the password prone to decryption by an attacker.
Can anybody think of a secure way to handle this scenario of password syncing?
The queue is a requirement and it's assumed that this is readable by anyone with access to the server. The passwords don't necessarily have to be synced; the password for the third-party API could be a derivation of the original so long as there's a secure means to decrypt via the logged in user without supplying their password. This is essentially to simulate Single Sign-On with a third party API that does not support SSO.
There are a few ways to sync passwords:
Both auth stores use reversible encryption so that each system can extract the real values to send to the other system;
Both use the exact same encryption so that you send the encrypted text through and therefore can be understood by both.
One system is the "master" in which the users always authenticate through and the "slave" systems simply receive acknowledgement that the user has logged in. This can take the form of machine generated passwords created by the master for use in account creation on the slaves.
One system is the "master" that all other systems make calls into for account validation. Similar to using LDAP or MyOpenID.
There are certainly issues you can run into with a multi-master password sync'ing such as ensuring password changes are properly replicated when a user changes their password.
In your case, it sounds like the user never directly interfaces with the 3rd party API. If that's accurate, have the users authenticate against your system. Generate the 3rd party API password when needed, store it with their account and auto log them into the other system as necessary. Your primary password can be stored in irreversible encryption; however the 3rd party one would have to use reversible encryption. The Queue would never have to have the initial password and instead would simply generate a new one and store it with the local account.