This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Java in General and the fly likes Criptography Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Criptography" Watch "Criptography" New topic
Author

Criptography

rafael viana
Greenhorn

Joined: Aug 24, 2007
Posts: 1
Fellows,

i need to encrypt the username and password database informations that are stored under my %CATALINA_HOME%/conf/catalina/localhost/myAPP.xml file.

Has anyone already used the EncriptedDataSourceFactory class that is provided at
encrypt,so we can exchange some information about it?

Regards,
Rafael Roque
ITIL Foundations Certified
Sun Certified Enterprise Architect for Java 2 Enterprise Edition(I)
Sun Certified Web Component Developer for Java 2 Enterprise Edition
Sun Certified Programmer for Java 2 Platform Edition
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41155
    
  45
Welcome to JavaRanch.

"DataSource" generally implies that a database is accessed, so I don't think that it's any help with reading data from an XML file.

But you could subclass org.apache.catalina.realm.UserDatabaseRealm (which is the class dealing the user database XML file), and extend it to encrypt and decrypt the information along the way.


Ping & DNS - my free Android networking tools app
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

The normal spelling is cryptography. Most folks talk about encrypting and decrypting strings, but I have it on good authority that the folks at NSA prefer to use "encipher" and "decipher" since they are rarely taking shovels and picks to bury things.

The standard approach to securing passwords/passphrases is to put them through a one way hash, say MD5 or SHA1, and store the resulting hash. You then tell users that you can not tell them the old password, just give them a new one.

If you really want to encipher and decipher, then you have to keep the key, which is a real pain. 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.
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
Originally posted by Pat Farrell:
Good authority (such as the folks at No Such Agency) prefer to use shovels and picks to bury things since they are rarely being nice to people that come in to visit them.


Just a joke, no really,... it's a joke - no really !

The standard approach to securing passwords/passphrases is to put them through a one way hash, say MD5 or SHA1, and store the resulting hash. You then tell users that you can not tell them the old password, just give them a new one.


So I assume you would frown on my beginner approach:



Because it relies on a stored table which is xor'd against the incoming string and Colin Plumb's approach does not rely on something which could be worked backwards ?

************
message edit: Many companies are beginning to realize that Sarbanes Oxley compliance is not a one-time endeavor or expense like managing the Y2K problem. Original Poster's site citation may be worthy of Pat Farrell's review and comment.
************
[ September 01, 2007: Message edited by: Nicholas Jordan ]

"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

Originally posted by Nicholas Jordan:


So I assume you would frown on my beginner approach:

Because it relies on a stored table which is xor'd against the incoming string and Colin Plumb's approach does not rely on something which could be worked backwards ?



It really depends on what you are trying to do.
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.

(the old SHA1 is no longer considered "strong", but whether you need "strong" is an engineering decision).

Then to login, you get the userid and password, run the password through the SHA256 again, and compare the result with what the database stored the first time.

Real code to do it is not hard:





Many companies are beginning to realize that Sarbanes Oxley compliance is not a one-time endeavor or expense like managing the Y2K problem. Original Poster's site citation may be worthy of Pat Farrell's review and comment.



I looked at that article, and it uses "base64" for encipherment.
While that is fine for a tutorial, its a codec, not a cipher.
If you are at all about things like real security, or Sarbanes Oxley compliance, you have to use real ciphers and real key management.

Just taking a SHA is not encipherment, and is not strong enough. The above code sample uses a HMAC, which is a where you take a known (secret) string
and wrap the password with it.

Say the secret is "secret" and the password is 'password'
build up a sting of
String text = "password" + secret + "password";
and feed that to the SHA256.

As long as you keep your secret fairly secret, you are vastly more secure.

Whether that is "secure enough" for your auditors is a separate matter, and
not something professionals will post in a forum.
[ September 01, 2007: Message edited by: Pat Farrell ]
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
Pat,

This is so far ahead of anything else I have seen here at jr that I wish to exchange a few private messages with you.

This is a heavy weight response (compared to what I am acclimatized to) in open fora and so to answer your questions:

[PF:]It really depends on what you are trying to do.

This really funny, I wrote that code during an "all-night hair puller" that lasted several months. At the time I sat down, I could not code   int someint ;//   and reasoned that if I wrote some code I could understand, I would be more secure in my long-term goals (the discussion of this is involved) After contemplation, I reasoned that if I could key a place to put things on an int, I could achieve better time-based effectiveness and thus devote the unused machine power to other security issues about which I may have no knowledge at the time.

The approach is suggested by bruce schneier in recent works.

I then came up with a simple XOR idea and soon blew into the bowels of STL, where I found strlen() -> which was an obvious security hole.

Once I figured out what strlen does, I resolved to make the call a char[] with a length coming in with it and do my own runtime checks, the hell with the geezers ..... soon finding out that Java had done all of that for me. I am now writing in Java as my primary linguistic because of it's rich toolkit and elegant solution to such nasties as [] overrun.

My goal in writng that was to use a zero entrophy random xor key so that I could undersand the operation of the code. I figured I would write other code when my skills had advanced.

[PF:]As long as you keep your secret fairly secret, you are vastly more secure.

I have to admit that the people I work with make keep your secret fairly secret a real challenge, such as that by bruce schneier in recent works.

