• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Image Storage Suggestions needed

 
Ranch Hand
Posts: 495
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a requirement , this is to build an application that would store image retrieved from an Image Capture Machine, I cannot use a database because it would be too slow and i don't want to use the File System Storage because of Security concerns, what method of Storage can i use for this project
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The way I see it:

Create a user login/password for your application.
Hash the password using MD5 or SHA.
Fetch the image and write it you the hard drive using a set of outputstreams and put a self made outputstream between it so you can encode the bytes sent to the file using the hash of the user password.
And when you read the file again, use the same hash to decode the byte stream and build up the object again.

So in short terms, write to the filesystem but encrypt the files.
 
Rancher
Posts: 43027
76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What security concerns are those specifically? What are you trying to protect against? Also, would the file system be on the client or on a server?
 
Abiodun Adisa
Ranch Hand
Posts: 495
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ulf Dittmer:
What security concerns are those specifically? What are you trying to protect against? Also, would the file system be on the client or on a server?



This images are check images retrieved from a Check Scanner, so one would not just want to store them in a FileSystem, and if ones stores them on a file System how would you associate the images with the transaction ID which is the primary key identifying each image
 
Ulf Dittmer
Rancher
Posts: 43027
76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Encryption seems like a good idea, although it sounds as if the per-user encryption Sven suggested wouldn't work, as all users may need access to all images. So a system-wide encryption key is called for, which isn't accessible to anyone who might gain access to the file system drives (in other words, it's not stored on that system, just used).

It's not immediately clear that using the file system will necessarily be faster than using a database, though. Or have you done timings already?
 
Abiodun Adisa
Ranch Hand
Posts: 495
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We have done timings, when one is storing images that are about 2mb in sizes into a database, its is really slower than a file system and retrieving is another headarche, because theis images would need to be stored as blob, when retrieving one has to convert them to the proper format and this also impacts performance

Originally posted by Ulf Dittmer:
Encryption seems like a good idea, although it sounds as if the per-user encryption Sven suggested wouldn't work, as all users may need access to all images. So a system-wide encryption key is called for, which isn't accessible to anyone who might gain access to the file system drives (in other words, it's not stored on that system, just used).

It's not immediately clear that using the file system will necessarily be faster than using a database, though. Or have you done timings already?

 
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

and if ones stores them on a file System how would you associate the images with the transaction ID which is the primary key identifying each image



If you store them to disk - you would store the URL (location to the file on disk) in the database along with all the other information about that transaction. This is a common scenario.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How about using an encrypted removable hard disk for the images? It could be removed from the system and physically locked up when not needed.

Bill
 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Assuming you're getting these images and parsing them into java objects already, why not just implement a new Object containing the needed fields then use the magic of Externalize to solve the problem.

public class SecureCheckImage implements Externalizable {
public static final serialVersionUID = 1L;
private Image check;
private String key;
byte[] passwordDecrypt = new Byte[{Random.nextByte(),Random.nextByte(),...};
...
then make a writeExternal like:

PUT key into output stream
JPEGCOMPRES the image into a CRYPTO stream using passwordDecrypt as a hash then write that stream it into the output stream

Now the passwordDecrypt in my example is randomly generated, so it would have to be stored into a keystore along with the image key as a decryption reference. In the store, you can do all sorts of magnificent things like user access control.

The nice thing here is that the key isn't encrypted and can be indexed / resolved at any point without ever compromising the security of the contents. The same goes for any other public metadata if you decide to add them later on.
[ February 27, 2008: Message edited by: Daniel Chemko ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Abiodun Adisa:

if ones stores them on a file System how would you associate the images with the transaction ID which is the primary key identifying each image



Use the transaction id as the file name?
 
Evildoers! Eat my justice! And this tiny ad's justice too!
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic