Maarten Bodewes

Pat Farrell wrote:

Chuck Barnes wrote:So I am 'worried' about being less secure than a user manually downloading the file with a browser.

I'm not sure what part of downloading a file you are concerned about. From the server point of view, its got the file, and letting someone download the file is what a webserver does. HTML page, image, Excel spreadsheet, doesn't matter, they are all just files.

Usual practice is to use Basic Auth with SSL/TLS and declare victory.

From the client view, you have to make a number of leaps of faith that the server is who you think it is, that the file is what you think it is. TLS does a fairly weak job of addressing this, as the whole certificate schema is weak and nearly useless.

So the trick is to only to allow certain certificates. If you know when these certificates get refreshed, you could simply trust only that certificate (or that specific CA, and it's certificate status). Of course, if you go this way, it makes sense to test the connection now and then, or your users are stuck with no SSL connection.

Always keep the classes and methods separate. Normally, you would put the inner classes first. You keep the fields within the class where they belong. Try to avoid having too many inner classes. Also try to avoid classes that are basically copies. E.g. you could rewrite the X/YChangeListener to ChangeListener and a constructor with a label argument. That class could be adorned with the "static" keyword to show that it does not have any other side effects. As the use is exclusive to the MainPanel class, the class should probably be defined in there.

As for the fields, keep the fields as close to the class that uses them as possible. If you've already got a JPanel class, and the instance of this class uses the xLabel field exclusively, then this class should have the field, not the surrounding class (as the same way the X/YChangeListener class definitions should be local to the MainPanel class). Try and rewrite it in such a way that the MainPanel class is not defined within the ScrollTestTrouble class, but is a top-level class in its own file. In that case the class should have package visibility, which is accomplished by removing the private keyword.

Yeah, sorry, that was maybe a bit much. Tip 8 though is a pretty useful one, since you can take your regexp one piece at a time. Probably in this case you are expecting the dot to match any character, but because it is in between square brackets, it's just a dot.

Without looking into the reexp, I think you are on your way now. So I will give you some very important hints regarding regular expressions:
0) make sure there isn't already something that parses your input
1) don't make them too complex, you're better create a hierarchy, and mix parsing techniques - e.g first split things with String.split() if possible
2) describe them well, it may take a very long time to read a regexp, describe what you are trying to accomplish
3) create at least a couple of junit tests around them, with (at least) some corner cases, the expected good and possibly some bad scenarios
4) don't use them as technique to e.g. test ranges of numbers, dates etc., there are better tools for that, just test string input
5) remember that groups are *not* repetative (use Matcher.find() instead, or use other ways of repeating things from within the language (this trap caught me a few times)
6) learn to use non-capturing groups (you already got this one) and reluctant qualifiers
7) use findbugs to make sure your rexexps are at least valid at build time (findbugs can also check formatted strings)
8) use plugins for your favourite IDE that enable you to test regexps and their input in real time (extra points if they auto escape backslashes)
9) don't try to learn Pattern.html out of the top of your head, just the general techniques, that's what bookmarks and Google are for

Finally never forget that the Java regexp is brilliantly strong, and works on actual unicode strings - don't get disappointed if other languages don't give you that same robustness or flexibility.

General remarks: using Matcher.match() and a regular expression that starts with ^ and ends with $ makes the code a bit less error prone - currently you may match strings that have spurious information.

This stuff is very clearly specified in the Java language specs. Try them out, they're pretty readable regarding the base types, and you might learn things about the language you would not otherwise.

Bitwise operators are normally not used for business logic, much more for low level (on bytes etc) operations. One place where they are used much is cryptography and (again, low level) communication protocols.

As for the toHexStrring method:

private static final String toHex(final byte[] data) { StringBuilder sb = new StringBuilder(data.length * 2); for (int i = 0; i < data.length; i++) { sb.append(String.format("%02X", data[i] & 0xFF)); } return sb.toString(); }

Seems a bit more readable to me. Note the & bitwise operator that converts the (possibly negative) signed byte value to a possitive int.

[EDIT] this is a bit unfair of course, since String.format() almost certainly will use shift operators to generate the 2 digit hexadecimal string similar to the code given in the post above

Try Matcher.find() multiple times using "\\d+" as input...

Don't try and create locks on remote files, use something else, e.g. a database for synchronization (or try and work around your sync options).

What you could do is try to separate the security relevant parts of the running code and possibly the database itself. Make the target as small and well managed as possible. Make sure you manage those serivces well (e.g. software updates if security issues are found in any of the server applications).

Then you might want to think about encrypting the info in the database (e.g. public key in the front end, private key in the backoffice) - so that database compromise does not automatically lead to loss of confidentiality of the data. This is complex and should only be attempted after all the other security "holes" have been plugged.

Note: I'm a security professional, but this is only a fast reply on your question, there are many other things to consider as well.

Why would you use Java for this? Just make the config file only available to the account of the deamon, not any old user. The users only get access to the functions offered by the deamon.

I "interface" with HSM's all the time.

If you want direct (much more functionality) access, you can use the free PKCS#11 wrapper from IAIK (which is also used internally by the Sun PKCS#11 provider).

If you want compatible (JCE/JCA provider) access you can put a PKCS#11 library under the Sun PKCS#11 provider. It's very X509 certificate (SSL) centered.

Some HSM's may also be available through the MS Windows crypto layer, for which in 1.6 there is also a provider.

And then there is the functionality provided by HSM providers (some of which may be outdated & utter crap, be warned).

If you've got some money, you can pay IAIK for their provider, which at least may offer some assurance regarding compatability with your HSM.

About the exception handling: use BadPaddingException and then GeneralSecurityException - and convert at least the last one into a InvalidStateException. You can avoid the encoding exceptions by using Charset.forName() in later VM's. Note that any encoding is accepted by default, the exception normally only gets thrown if the encoding is not available; but Java specifies that "UTF-8" is ALWAYS available, so that's a bit of a moot point.

The only thing I can think of is that you somehow refer to a different JCE jar than the one that comes with 1.6, e.g. an older version. It's included in Java so there is no need to supply it. Most of the time, unless you have specific requirements, there is no need to indicate the provider anyway, just let Java look up the first one (it may e.g. be hardware accellerated on servers, or use a native provider such as NSS).

By the way, in 1.7 there is no specific need to sign providers anymore, but the signature still gets validated *if it is present*.