Tag Info

Hot answers tagged

32

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 ...


19

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

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

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 ...


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 ...


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 ...


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 ...


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 ...


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

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

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 ...


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 ...


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

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

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

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

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

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 ...


1

beside joshuas explanations there are also performance - reasons to have debugging off on prod-systems, because all the debugging infos have to be written and stored, an turning debugging on increases pressure on your storage/filesystem. talking of webservers, if you write ~ 1 GB usual access.log each day you'll easily write 3-10 GB when turning on ...


1

Let C be the attacker. C runs another server, under its own name (C), with its own public key Kc. Occasionally, A connects to C (knowingly, but not knowing that C is Evil, or believing that the evilness of C won't extend beyond C itself). Attack goes thus: Client A connects to C and sends {Kac}Kc to C. Immediately, C connects to server B and claims to be ...


1

There's a couple of potential risks which spring to mind. Firstly if there's a vulnerability in the client software (e.g. a buffer overflow) by connecting to a malicious server it could be possible for the server to compromise the client machine via the VNC protocol. Secondly, there's the obvious risk that the client machine is visible to the server (i.e. ...


1

In SSL there are two areas where SHA-1 or SHA-256 may be used: in the specific entrails of the protocol itself, for the internal "PRF" (a function used during the handshake) and for protecting the integrity of subsequent data exchanges; as part of the signature over the server's certificate, and its CA certificate, and so on. SSL 3.0, TLS 1.0 and TLS 1.1 ...


1

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 ...


1

It sounds like you're trying to tie a piece of software or an identity to a single physical computer. This can't be done. In some circumstances some solutions will work some of the time, assuming no one tries to circumvent them. But in the general sense, this is an impossible problem. One solution as hinted by Thomas is to use a cryptographic hardware token ...


1

Use HTTPS as Tom Leek suggested in his answer. Additionally, request a password from the user and send them back an encrypted PKCS-12 formatted file that is encrypted using the password that you got from the user. The PKCS-12 file will contain the user's certificate and private key. Optionally, you can also sign the PKCS-12 file using your server's ...



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