Tag Info

Hot answers tagged

38

You shouldn't really be worrying about this, the certificate contains only your public key, which is supposed to be public anyway. The only issue is the privacy concern of giving away the information in your certificate to any site that asks for it. Summary of the issue: The BBC weather page has a request to http://www.live.bbc.co.uk. HTTPS Everywhere is ...


20

Update: PasswordBox responded to my inquiry on the subject. Personally, I couldn't really figure out what they're talking about. It could be a problem in my understanding. Below is a screenshot of their reply This is a very interesting question. PasswordBox seem claim that they can never have access to your passwords. According to their FAQ page: ...


10

Notice the phrase "This master password is NOT stored on our servers, so your secure data can't be retrieved by anyone but you." Actually, one does not necessarily mean the other, depending on the details. Consider the following system: A symmetric key is generated on the client software by hashing your master password, hopefully with something reasonably ...


7

In short: Just go to startssl.com and get your SSL certificate for free. The protocol is not specific enough. If you aim to implement this yourself, you will likely introduce flaws in the signing and encryption steps. How are users going to validate the server's public key here? Do you expect them to compare hex-digits? You also seem to assume that clients ...


7

The flow provided is remarkably lacking in technical detail. It provides the personnel process, but not the technical one. Hard to say, seeing it, what it means. My original thought reading the FAQ was that the password is something a human can remember, but the "master password" is an inscruitable number built from the password and a process of salting ...


7

I wouldn't bother to be honest. Most application store their database passwords in plain text, i don't see this as being very different. If you are on a shared host, make sure only your user account has read access to the file. I also strongly recommend using SFTP or FTPS, if you aren't using one of these protocols then you are begging to be hacked.


6

Note that there might a difference between the password and the encryption key! The first statements says that there is no way that they would be able to decrypt your stuff without having your password. Considering the second statement, I believe that they are probably encrypting either an encryption key or all your files (duplicate) with their own ...


6

In a fight between a polar bear and a white shark, who will win ? Guess what, if this is a pool fight, the shark will munch through the bear in less than two minutes (this site makes unsubstantiated claims to the contrary, but there are strong clues that a shark eating a polar bear really happened). Now put them both on a land, and I will put my money on the ...


5

