I tried pushing onto a git repo on my server, so I thought I did something like this
git remote add games#games.com
When I should have done
git remote add games#gamesThatAreFunEtc.com
Anyway I thought it was weird that it asked for my password but not realizing what was happening I gave it. I think the site also got my private key as it probably tried to use my key in ~/.ssh first.
Should I now change my password and/or rsa key? Does doing something like that log an incorrect password attempt with the incorrect pass or the rsa key? Should I worry that if it does, the owner of the site will try to break into my site?
Also as it's not obvious from the login attempt what my site name actually is, am I fretting for nothing? Can I assume he won't try every combination of domains that start with games
First of all, it's good that you noticed your error and that you care enough to ask this question here. I'd assume most people would get back to business and not worry.
your RSA key is safe, as it is only used in a challenge-response query to verify if it matches any saved public keys, it is not transmitted to the server
you should change your password, as a malicious server could have logged it
You probably don't have to worry about the owner of the site breaking into yours. Usually ssh-server do not log passwords. I would change my password anyway, just to be safe.
In the future, try to heed the warnings ssh gives you (in your case probably a missing known_hosts entry) and take them seriously instead of mindlessly pressing 'yes'.
EDIT: As pointed out, since you entered your password when connecting to the unknown site, change it.
As to your private key, its fine as long as it doesn't share the same password - at most the remote site would have got a sniff of your public key only, your intended username, and ip your were using. The likelihood that someone at that address is actively monitoring the single 'failed connection' log line, or doing anything insidious is very, very, very small.
If you need more encouragement, and want more information about how such transactions typically go down, google "diffie/hellman key exchange".
Related
We're dealing with an unusual situation involving dovecot that perhaps requires an unusual solution.
We recently required all of our POP/IMAP users to change their passwords, and in almost all cases, they dutifully did so. However, one user has several devices and machines which are repeatedly querying for email, and due to circumstances beyond anyone's control, one of his computers cannot be accessed for at least another few weeks, and therefore, the dovecot password for that user's email access cannot not be changed until that time passes.
Therefore, that computer keeps querying dovecot for email for that user with the old, now invalid password, and those queries fail.
Furthermore, due to various circumstances which are also beyond our control for the time being, we can't have that one user change his password back to the old value on the other machines and devices that he uses.
What we're wondering is whether there is some way that dovecot could be set up to recognize and accept both passwords for this one, specific user. In other words, can we somehow set up a secondary password for this email address so that both the old and the new password will allow this user to access his email?
We are using auth sql by including auth-sql.conf.ext in 10-auth.conf. Perhaps the solution to this problem would to restructure the database we are using for SQL authentication and add one or more columns, and then somehow change the SELECT statement that is used in auth-sql.conf.ext to choose between one of two passwords.
We are willing to attempt this procedure if it's the only option available, but we aren't even sure how it can be done. And in any case, we're hoping that there might be some feature of dovecot that we are unfamilar with which would allow us to set up this one user's dovecot email account to allow two different passwords for authentication without any database changes.
Is there any chance that we could do this?
Thank you in advance.
The link supplied by Allan Wind helped me (thank you!), as well as a couple other things I saw in those dovecot docs which I had overlooked in the past.
It turns out that I can supply a second userdb and passdb block in auth-sql.conf.ext, and they serve as secondary fallbacks if the primary SQL query doesn't return a match. I set up a passwd-file that is usable by both of these which contains the hash of the user's old password, and now, both passwords are working.
For example, the secondary userdb block (which should appear right below the original sql-based userdb block) looks like this:
# Fallback ...
userdb {
driver = passwd-file
args = scheme=md5-crypt username_format=%u /etc/dovecot/extra.userdb
}
The secondary passdb block is identical, except for it being named passdb instead of userdb. It must appear right after the original passdb statement in that same file.
So, all's well that ends well.
Onward!
I am implementing forgot password feature for my website, and while looking at other websites for best practices, I found that gmail enforces this, no other site I looked at enforced this constraint.
There is a lot of rather out-dated ideas about passwords and password security.
If a user has a password compromised -- and then however many days later they change it -- the attacker is now blocked from the system.
Should that user ever go back and re-use his old password, then the hacker might decide to retry that account/password and regain entry into the system.
Of course, it opens up a whole new set of problems. Make it so a user can't remember his password and they will start writing them on sticky notes taped to their monitor.
Personally? On all the sites I've worked on, I've never thought it important to add password expiration /or/ limits on what passwords may be (re)-used.
I would have thought it provides little to no added security. You are trusting the user to not lose their password but I guess it can go both ways.
If they have to choose a new password then they may have to write it down or be more likely to forget it again however if they have a new password it is less likely that someone who knows a password they use could use it to access your website.
Either way make sure you are storing the hashed password for comparison and not plain text.
I'm developing a small app that will help users easily get information from their isp provider, by scrapping their isp account page. For that to be possible I need their username and password store in my db. To keep their password safe I will use an openssl public key to encode it in my db and a private key to decode it before my scraper logs in to their account page.
I'm wondering where to put my private key so the passwords are safe even if someone take controller of my web server? Because It would be totally inappropriate to just leave the private key on the web server...
tks
If someone takes total control of your server and is interested in those passwords, he will succeed. Always take this into consideration and make plans on what to do in this case.
Now to make it as hard as possible and improbable to achieve this, I suggest to store the key (or better, the passwords) in some kind of memory table: like a Ramdisk, a script that will give out only one password per minute and delete itself if called more than that etc.
I don't see any positive effect of using public key encryption here, the key to decrypt must be stored on the server no matter what you use. You may look for Howtos that descripe the problem of https-certificates, they should be protected by passphrases and must be read on server start - the problem is related.
Probably a good solution would be to log into the server, store the passwordfile in a ramdisk and log out. Repeat on Server reboot, crash or password change.
One of the goals of OpenID is to be resistant against the failure of any one corporation. This sounds good, but there is another problem: if the site your ID is hosted on goes down, so does your ID. I thought that there must be a login system that would be totally resistant to failure.
My idea is like this: I go to a website and I have to login. I give them my public key. The website sends me back some random data. I sign this data with my private key and send it back to them. If the signature is valid, I get logged in. This has the advantage that my ID is just my public key, so I don't rely on any external site.
To make it so that users don't have to remember there keys, the system could also optionally allow an OpenID-like system where my keys are hosted on some server and the original site redirects me there to login, and that site signs the data and sends it back to the original site, and I am logged in. This method would work similar to OpenID, but would allow me to back up my keys so if that site goes down, I can use another site.
Is this a practical system? Am I just wasting my time? Should I not reinvent the wheel and just use OpenID?
Identity cards, like Windows Cardspace, are a good alternative because they are stored on your computer and can be backed up. This is technically called the Identity Metasystem or Identity Cards.
This is different from a centralized identity service like OpenID. The good thing about the OpenID system is that the chance of everyone's identity server of going down is pretty small. However, individually, each user can possibly experience an outage.
The InfoCard system by Microsoft is a good solution, although it has not been very popular.
This is not a new problem-- email signing and encryption is a similar solution to private/public key system. GPG actually does have keystores where you can post your public keys so that people can verify your signatures.
If you're really wanting to avoid any possibility of an identity server being down(a pretty strict requirement), use CardSpace, or some other private/public key system where the users themselves have the keys, and only have to demonstrate that they have them by some challenge-response hashing algorithm.
Also, the cardspace solution is not strictly a Microsoft thing, there are plenty of applications for all operating systems. I believe it is a public standard.
This is very similar to how HTTPS works.
With your idea, you need to take good care of your private key. What if your comnputer crashes, etc. Also what about logging in from someone eleses computer? Would you trust putting a thumb drive with your private key on it into someone elses computer?
This is also very similar to what the military does with ID cards with private keys embeded on a chip that they issue to service members. A member needs to put his ID into a special reader as well as logon with a unique ID and password that must be changed periodically. This is to take care of the case where a member looses his ID and someone else trys to use it.
So I guess my answer is yes, you have a good idea, but perhaps you just need to refine it some more.
Use OpenID. It's so easy to set up and you don't have to debug it.
Windows CardSpace supports something like this. But it hasn't really taken off.
The problem with your system is that if you lose your key due to hardware problems or a system crash, you lose your only way to get to the sites you use that key for.
I would say OpenID is sufficient.
I see a couple issues with your system
I need to have that key to login. If I go out, and don't have the file on my person or hosted remotely, I'm out of luck. I also may not be able to enter it on my cell phone or some other device.
You will also need to protect the key from loss. Which likely means password protecting the key, which takes away alot of the convenience of the system.
What needs to happen for OpenID to be more resistant to ID provider failure, is for sites to allow multiple OpenIDs to be associated with an account, just like SO does. So, your idea may end being workable, but I think the effort to get it working and adopted would be much greater than the work to get widespread adoption of sites allowing multiple OpenIDs.
Also, check this link for a description of TLS Client Authentication
Right now I'm building a personal site/blog and have pretty much got it they way I want except I'm in two minds about how to add posts to it.
It's just me who'll be adding posts and to me having a user / name password to log in seems rather passé ;).
I'm looking in to alternatives to play around and experiment with and one idea I have is this:
Generate an asymmetric key, I personally keep the private and the site has the public key. When I try to add a post or modify any content the site will generate a random string, encrypt it with the public key and display it. I decrypt this using a little app I could whip together and pass the unencrypted string back to the site which will allow the modification to continue.
I'm just wondering about any caveats I should be on the look out for, or if anyone thinks this is a bad idea, perhaps an alternative I could try?
Why not just have a user name and password and either have your web browser remember the login, or send an authentication cookie back that doesn't expire. Use a self signed SSL cert to secure the communications channel. If you want to use public/private key crypto just setup an SSH tunnel and post from localhost on your server. Trust me, it's better to re-use known good crypto/security than to try to roll your own.
Why not go one stage further from your suggestion and put the encrypted string in to the URL?
For example, turn the current date and time into a string - eg. 0904240905 - encrypt it with your private key and add this to a URL, e.g. http://yoursite.com/admin/dksjfh4d392s where dksjfh4d392s is the encrypted string. You site then has a servlet which extracts the encrypted string from the URL, verifies that it decrypts to a recent time and then gives you a session cookie while allows you to perform admin tasks.
I think the asymmetric key is an elegant solution - but a username/password is almost certainly going to be easier to implement.
If you're building your own site then you are just doing it for kicks (otherwise you'd be using WordPress, Drupal, Django, etc.) so why not do things differently?
You might find that having to carry around your keymat app might get a little restrictive, if you find yourself wanting to blog but without the means to identify yourself.
But, that said, #Kurt has the right idea for crypto - DIY is almost certainly going to be worse than using something already tried and tested.
One of the wisest statements I ever heard about security was "don't try and re-invent it".
Online security has been through so many iterations that it's highly likely that any bright idea you come up with has some flaw that has previously been found, considered and fixed.
If you want "casual" security, secure your site with a user name and password. If you want "strong" security, stick an SSL certificate on top of it. If you want "bank" security, add in anti-keystroke security.
SSL client certificates do this anyway. Why not just use one of those?
The main reason more people don't use SSL client certificates is that they're an administrative nightmare - you have to get end-users to create keys, then sign their certificates, then make sure the end-users don't lose their keys (when they lose their laptop, upgrade to a new OS etc), which they usually do, so you have to sign YET MORE certificates when the end-users lose their private keys.