Tag Info

New answers tagged

0

the Java keystore contains certificate information To be more precise it contains public keys or key pairs (public and private key). The keystore is protected by a password and every private key is also protected by a password. However you are able to change or remove passwords. It's up to you. A Java keystore is like a detached keystore of a web ...


0

There are two things that you should do to solve your issue. One is look into mutual SSL. This will allow your client to authenticate your server and your server will authenticate your client avoiding repudiation. There are a few links on SE about this. Mutual SSL provides the same things as SSL, with the addition of authentication and non-repudiation ...


2

You have encountered two "hard" problems: authentication and authorization. There is plenty of information online on thes topic, but in your case I think your problem goes back to the design of the app. Let us start with two questions: How do you know whether user is allowed to post a high score? (Authorization) How do you know the connection to your ...


0

You have a few options. Honestly, you would most likely want to enable some sort of authentication, like HMAC to send the requests to make sure they are coming from your application. If you don't know about HMAC, google it, there is a lot of content. Take a look at this Security.StackExchange answer: A message authentication code (MAC) is produced from ...


1

If you are talking about the truststore, the risk isn't that someone will see or steal the certs in the truststore. The risk is that someone will add a certificate into the store which you do not want to trust. The store should be protected first protected by the OS permissions. The password is an additional protection.


0

I think it is important to have a strong password when you keep a chain of certificates in the keystore in order to perform a client-side authentication. Some servers, i.e: banking servers need client-authentication to set up a trustful connection: "proof me that you are the client that I think you are". You'll want to put these certificates in the keystore ...


0

Yes, you did keytool genkey in the file server.jks so that file contains your private key. What you need to do is, first add your cert (chain) to the JKS, THEN convert the JKS to "PFX". The p7b by itself does not contain sufficient information. The .p7b from the CA contains the cert for your server, and may contain other "chain" or "intermediate" certs ...


1

Yes, it is possible to track mouse movements with Java: http://docs.oracle.com/javase/tutorial/uiswing/events/mousemotionlistener.html Or http://stackoverflow.com/questions/18321877/tracking-mouse-movement-in-java Or http://mrbool.com/creating-a-simple-mouse-analyzer-with-java-swing/24507


0

You could consider using a cipher in CTR mode, which essentially turns it into a stream cipher. The output length should equal the input length, but you still need to come up with a unique nonce for each record. If you have a unique identifier for each record, you can use that to generate your nonce for the counter. Be careful: using the same nonce twice ...


0

Depending on what security you are trying to achieve, this might not be possible: A certain amount of output expansion is necessary to provide protection against certain attacks. Consider the case of a database that stores health records in the form of a list of illnesses that a person is affected by; also, consider that "high blood pressure" encrypts to ...


0

What is described in the question is Format Preserving Encryption. However, expect a steep learning curve, and a severe lack of ready made implementations.


3

Actually, I'd argue that it's better UX to clear the fields. Assuming the password fields are full of asterisks, the user is going to delete the whole field anyway when they retype their password. In addition, you're opening yourself up to a new security risk. There are possibilities for XSS, shoulder surfing, and also any time you send passwords anywhere ...


0

I don't think that re-entering the three passwords is a poor user experience, please prefer that and avoiding send them back! Imagine that the user left the computer and some one else do something like console.log($('#oldpassword').val()); That is bad. While you can only see dots at passwords fields, if you forget the last char, commonly you clear the ...


1

It's best to have a policy of passwords are only input, never output. This is a practical approach and a good step in the right direction for security with little cost. Any passwords output would also be visible in plain text if "view source" is clicked meaning that any shoulder surfers around could view the passwords. If it is simply asking the user to ...


0

I believe the reason it is considered insecure to send the passwords back to the client is because the client may cache the page, meaning there is a version of the password in plain text stored somewhere on the user's local drive. Hitting the back button or parsing the cache could reveal the password. This is especially bad on public machines. Also, there ...


0

Echoing input back to the client always raise cross site scripting XSS suspicion. But in your case, I think it is an over reaction since the output is transient and will never be shown to anyone else than who entered it. Have you tried <script>alert(document.cookie);</script> as a password ? You could play game with your auditor by making the ...


1

The CVE statistics on Apache POI indicate only a single known vulnerability, which is of type "denial-of-service" and is expanded upon there: namely, a specially crafted document may make POI allocate tons of memory (that is, more than it already does normally). If such a vulnerability has been reported at all, then it means that behaviour of POI on hostile ...


0

I see from the tag that you mention Java. The technology you use makes a big difference in what certificate stores come into question. As Thomas says it's a whole different ball game for web browsers. If you are focusing on Sun / Oracle Java deployment you should be getting the same cabundle file. That being said you should be able to pick one off that ...


2

On Windows, CA are normally centralized in the OS, in the "trusted CA" store. Microsoft manages the default contents for this store, and they do this following an explicit "management program". You can find the list of CA there. Apple also runs a similar program and documents the list of root CA that a brand new OS X will trust by default. Of course, any ...


2

In "usual" SSL, the public and private key pairs are on the server side, not the client. The client uses the server's public key (as found in the server's certificate, that the server conveniently sends to the client during the first connection steps) but does not need to own a public/private key pair itself(*). Of course, this implies that while the client ...



Top 50 recent answers are included