I could copy-paste your code directly into my project, but that would mean using code I do not understand. The design decision has been made in conjunction with Team Lead, who is trained in computer security but knows nothing more about enciperment than I do to employ a single round of 32-bit rsa to any protected data until such time as we know what we are doing. This level of encipherment was chosen to protect honest workers from routine mistakes, but will be replaced by something such as what you write as soon as we understand the tools.

Team Lead understands passphrase management, I have tested M. under real-world stress and performance was flawless.

The mention of Sarbanes-Oxley compliance was so that the other posters that may come along could see that you responded out of knowledge, not speculation. From experience, I can expect that Sarbanes-Oxley will leave finality in the hands of trained operators: By Larry M. Spirgel and Gavin B. Grover of Morrison & Foerster LLP

Something which would be difficult to determine running criptography on consumer-grade operating systems.

Meet me in Meaningless Drivel to discuss the issues involved in a realistic assessment of such.

There is no mercy where professionals are concerned.



//eof
[ September 04, 2007: Message edited by: Nicholas Jordan ]
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

Originally posted by Nicholas Jordan:
This is so far ahead of anything else I have seen here at jr that I wish to exchange a few private messages with you.

my "handle" is my real name, google for "Pat Farrell security"


This is a heavy weight response (compared to what I am acclimatized to) in open fora



I'm a heavy weight guy, too close to 300 pounds for my doctor's preference.
Would be nice to lose 75 or 100 pounds, but I'd have to give up ice cream.


I could achieve better time-based effectiveness and thus devote the unused machine power to other security issues about which I may have no knowledge at the time.


using a computer to do stuff instead of using a human is a good idea. But while security needs are well known, at least per the media hype over the latest bad thing(tm), good security is actually hard.


The approach is suggested by bruce schneier in recent works.

Bruce often writes about how easy it is to screw up. Security is somewhat like global politics, its not as easy as saying the right thing to Pakistan and hoping that the India govenment won't notice.


I have to admit that the people I work with make keep your secret fairly secret a real challenge, such as that by bruce schneier in recent works.



It is a really, really hard problem in general. The first thing you realise is that just as most retail shoplifting is done by employees, most security hacks are not done by breaking ciphers, its by exploiting the weakest link, the humans. Read up on "social engineering" it is amazing. If you check out Kevin Mitnick's record, he was a master at social engineering.

The spy movie cliche of a serious guy with a briefcase handcuffed to his wrist is not far from the truth of how to transport keys. The real definition of "key" is really that of "secret".


I could copy-paste your code directly into my project, but that would mean using code I do not understand.

So go back and read the RFC, that is the source of much knowledge.
From it, you can follow the code with only a tiny bit of Java knowledge. This is a Java forum.


to employ a single round of 32-bit rsa



32 bit RSA? Are your sure that isn't a typo? 256 bit RSA is so weak no one thinks about it. 768 bit was considered fairly strong in 1996 when I was doing crypto at CyberCash, Anything less than 1024 is too wimpy to be much better than SBO today.

If it is worth protecting, it is worth using 2048 bit RSA for the key exchange, and AES-128 for the session.

--- edited to fix quoting and make sentence about 1024 bit keys be logical --
[ September 06, 2007: Message edited by: Pat Farrell ]
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
Brother, I will see you in Meaningless Drivel - there you can watch Mad Dogs and inglishmen lock in a Neutron Spin.

Original Poster asked about Criptography, not Cryptography and we are already outside of the domain of Quantum Cryptography ~ that being considered speculative, at best, and be forewarned: I owe several Doctorates here at the ranch an apology. I trashed my reputation early and quick in Removing Entires From a Collection, figuring worrying about my reputation to be a security risk.

Here, as noted, apologetics for those for whom it matters.

JY - For exploiting the newfound interlocutor with not well developed work.
EFH - For the no mercy thing, in the post about REGEX's
HW - The Zoe in the discussions, usually, for interrupting Christmas Shopping.

Note Pat, the above three hold Doctorates. The subject of work will be your proposal: cost of attack can be evaluated in terms of the work effort to the attacker

I counter that the typical is closer to your work here, than that proposed in: Towards a Model of Computer Security As an example, we have lost $1,400 in mop buckets in a few weeks, and have to borrow them from ..... It is a really, really hard problem in general, like when SuperModels think really, really hard.

Example: Somebody, because of my early confused work, above my skill level and overloaded from regular day job, went through my website at Mission Statement: Belvedere Computer Services in which I used the phrase: "trapping the ignorant in Mind Games", speaking to Jack - team member degreed in Industrial Engineering - .... and becuse it (my posts there) looked, and for all in the world amounted to just that and nothing more circulated a rumor about me.

I told my confidant that it was just a risk I have to assume.

Those above will recognize, from my apologizing here, that one of them will be packing a Golden Parachute; One will be waiting to record the ricochet (pronounced Rick-oh-shay) of a Board Heaing as my ideas get bounced off the Saloon Wall; And one will be able to keep up with me Full-Tilt-Boogie as the afterburners open up.

[ Fast text searching is what I needed the hashing for. ]
[ September 15, 2007: Message edited by: Nicholas Jordan ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Criptography
 
Similar Threads
Passed SCEA part I with 93%
Selling Sun Exam Voucher
Help required
Which version of EJB spec we have to read ?
SCEA BETA Part II and III results Master Thread