Your method is trivially vulnerable to a Man in the Middle (MitM) attack. There are two benefits of using SSL: Sensitive traffic over the wire is sent encrypted (which your method effectively accomplishes) and you can cryptographically verify that you are going to the right website and not a fake version of the website. (Again note the URL in the ...


5

The server will provide its own certificate, and optionally (but recommended) all intermediate CA certs in the chain (aka the CA bundle). It need not provide the root CA cert of the chain, and the client should disregard that cert if provided in the bundle anyway, see this question for more details on that. Since the complete bundle is quite possibly ...


5

nsCertType is an old Netscape-specific extension, which was used by the Netscape browser at a time when that browser was still alive. You can forget it nowadays. The signing CA, by principle, acts in any way as it sees fit. It can put whatever it wishes in your certificate. Your certificate request is just a suggestion. You can more or less count on the CA ...


4

The client is a network concept: the data is transported between two machines, the server and the client. The client is the one who initiates the conversation; the server is the one who is sitting all day, waiting for clients to connect. The user is the biological entity (presumed human) who controls the client. Authentication is about the server making ...


4

I lean towards "naah, don't bother", though I don't think there's a single clearcut answer. In principle it depends upon what data and resources those passwords grant access to, as well as how tightly secured the machine where you'll be storing them is. If the passwords will be stored on a machine that is reasonably well-secured, and if the data they grant ...


3

First off, let's be clear: the client certificates are not self-signed. They are signed by a CA, and that CA's certificate is self-signed. This is important, because a self-signed certificate cannot be revoked at all, by definition: revocation is an information coming from the issuing CA; a self-signed certificate is its own CA. A second important point is ...


3

Yes, production servers should present little information outside their designed purpose to the outside world. Display of any kind of debug or trace information (intentional or accidental) could clue hackers/attackers into where to pinpoint an attack, a particular form box that maybe vulnerable and at the very least make finding a weakness in your site less ...


3

Leaving aside the HUGE issue of FTP security, and looking at the problem of storing passwords, if you need to decrypt the password (as oposed to simply verifying it against a stored, hashed value) then you quickly run into the problem that someone who can gain access to the data can probably also gain access to the key used to encrypt the password. About the ...


3

If the server requests the certificate during the initial handshake, simply use Wireshark and look for the Certificate Request TLS message (just before Server Hello Done). If you look into the details of this package, you should see a certificate_authorities list giving you the list of acceptable CAs. Your local chain will need to match one of these. If ...


2

There's little benefit to reversible encryption if you have a program automatically decrypting it. If some idiot has read access to the script they probably also can execute it and figure out how to decrypt the password. Sure it may prevent "kid-sister" type attacks, but not prevent any challenge to your average attacker. Personally, I'd opt for plaintext ...


2

I seem to be unable to comment so instead an answer, with a simple method how that can be achieved: The long and incredibly hard master password is generated. The software additionally creates a completely random (long) symmetric key. Let's call this symmetric key the DeathKey (basically a long random byte chunk). The software uses the DeathKey to encrypt ...


2

You have two potential attacks: The attacker poses as a fake server, and talks to the genuine client, feeding him a wrong certificate or other nefarious data. The attacker poses as a fake client, and talks to the genuine server, obtaining a valid certificate with the genuine client's name but the attacker's key in it. A man-in-the-middle attack is when ...


2

In C system() function executes an internal operating system command. If the command execution is terminated the command processor will give the control back to the program that has called the system command. It takes a C String as a parameter.as an example int main () { char c[50]; strcpy( c, "command string" ); system(c); return 0; } You can see the ...


2

If you want to have your program call another executable, than it would be required to be installed on the system (it's open source so in most cases you should be able to ship or incorporate somehow). OpenSSL also provides some libraries for programmers, see the C Header files documentation. Here are some tutorials about progamming with OpenSSL: Windows ...


2

From the point of view of the server, all that can be seen is the client certificate (a public object, which is basically a bunch of bytes that everybody knows) and also a signature from the client (the signature is computed during the SSL handshake). The signature, being verified, offers some guarantee to the server that whoever is talking to it also knows ...


2

The FTP password is for authentication on the target FTP servers: the password unlocks access to the storage service of these servers. To a large extent, this is their problem, not yours. To be more detailed, whenever you send a data file to a server, the overall confidentiality and integrity of the data is partly the responsibility of the server's ...


2

Now I find that I must add another answer, at another level. You are trying to use certificates for authorization. Don't. It does not work well in the long term. Certificates are for authentication. A certificate tells you: this guy owns that public key. Revocation is a way to cancel that, and is meant to be used when the key ownership is no longer ...


2

A simple Google search on "django client certificate" reveals this, and this, and this, which all answer to your question as: yes, Django can work with certificate-based client authentication. People don't do that often in practice, because client certificates work only if you can arrange for clients to have certificates, basically meaning that you must ...


2

If an attacker replays old handshake messages, the trickery will become apparent with the Finished message from the attacker, because the message previously recorded was encrypted and MACed with distinct keys, and its contents won't match either: The derivation from the master secret (resulting from the key exchange mechanism, e.g. RSA) into symmetric ...


2

Technically your certificate is not for you. You have a certificate so you can show it to other people; it is meant to convince them, not you. You don't necessarily trust your own certificate. As a safeguard against bugs, you may want to check that the public key in the certificate matches your private key: if the CA fumbled (badly) and sent you the wrong ...


2

It sounds like you want public-key cryptography similar to what SSH supports. The basic idea is that the user provides their public key to the server during the account creation process, then proves their ownership of the corresponding private key during the login process. The public key, as the name implies, isn't even remotely secret, so it meets ...


2

Use certificates. That way the client never shares it's private key with anyone including the server. The server just has the clients public key which isn't secret. Alternatively run a federated identity solution or leverage one such as Google or Facebook's. There are open source options for this (such as http://en.m.wikipedia.org/wiki/OpenAM ) You also ...



Only top voted, non community-wiki answers of a minimum length are eligible