I have a project to build a voting desktop application for a class in Java. While security isn't the focus of the project, I would like to be as realistic as I can. What are some of the primary tools to integrate security into a Java application.
Edit: I'm not primarily worried about physical security, we are simply building an application not a whole system. I want to ensure votes are recorded correctly and not able to be changed or read by someone else.
It really depends on what kind of security you are looking to integrate. Do you want security to ensure that the user isn't running any debuggers or such to flip bits in your application to change the votes? Do you want to ensure that the user doesn't install logging software to keep track of who voted for who? Do you want to ensure that the person who is supposed to be voting is actually voting? Security is a very broad subject, and it's hard to give an answer without knowing what exactly you are looking for.
My company did lately app with very strong security. Maybe it helps.
Our app
It was java EE app.
Architecture is following:
Client computer has a cryptography package.
Dirty serwer that stores encrypted user input and output
Clean serwer that is not accesible from outside that stores keys and decrypted data.
Users are issued cryptography cards (you may want to use something less safe - eg. pgp), and are required by jsp pages to encrypt with them all input. Page contains component that connects to cryctography app, asks user for key passphrase, encrypts it with server public key and signs it with user private key, then submits.
Data is stored in external server then transferred to internal server, where it is decrypted and signature is verified, then data is processed and reencrypted, then it is sent to dirty server, and then user may get it.
So even if someone cracked the dirty server (even get hold of database) he would get mostly useless data.
Your app
I'd send encrypted and signed votes to server. It would assert two things:
You know who sent the vote
Noone wil be able to know what the vote was.
Then get data from server, assert that everyone voted at most once count the votes, voila!
If you're looking for a "higher-level" explanation of this stuff (as in, not code), Applied Cryptography has quite a few relevant examples (and I believe a section on "secure elections" that covers some voting strategies).
I'm not primarily worried about physical security, we are simply building an application not a whole system. I want to ensure votes are recorded correctly and not able to be changed or read by someone else.
Putting to one side questions of protecting against physical tampering (e.g. of the underlying database), since you've stipulated that physical security is not the present concern...
I think the primary consideration is how to ensure that a given voter votes only once. At a paper poll, each registered voter is restricted to a particular booth/location and verification is done by name+SSN and a signature.
You might need a high resolution digital signature capture and therefore a touchscreen capture peripheral or a touch screen terminal. A more sophisticated approach would be a biometric scanner, but that would require government records of thumb/finger prints or retinal scan - I can already see the privacy advocates lining up at the lawyer's offices.
Another approach would be for the voter "registrar office" to issue digital keys to each voter prior to the election - a (relatively) short (cryptographically strong) random alpha/numeric key that is entered with the voter's name and/or SSN into the application. Knowledge of that key is required for that particular voter in that particular election. These keys would be issued by post in tamper-evident envelopes, like those used by banks for postal confirmation of wire transfers and delivery of PIN numbers. The key must include checksum data so that the user can have the entry of it immediately validated and it should be in groups of 4, so something like XXXX-XXXX-XXXX-CCCC.
Any other "secret" knowledge, such as SSN, is likely too easily discovered for a large percentage of the population (though we don't seem to be able to make credit-granting organizations understand this), and therefore is unsuitable for authentication.
Vote counting can be done by generating a public key encrypted data file which is transferred (by sneaker net?) to the central system. This must include the "voting booth" identity information and a record for each voter including their SSN and the digital key (or signature, or biometric data). Votes with invalid keys are eliminated. Multiple votes with the same key and same votes are treated as a single vote for that candidate. Multiple votes with the same key and different votes are flagged for fraud investigation (with the constituent contacted by phone, issued a new key, and directed to revote).
Your problem is that you need to identify the user reliably, so that you can prevent them from re-voting and accessing each others votes.
This is not any different from any other desktop application that requires authentication (and potentially authorization). If your voters are a closed group on a network with user accounts, you could integrate with the directory and require users to log in.
If voters do not have network user accounts, this is where it gets interesting. Each user will still need to authenticate with the application. You could generate accounts with passwords in the application and distribute this information securely prior to voting. Your application could ask users to select a password when the access the application for the first time.
Without knowing the specifics, it is hard give a more specific answer.
You are aware that electronic voting is an unsolved research problem? Large scale fraud should take a large effort.
I believe that physical security is more important for voting booth system rather than you know, code security.
These machine by their very nature shouldn't be connected to any kind of public networks, especially not the the internet. But having a good physical security to prevent any sort of physical tampering is very important.
Related
Recently we have added a tool to find security holes in our organization. One of the issues that was found is that when connecting to a database (ex. using Hikari), we have to provide a String containing the password (encrypted, of course, which will be decrypted when used).
Now, keeping passwords in Strings is not safe, because it can be extracted, until garbage collector comes and clears it.
So we started changing our code to use char[] and byte[] (not sure it's the best, but the idea is that we can clear the array after usage, and not wait for garbage collector to clear it for us) to set our passwords on Hikari, but the last part of the flow is setting an unencrypted password String to Hikari. So all this fuss to find out that Hikari is keeping the password inside a String..
So am I supposed to change Hikari code and recompile it as our own organization implementation of Hikari which use passwords from a char[]? or what?
How can we avoid this?
Now, keeping passwords in Strings is not safe, because it can be extracted, until garbage collector comes and clears it.
Only if someone has sufficient access to capture what is in memory (or swap space on disk). If someone can do that, they can probably also do one or more of the following:
modify your application at the bytecode level to inject code to capture the secret
attach a debugger and use it to set a breakpoint at the point where the secret is used
read the secret from the file system, database, whatever
find the private key for your server's SSL certs and use it to snoop on the HTTPS traffic to your server,
walk out of your machine room with your hard drives, etc and then attack them at their leisure
and so on.
Spending a lot of effort to use char[] for handling passwords won't address any of those other ways of stealing the secrets.
And it won't address various other security blunders ... like porous firewalls, unencrypted backups saved to the cloud, keys on a stolen devops laptop, successful spear phishing, etc.
So am I supposed to change Hikari code and recompile it as our own organization implementation of Hikari which use passwords from a char[]? or what?
That is what you would need to do if you wanted to address this attack vector. Don't ever hold passwords in String objects, and make sure that you clear the char[] or byte[] or whatever that you use to hold them as soon as possible.
Are you "supposed" to do that? Shrug.
My advice would be to do a full security risk assessment, look at all of the issues and decide whether or not addressing this one will make a significant difference to overall security. Balance that against the costs of creating and maintaining the Hikari patches. On the flip-side, quantify the costs to your organization if (these) passwords were stolen.
But it is not up to us to decide what you should. And it is not even possible to give you an objective recommendation, because we don't understand the full context.
I want our staff who have iPhones to be able to get members of the public to digitally sign a document which starts out as a Spring based web-form.
This form is only present on our intranet and only completed by our staff.
My research so far has considered a number of possible solutions:
Electronic wet ink signature on the screen of the phone;
Using the fingerprint scanner on phone to capture a specific finger of the member of the public and store it digitally;
PKI system;
The purpose is to prove a particular person signed a document.
1 technically possible, but doesn't count for much as it could easily be copied.
Is it possible to capture a fingerprint via the browser and javascript on a iOS device?
Can 3 be made to fit this sort of scenario?
If you are trying to guarantee non-repudiation of the form by the member that signed it, I would recommend to use 3.
The process could go like this:
A key pair (K+, K-) (public, private) is generated for the user
The document is signed against K-(information_input_by_user)
You store K+ together with your user's records in some database.
Fetch K+ from the database and use it to prove the user is the authentic author of the signature
Note: information_input_by_user in line 2 could be any personal information related to the user (his own input) used to authenticate him.
I want to build an app which shows places around user using Google Places based on user interests. As mentioned here:
Place IDs are exempt from the caching restrictions stated in Section
10.5.d of the Google Maps APIs Terms of Service. You can therefore store place ID values indefinitely.
So, can I save place_id in cloud database and perform any analytics operation over it? For example; if I gather place_ids added in each user's favorite places table and from analytics; I can know which place_id are the most ones added to favorites? or can I show something like 'Trending Places' in app from gathered place_ids in responses?
Will it violate the terms and conditions? I read the whole page of terms but couldn't find the answer.
can anyone help me out? Thanks.
Yes you can 100% store the place_id indefinitely and reuse it.
See Referencing a Place with a Place ID.
Please note one thing that
A single place ID refers to only one place, but a place can have
multiple place IDs
These terms and conditions are kind of self explanatory. Except your requirement which will be clarified after the below link is read carefully. As per your requirement , inorder to prevent calling services next time with same query which user had done with an intention of saving network calls is acceptable.
No caching or storage: You will not pre-fetch, cache, index, or store any Content to be used outside the Service, except that you may store limited amounts of Content solely for the purpose of improving the performance of your Maps API Implementation due to network latency (and not for the purpose of preventing Google from accurately tracking usage), and only if such storage
1) is temporary (and in no event more than 30 calendar days)
2) is secure 3)
does not manipulate or aggregate any part of the Content or Service 4) and
does not modify attribution in any way. Go through this Section 10.5 Intellectual Property Restrictions. Subsection (B)
You'll need to contact Google to get a 100% answer.
That being said, from my experience it looks like the clause you included is intended exactly for the kind of thing you want to do.
Again, I want to reiterate that contacting Google directly is something you should do if you still have concerns.
You can store place ID values indefinitely.
Just What part of
You can therefore store place ID Values indefinitely.
Don't you understand?
Indefinitely requires a server.
Is there a way that I can integrate a pattern, say for a song tempo, into being used for access into a system?
To give more detail, if I wanted to discourage hackers from gaining access, is there a way that I can make a suite that would search the persons system covertly for a MAC address and ban that address if he/she doesn't get a certain tempo right with the keystrokes?
It seems pretty straightforward. You make an element that times keystrokes, you send the raw timing data back to the server, analyze it there against known patterns and what the tolerance of error is.
While it seems a bit wonky and perhaps not exactly user friendly (there's only a limited number of combinations of tempos and strokes so it would get cracked quickly) the digital logistics of it are pretty easy if you break it down into a handful of simple components.
I need to develop a feature in the system which allows unregistered users to get one-off system access via URL token that is generated/sent by an authenticated user.
For example, a user logs in and wants to share a piece of information so the system generates a URL like http://host/page?token=jkb345k4b5234k54kh5345kb34kb34. Then this URL is sent to an unregistered user who would follow the URL to get some limited access to normally protected data.
First question - are there any standards (RFC? IETF? others?) that would be defining URL generation? The only ones I was able to find are RFC2289 and OpenToken, but none of these are directly related to what I need to do and the latter is only in a second draft state.
There is another design consideration: whether to use one way crypto hash functions and store the payload in a local data store VS using private-public key pairs and encode all necessary payload in the unique string itself.
At the moment I am heavily leaning towards one way hash as it would give me much more freedom (no dependency between payload size and generated string) and less potential problems in the future (e.g. what if I decide to add more payload - how to ensure backwards compatibility). Last but not least, accidental exposure of server-side private key would require massive efforts in key regeneration, update of all live instances, etc. None of these problems are relevant if choosing one-way hash option, but maybe there's something I overlook? RFC2289 prefers one way crypto function whereas OpenToken chooses the key pair option.
And finally, is anybody aware of any Java library for generating these?
Thanks in advance.
Also have a look at http://en.wikipedia.org/wiki/Universally_unique_identifier and RFC4122. Inside the backend you would need to attach the generated uuid to your entity so verification based on the UUID can be done later.
Apart from that most often the token could include some data (e.g. versioning+userdata) and then a secure MD5-hash is used to 'obfuscate/anonymize' it. Later then the data is concatenated by server and the hash-values are compared again.
Regarding java-lib and uuid have a look at UUID-javadoc.
Generate random strings and store them in a database with credentials.
The codes generated need to have two properties: complexity and uniqueness. Complexity ensures that they cannot be guessed and uniqueness ensures that the same code can never be generated twice. Beyond this, the specific method doesn't matter.
Generate token strings with two parts to them. The first part is time-dependent, where the key will increment and change in a predictable way with each millisecond. The second part is completely random. Combined, this will give you a long string that is unique and complex.
When you generate the token, store it in the database with the credentials that are granted when this token is used. It's important that these credentials are not encoded into the string, since this ensures that the strings cannot be hacked.
When the user click on the link with the token, mark that token as used in the database. Even better is to set a timestamp for the use, so that it can be expired, perhaps, 24 hours after the first click. This approach gives you the flexibility to implement this specific part of the requirement as necessary for your project.
I've used this solution before in many different cases for not only one-off system access, but also for ticket admission codes, gift certificate codes, and anything that's one-time use. It doesn't matter so much what you use to generate the token, so much as you can guarantee its complexity and uniqueness.
Here's how I would have done it:
Create a token (you could use a UUID for this) and add it to your database along with creation time and what resource the token should grant access to
Send an email to the user with the url http://www.myserver.com/page?token=
When the user navigates to the url, create a new session with the desired timeout and mark that session as authorized to view whatever the database says the user should be able to see (If the token isn't too old. Check the creation time against current time)
Either delete the token from the database, or mark it as expired
You only need a token when a user shares one piece of information. So, can't you just generate a random token, and associate this with the piece of information (e.g. a database field)? It's a lot simpler than doing any crypto stuff...