I am using forgot password to change my GitHub password, but it's required 2FA credentials and I lost the 2FA app as well. So is there any I can change my password without using 2FA credentials?
A list of possibilities is given in this help page on GitHub.
To summarize, you can recover your account on your own, even after losing your 2FA app, if you (already) have:
A recovery code: you can download and safely keep a list of backup codes for situations like this.
A fallback number: a second phone number associated with your account.
A security key: you can have, for example, a physical USB stick as a security key.
Without this, there are two more methods provided, but will take longer and are not guaranteed to recover your account:
Using a verified device, SSH token, or personal access token: you can apply for account recovery by proving that you are logging in from a device you have used before, or using a SSH or personal access token that has been used before. The request will be then manually considered by GitHub support.
Using an account recovery token on Facebook (if you have set it previously): This also requires manual verification.
In general, to avoid such issues in the future, it would be advisable to download (and perhaps print a physical copy) of recovery codes for each service you use 2FA with, as that would be one of the easiest and fastest ways to recover your account.
Related
Github refused to clone a private repo:
$ git clone https://github.com/jamesbond/secretmission
Cloning into 'secretmission'...
Username for 'https://github.com': kilojoules
Password for 'https://kilojoules#github.com':
remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
fatal: Authentication failed for 'https://github.com/jamesbond/secretmission/'
In my opinion, the blog they post to is not clear about what I can do here. I am trying to add a security key to see if that helps. When I try to enter a security key on firefox on my mac, I see this: github.com wants to register an account with one of your security keys. You can connect and authorize one now, or cancel. I have no calls actions available I am aware of past this point.
I'm out of my element. How do I connect and authorize a security key? When I use the firefox plugin, it asked for the issuer and secret, of which I have neither. Can I use an ethereum wallet as an authentication?
To push to GitHub, you don't need to set up a security key. A security key is a special device that plugs into the USB port, such as a YubiKey, and typically acts as a second factor.
In your case, to push, you need to use a personal access token. While Git asks you generally for a username and password, GitHub doesn't permit the use of your actual login password here. You must go to the token page and create a personal access token that has at least the repo scope. Then, when you're prompted for your password, paste the token in instead of entering your password (note that nothing will be echoed to the screen, including asterisks).
GitHub requires this for several reasons. First, passwords are generally of poor quality, whereas GitHub's tokens contain at least 128 bits of entropy and are effectively unguessable. Second, tokens can be restricted to have access to only some repositories or some functionalities, whereas having your password allows the attacker to log in and do anything. Third, tokens can be rotated or deleted if they're compromised, which is much easier than forcing the user to change their password. And finally, tokens typically have a special fixed form that makes it obvious when they're leaked, so if a token is leaked, it can be automatically revoked.
In case of using password-backed authentication, if user forgets the password, the provider always trusts the user's email security.
So why the whole fuss? Why not use email for sending the secret login keys to registered users? Isn't that what sites do when user forgets the password?
What is the reason for still using passwords for authentication?
What are the major problems with passwordless auth that passworded auth lacks?
One difference is if you log on via forgotten password, you usually have to change the password to something else, so it cannot be undetected - an attacker will likely be discovered. If it's just a login link in email, this is not the case, the attacker can log in, and likely nobody will notice. There can be controls to mitigate this of course, but it quickly becomes a UX question.
Another UX aspect is having to go to your email all the time if there is only a login link. A lot of people use password managers, which make entering very secure and unique passwords really easy. If it's a login link, you have to open your email, disrupting your flow in the application. It's arguably inconvenient.
Also a login link sent in an email will contain a token in the url. That will be remembered by the browser, logged in intermediate proxies, logged to the web server logs and so on. Secrets should not be sent in the url. However, if it's a one-time token valid for a (very) limited time, this risk is very much mitigated.
Having said all these, there are commercial applications that opted for passwordless login via an emailed link. If implemented correctly (a strong enough one-time token with enough entropy, generated with a proper crypto random generator and so on), passwordless login via an emailed link can be secure enough for many applications, and it's mostly a UX question (keeping in mind the security considerations above).
I am currently developing a RESTful API server, and I am choosing between using ID and password or using a token to authenticate a user.
Let me, explain my situation first. I need to include static authentication information to my library to communicate between a client and my server or provide it to a partnership company to communicate between their server and my server. And when I was researching other services which are in a similar situation as us, they are using token now (for example, Bugfender is using a token to specify a user).
However, what I think is that using ID and PW and using the token are the same or using ID and PW is better because there are two factors to compare it is correct or incorrect.
Is there any reason why other services are using a token?
Which one is better as a security perspective or is there a better way to do this?
I think, if you are going go use on your client fixed username/password, or some fixed token, then the level of the security is the same.
Username and password is not considered as multi-factor authentication. Multi factor means that you are authenticating someone by more than one of the factors:
What you know. This can be the combination of username and password, or some special token.
What you have. Might be some hardware that generates an additional one time password - Google authenticator app on your telephone, or SMS with OTP received with some time expiration.
What you are. This is for example your fingerprint or retina of the eye.
Where you are. This can be the IP address of the origin if it is applicable for your setup.
How you behave. What is your normal way of using the service.
etc.
Maybe not needed to mention that both - the token and the username/password combination have to be carried in an encrypted requests (I believe you are using HTTPS). Otherwise the client's identity can be stolen.
How are you going to provide the credentials to your client library? I thnk this is the most tricky part. If those credentials are saved as a configuration (or worse hard coded) on their server, is that storage secure enough? Who is going to have access to it. Can you avoid it?
What would happen if your partner company realize that the username/password is compromised? Can they change it easily themselves? Or how fast you can revoke the permissions of stolen credentials?
My advice is also to keep audit logs on your server, recording the activity of the client requests. Remember also the GDPR if you work with Europe servers, check for similar regulations in your country based on what you are going to audit log.
In case the credentials (ID and password) and the token are being transferred the same way (say: by a header in a REST request) over a TLS secured channel, the only difference lies in the entropy of the password VS entropy of the token. Since it is something for you to decide in both cases, there is no real difference from the security perspective.
NOTE: I don't count the ID as a secret, as it usually is something far easier to guess than a secret should be.
I'd go for a solution that is easier to implement and manage.
IMHO this would be HTTP basic authentication, as you usually get full support from your framework/web server with little danger of making security mistakes in authentication logic. You know, friends don't let friends write their own auth. ;)
I recently wanted to use one of my old project specific GitHub account, where the two factor authentication was enabled. Since I was not able to remember the password I used the option Forgot password and reset the password.
However after successfully changing the credentials, GitHub is as usual expecting the two way authentication key, since I was not having the same device now, I don't have the GitHub configured to get the Two way authentication, neither I have any more information about the account, rather than my login credentials.
Is there any way I could get the two - way refactor working. Or I could login?
If have the credential of the GitHub account, you can login to said account, and enable 2FA
Then you can generate a PAT (Personal Access Token) in order to use that as a password (and bypass the 2fa step when pushing in command-line).
Personal access tokens are useful when it's too cumbersome to provide a client/secret pair for a full application, such as when authenticating to GitHub from Git using HTTPS, or within a command line utility or script.
Later I reset my password , and I was't having the device which i had configured my DuO Mobile. How could I login now. It is asking for 2FA and I don't have any way to provide the key.
Then you would need to follow "Recovering your account if you lost your 2FA credentials"
Having access to your recovery codes in a secure place, or establishing a secondary mobile phone number for recovery, will get you back into your account.
I want to make a simple REST web app, where the user interact with the objects through links in an email. The links have a token that can be used to authenticate a user without a username and password, like the ones that are usually used to reset a password.
What are the best practices for such a login-less, token-based authentication system?
I am by no means a security expert.. but some of the points which come to mind are -
Lifetime - The token should expire after a set period of time. Indefinite access using the token certainly doesn't make sense.
Replay attacks - The mechanism should prevent replay attacks.. which means the token should be valid for not only a set period of time, but also fixed number of calls.. Ideally exactly 1. If this number is not exactly 1, then it opens another can of worms..
Unless, its a feature :( For example, by design, the user is expected to share link with others, and anyone with the link should be able to access the resource in question.
Authorization - Granularity of the access granted by the token. Is it black and white.. or is the token also associated with a fixed set of rights. For example - token X was issued for Read-Only access, vs token Y was issued, for same resource with R/W access.
Administration - User / Admin should be able to see and verify any currently active and issued tokens, and associated information (permissions granted / affected resource etc), and explicitly revoke them, if necessary.
Secure Communication - You should consider security of the medium through which the url with token will be sent to the user. i.e. in your scenario, do the users receive emails over secure channel (TLS / SSL)? Should the email itself be protected with DRM?
Man in the Middle / Leaks - Similarly, even though you are providing the url in email, and the user is not logging on using user name and password over SSL, the resource should still be accessed using the url with token over SSL. This will prevent any capturing of the tokens from url, by a man in the middle. You would also need to be very careful about when the users browser may use this url in places you didn't expect..
I can vaguely recall reading about a popular site being affected by their urls being used as Refer Url, when displaying ads on their website.. which means, the advertisers site would probably get the url with the token as Refer.
Generation - Choice of algorithm to generate the token - May seem pretty obvious, but the token should be extremely obscure and near impossible to guess or brute force. The tokens should never be reused and the algorithm should avoid collisions.
Server Side Security - The tokens should probably be treated with same security as you would secure users id and password. If your user database gets hacked, hackers should not get the users passwords and other sensitive information.. Similarly, if your user / resource / token database gets hacked, despite the expiration on the tokens, hackers should not be able to access the resources as users for x hours.
Point is, when the tokens are stored on server side, they should themselves be secured / encrypted.
On the same lines.. just like its bad practice to log information like passwords in log file (specially plain text), You'd also have to consider any place these urls may get logged (plain text) on your server.. For example web server logs. If only super admins should have access to user's database, then they should also be the only ones to be able to see these token.. Not your web server admin and not any hackers parsing the log file after the hack.
Auditing - If there will be a need for auditing, you'd need some mechanism in place to prove that while the user didn't log on to the system, they are indeed the ones who performed the action / operation in question. Would you want to track the ip address and other information along with the request which would help such auditing?
Consent - Do your users even consent to the use of such alternate means of authentication and authorization? Should this be an optional / opt in feature?
EDIT: I found a link to the referrer url problem I was recalling. Although it was in context of user information.
I agree to 10 points of Vikas however from security perspective I have to tell you few points that you must be careful.
I will try to keep as simple as possible. And here I simplify the technical stuff to your special case.
Firstly tokens are used to prevent Cross Site Request Forgery attacks (XSRF). Keep that in your mind. If there is a web platfrom without unique tokens on the forms then any attacker can force the user to make malicious requests.
If you simply try to authenticate the user with a token, this is pretty wrong. Because there must be no simple authentication process and you can not rely on token.
Here is how the login system works in official security documentations, im writing as I remember:
Identification: you have to identify the user firstly, that is generally done with username. YOu will know that there is a user exist in your system.
Authentication: Let's say you have already identified that user A want to login. So you mast authenticate the user A with something that you know and user A know. We call it password simply :) You cannot by pass this step with plain text methods. Passwords are generally encrypted in your db and also through all communication with secure certicates, check ssl.
Authorization: okay you made the authentication somehow, the user has a right to get Authorization. Let's say if the admin type user is logged in, he has differen rigts and if the normal user is logged in then she has regular rights.
Session control: finally you have to control the session with a secure way. Here generally in web applciations people use access tokens for all requests to be sure that the authorized user is aware of the request. As a platform owner you are responsible to secure everything until the session ends. If you don't satisfy the users with your security, then probably your platf is not going to survive longer.
Tokens have different lifetime to expire and different access rights.
Now let's look at what facebok like companies do with mobile aplications. For the mobile app they generate a unique access token which is alway alive. One shortcoming here is, if any attacker steal the mobile token generally she can do anything in the account anytime :) Anyway here our point is how they verify the users with those tokens; firstly the token is unique for that device. (Actually not exactly unique or not dependent on hardware, because if you clearly steal the necessary files from the device then you can use it on another phone). So with this unique access token which is generated with users password at their initial login on mobile app, they can login always automatically with that. And this method is a little similar to what you want to do. However pay attention that they don't authenticate the users with links or email code.
Verification is not an authentication, don't forget that. By sending e-mail you can verify the users if the emailed code is unique and valid for only 30 sec or 1 minute. I hope you got the point.
Here I suggest you to check single sign on across multiple domains, which is really interesting.
Single Sign On across multiple domains
Let's say you are logged in to google.com and then you visit the youtube.com Opps the youtube is already logged in? Yea, cool right, but exist for long time. They can authenticate users accross domains which use different cookies with a little and secure trick. You will read on the link.
If your service is not really confidential and if you want to make your users happy with easy login system. Here is two of my solutions which I love :)
1-) Ask users their email address: just directly send 4-6 digit code as e-mail. Ask user the enter/click on that. There will be no password at all, only unique code on each login.
2-) Let's say you need to verify the user with a stronger way than email. Then mobile phone :) Here trick is; you will not send the verification code to user, but they will send what you tell them to you.
Ask to user to send a SMS with a unique CODE to XXXXXX your number :) Connect your mobile operator with your web service and check whether the code is sent to you by the user :)
There is always a trade-off between security and simplicity, and also with complexity. You have to find the balance.
Don't try to make it simple if your security is going away.
Don't try to make it complex if it'll seem more secure.
Hope those informationn help you.