Forums Register Login

Saving data after application exit

+Pie Number of slices to send: Send
Hi.

I know data can be saved to a text file when a java application is exited and can be retrievd again from this file when opened again. But, can data be saved into a different type of file so that it is not so easily accesable by the user?

Thanks
+Pie Number of slices to send: Send
yes, just specifiy the file name in the constructor:

File filbert = new File("Internal.dat");// or whatever

and the file writes can be done with some more work and with a little bit of forward motion in your studies. The answer to your question is a definite yes - and it is usually done that way. Do you want to save the data in an internal format that prevents snooping ?



[ Message edited: here's another person working on the same problem ]
[ They are somewhat ahead of you: http://www.javaranch.com ]
[ September 23, 2007: Message edited by: Nicholas Jordan ]
+Pie Number of slices to send: Send
One caution on using ObjectStreams for this purpose. Many classes in the library warn you that a serialized version of this object may not be compatible with future versions of Java. That means if you compile with a newer JDK one day, you may not be able to read the files saved with the old version. You decide how big a risk that is to you.
+Pie Number of slices to send: Send
Yes, it's like Stan says - almost every file I look into has the disclaimer:


... well, I went looking for it and did not find it but is states serial version id may not be compatible with future versions.

Okay, that makes sense, but this is really what you need to look at:
Don't try to do character conversions yourself, either work in your own internal format, or let the jvm write characters as the local platform understands them.
+Pie Number of slices to send: Send
Thanks for your help people. I shall research into your suggestions.

BTW Nicholas, yes it is snooping I definately DONT want.

SB
[ September 24, 2007: Message edited by: Sam Bluesman ]
+Pie Number of slices to send: Send
[Sam Bluesman:]BTW Nicholas, yes it is snooping I defiantly DONT want.

Then you will have to look into the Java Cryptography Architecture.

Crypto is widely discussed and it is almost a collary of crypto that trying to do your own will result in weak protections. The average curiosity seeker can be defeated by just writing what you want as byte[], naming the file to extensions such as dot dat, which will be picked up by the music player if the shell is used to explore.

I got random byte[256] written to a file in the last few days, not to say that I know how to use that as a source of random bytes or keys or anything else: It has a great deal to do with how sophisticated your inquisitor is and how valuable your data is. See discussion I had recently with Pat Farrell in the advanced forum.

Note, I tried using file buffers that sounded like they were correct for what I wanted to do ~ all of them failed miserably. I went back to the basics, writing some code I could understand, and got some useable file writes done.

See my discussion of the issue at:

http://docdubya.com/belvedere/statement/index.html

It discusses the attack scenario, set to midi background music, in a manner that is brutal in it's dismissal of many first approaches to the problem.

Do not under-estimate your attacker.
+Pie Number of slices to send: Send


The data would be available in the byteBuffer after a read. Java should, to keep up with the developments in other facets of the linguistic, provide for a 64 byte broadside datablock transfer op from persistent storage to L2 cache, to do all io as 8-bit bytes sorta bites you in places you do not want to be bitten in.

The code has not been tested, significant work remains. The posting is only for ideas on how to approach the problem.


[ September 30, 2007: Message edited by: Nicholas Jordan ]
+Pie Number of slices to send: Send
The AntiSnoop code is rather inefficient and has very little to do with what Sam asked about; he would be well advised to just study the Java Cryptography Architecture. Specifically, I would look at Using Password-Based Encryption. If you're guarding one user's data against other users, then get the user to supply a password. If you're trying to guard against snooping by any user, that's much harder if the users are hackers, but you can at least guard against casual snooping by hard-coding a password into your program.

Nicholas, if you want to discuss what your think is wrong with the standard IO classes, or how to use them more effectively than you do here, I suggest a separate thread. Let's not distract Sam from what he's actually trying to do.
[ September 30, 2007: Message edited by: Jim Yingst ]
+Pie Number of slices to send: Send
[JY:]The AntiSnoop code is rather inefficient and has very little to do with what Sam asked about.

Sam's question was:   But, can data be saved into a different type of file so that it is not so easily accesable by the user?  

My approach was to provide code that ran. While you are correct in directing original poster to JCA, I found that I was not able to use it to accomplish concealment from snoopers. What power, in the hands of untrained, is efficient ? My code, by not using passwords, allows Original Poster to dispense with password management issues entirely by writng the data in a format of Sam's design and thus accomplishes his goal: not so easily accesable by the user . The idea of of storing a password hardcoded in a program introduces a weakness that did not exist before, that of a real intruder recovering the password from the compiled code and thus aliasing the authorized user. This was discussed recently in the Advaned:   Criptography   where PF dismisses hardcoded keys

Originally posted by: Pat Farrell Keeping the key in a config file or other secret or obscure place is not secure, and making a human type it in every time the system restarts is a headache at best.



I direct Sam's attention to that post if he needs anything more effective than class AntiSnoop, especially to avoid hardcoding passwords in source code.

[JY: ]Nicholas, if you want to discuss what your think is wrong with the standard IO classes, or how to use them more effectively than you do here, I suggest a separate thread. Let's not distract Sam from what he's actually trying to do

Agreed, except that I would like to be called Nick in routine, casual conversations. I am posting your pointer in Using Java as opposed to another language where performance counts
[ October 03, 2007: Message edited by: Nicholas Jordan ]
+Pie Number of slices to send: Send
[Nick]: My code, by not using passwords, allows Original Poster to dispense with password management issues entirely by writng the data in a format of Sam's design

In other words, it leaves it entirely up to Sam to find a way to encrypt or at least obfuscate his data. Your class AntiSnoop doesn't do anything remotely resembling encryption or decryption; it just does what a FileInputStream does, but more slowly. It doesn't seem to be of any use in answering Sam's question.

[It also has nothing to do with solving the blocking problem you refer to here, - but I'm not going to follow you there since that is, once again, an off-topic post in someone else's thread. If you want to talk about something specific, don't parasitize other people's threads - start a thread of your own, and stay focused on that topic long enough to make your point without driving people away with rambling discourses on everything else under the sun. Focus, please.]

[Nick]: The idea of of storing a password hardcoded in a program introduces a weakness that did not exist before, that of a real intruder recovering the password from the compiled code and thus aliasing the authorized user.

Sam was vague about who he's defending against - snooping by whom? If you read what I wrote, I only suggested the hard-coded password in the event that the programmer is attempting to hide the data from all users, including the person running the program. Against such a user, there's not much you can do if the person has enough technical knowledge - anything you do can be reverse-engineered somehow. Which is why I said my hard-coded password suggestion might be good against casual snoopers, nothing more. Again, we don't know who Sam is trying to defend against, but if it includes the owner of the process running the program, obfuscation is probably the most we can hope for. Feel free to make a specific alternate suggestion; I don't see a specific solution for this problem in the Cryptography thread.
[ October 03, 2007: Message edited by: Jim Yingst ]
+Pie Number of slices to send: Send
[JY:]In other words, it leaves it entirely up to Sam to find a way to encrypt or at least obfuscate his data. Your class AntiSnoop doesn't do anything remotely resembling encryption or decryption; it just does what a FileInputStream does, but more slowly. It doesn't seem to be of any use in answering Sam's question.

Sam's question was "can data be saved into a different type of file ", which the java source I wrote did just exactly that, nothing more. From what I can find, Serialization leaves data in a readable format. The code I provided addressed additonally what I thought to be a flaw, clearing the buffer before a read so that on return -1 the buffer does not contain garbage from a partial buffer fill.

Sam asked "save the data in a different format" and did not ask about encipherment. It seems a simple rot 1 or something would come to the posters mind and would make the risk assessment correctly.

[JY:]Sam was vague about who he's defending against - snooping by whom? If you read what I wrote, I only suggested the hard-coded password in the event that the programmer is attempting to hide the data from all users, including the person running the program. Against such a user, there's not much you can do if the person has enough technical knowledge - anything you do can be reverse-engineered somehow. Which is why I said my hard-coded password suggestion might be good against casual snoopers, nothing more. Again, we don't know who Sam is trying to defend against, but if it includes the owner of the process running the program, obfuscation is probably the most we can hope for. Feel free to make a specific alternate suggestion; I don't see a specific solution for this problem in the Cryptography thread.

It was apparent to me, and still is, that if Sam writes bytes in a format that only he knows, then the issue of passwords does not enter the solution. (unless of course he tells us he wants to do it that way ) Your solution brought to mind the type of person I have to deal with every day, and caused me alarm. I wrote the code for the poster because in my experience, trying to utilize JCA when the poster just wants to write bytes introduces a partially implemented solution and is a seriously flawed because of an incomplete grasp of the method used. Granted, the only real solution to Sam's question is real enciperment, which JCA can put within his grasp. But casual snooper defense does not require JCA.

I chose FileInputStream becase it does not do character conversion, which I assumed it would be incumbent on someone doing this type of work to at least read enough to know the difference between Streams and Writers.

The solution in the cryptography thread is very specific:   Java includes a real SHA256, so it is not much harder, and not all that much slower to just take the user's password, push it through the SHA256, and store the results when the userid/password is created which would alleviate the storing of passwords in compiled code.

That would be the correct solution. Since Sam was vague about who he's defending against, and has not provided further information, it may be difficult to work our discussion productively.

I deleted the f=15 t=001635 post, that does not interest you. At a minimum, assent that the code I posted was well intentioned. Protecting data from anyone, informed or otherwise, requires the type of discussion we are having. We know this, observers may not.
+Pie Number of slices to send: Send
[Nick]: The solution in the cryptography thread is very specific: Java includes a real SHA256, so it is not much harder, and not all that much slower to just take the user's password, push it through the SHA256, and store the results when the userid/password is created which would alleviate the storing of passwords in compiled code.]

If you use the user's password, then obviously the user has the ability to decrypt it. If you look again at the part where I mentioned a hard-coded password, I was considering the possibility that Sam was trying to prevent snooping from everyone, including the user himself (or herself). So using the user's own password is hardly any more secure against them than using a hard-coded password that they can reverse engineer.

[Nick]: It was apparent to me, and still is, that if Sam writes bytes in a format that only he knows, then the issue of passwords does not enter the solution.

If the snooper can figure out how to read the hard-coded password, they can also read the code that writes the data, and figure out the format easily enough. Moreover, merely using "a format that only he knows" has a high chance of leaving Strings readable to even more casual viewers unless extra steps are taken to scramble it somehow. Rot-13 would work for this purpose too.

[Nick]: I wrote the code for the poster because in my experience, trying to utilize JCA when the poster just wants to write bytes introduces a partially implemented solution and is a seriously flawed because of an incomplete grasp of the method used. Granted, the only real solution to Sam's question is real enciperment, which JCA can put within his grasp. But casual snooper defense does not require JCA.

Nick, you were the one who advised him to look into the JCA earlier. I merely pointed him towards a specific working example of it, because your "AntiSnoop" did nothing at all to scramble the data in any way, even with rot-13.

Any how, without more info on what sort of "different format" Sam wants, and what sort of snoopers he wants to defend against, there's little point in continuing this.
[ October 03, 2007: Message edited by: Jim Yingst ]
"Don't believe every tiny ad you see on the internet. But this one is rock solid." - George Washington
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 2542 times.
Similar Threads
File Access from a Directory.
Status & Cookie
PDF generate using jasper reports
How to handle this scenario.
serialization and transient
How to make resource file secured
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 11:57:43.