• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

Encrypt with JAVA (jasypt) and Decrypt with PHP

 
Ranch Hand
Posts: 30
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
**Encrypt with JAVA (jasypt) and Decrypt with PHP ?**            


-------

Im working on a legacy system that has the following tasks:

**1)** The Java Application saves some encrypted data on a mysql database. This happens very rarely. The data is saved once and rarely updated.

**2)** A PHP page loads that encrypted data from the mysql database and uses it for internal logic. This php page must be able to decrypt it internally, but not to encrypt it.

**3)** The java Application also loads the encrypted data from the mysql database and decrypts it for internal purposes.


In another words, I have a Java application that encrypts and decrypts data. And I have a php single page that must be able to decrypt the data.


------

**Currently,** I must re-do this with new crypto algorithms. I researched at stackoverflow and many are saying to stay away from MD5 and DES. As far as I understood, I must go with AES, So Ive came up with the following java CODE below. However:

**a)** Im unsure how to decrypt with php, I normally use openSSL but I dont know the equivalent algo name in php.





   



 
Saloon Keeper
Posts: 12027
257
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's no real point to using password based encryption if no password is being entered by a user. PooledPBEStringEncryptor internally uses an algorithm that follows the PKCS #5 RFC, which contains recommendations for encrypting data using passwords, such as making the encryption process more expensive than it could be when the encryption key is only present on the server. I took a quick look at Jasypt and it appears they only support password based encryption. I recommend dropping it and just using the standard API's Cipher class.

If your Java and PHP applications will be running on the same server, you can just generate an AES key once and store it in a file that is accessible by both applications. There might be an easy way to read a Java KeyStore file in PHP, but if not then you can easily just write your own format. I believe openssl_decrypt accepts a Base64 encoded key, so if you store the key using a custom file format, the format could just be the encryption key as Base64.

The salt must not be hard-coded, and it must not be a fixed value. Java's Cipher class will automatically generate an initialization vector (IV, another name for salt). You can get the IV from the cipher when you encrypt and then either add it to the front of the encrypted message or store it in a separate column in your table. To decrypt it in PHP, cut the IV from the front of the encrypted message or retrieve it from the table and use it for the salt parameter of the openssl_decrypt function.

Which encryption algorithm to use strongly depends on what you're going to do with the encrypted message afterwards. If the database that you store the encrypted message in will always be located on the same machine as the two applications, then you can use unauthenticated encryption, such as "AES-256-CBC" ("AES/CBC/PKCS5Padding" in Java). If the database can be on an untrusted machine, or accessed through an untrusted network, or if the encrypted message are otherwise accessible by untrusted applications, then you must use authenticated encryption. A good default algorithm to use is "AES-256-GCM" ("AES/GCM/PKCS5Padding" in Java).
 
Castiel Snow
Ranch Hand
Posts: 30
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:There's no real point to using password based encryption if no password is being entered by a user. PooledPBEStringEncryptor internally uses an algorithm that follows the PKCS #5 RFC, which contains recommendations for encrypting data using passwords, such as making the encryption process more expensive than it could be when the encryption key is only present on the server. I took a quick look at Jasypt and it appears they only support password based encryption. I recommend dropping it and just using the standard API's Cipher class.

If your Java and PHP applications will be running on the same server, you can just generate an AES key once and store it in a file that is accessible by both applications. There might be an easy way to read a Java KeyStore file in PHP, but if not then you can easily just write your own format. I believe openssl_decrypt accepts a Base64 encoded key, so if you store the key using a custom file format, the format could just be the encryption key as Base64.

The salt must not be hard-coded, and it must not be a fixed value. Java's Cipher class will automatically generate an initialization vector (IV, another name for salt). You can get the IV from the cipher when you encrypt and then either add it to the front of the encrypted message or store it in a separate column in your table. To decrypt it in PHP, cut the IV from the front of the encrypted message or retrieve it from the table and use it for the salt parameter of the openssl_decrypt function.

Which encryption algorithm to use strongly depends on what you're going to do with the encrypted message afterwards. If the database that you store the encrypted message in will always be located on the same machine as the two applications, then you can use unauthenticated encryption, such as "AES-256-CBC" ("AES/CBC/PKCS5Padding" in Java). If the database can be on an untrusted machine, or accessed through an untrusted network, or if the encrypted message are otherwise accessible by untrusted applications, then you must use authenticated encryption. A good default algorithm to use is "AES-256-GCM" ("AES/GCM/PKCS5Padding" in Java).



Thanks for the reply.

I have two questions:

1) The java part is desktop app that runs in multiple nodes. Does that Cipher solution still applies?

2) The database is in the cloud, always in the same place, but the java desktop APP isnt. The php file isnt on the same server either.


Hmm, if possible, could you post some small snippet code to point me to the right direction?

PS: I should have picked a crypto course on my masters'degree. I regret it so much rn.
 
Stephan van Hulst
Saloon Keeper
Posts: 12027
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Castiel Snow wrote:1) The java part is desktop app that runs in multiple nodes. Does that Cipher solution still applies?


Cipher will be used regardless. The library you found was probably built on top of Cipher. *How* to use it depends on who will be using your Java application (regular users/trusted administrators), what they'll be using it for and on what machines they'll be running it (trusted nodes in company domain/external systems). Maybe you can tell us a little bit more about what your application is supposed to do.

2) The database is in the cloud, always in the same place, but the java desktop APP isnt. The php file isnt on the same server either.


Then you need to use authenticated encryption. Whether to use password based encryption depends on how the application is used.

Hmm, if possible, could you post some small snippet code to point me to the right direction?


Sure. Just give us some more details about the purpose of your application and I'll come up with something later. Yesterday was a long day so I'm going to take it a bit easy first.

PS: I should have picked a crypto course on my masters'degree. I regret it so much rn.


I don't think it would have been super relevant. Cryptography courses in academic institutes are mostly about the mathematics behind cryptographic primitives, not how and when you should use specific algorithms.
 
Castiel Snow
Ranch Hand
Posts: 30
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!
I will try to answer your questions the best I can.

1-Regular users and in non-controlled domains. Basically end-user. So I have no control of where the app is running. Its supposed to run anywhere the client wants.

2- Ok, I will give a small example:

--- Suppose 0 to n desktop users.
--- Suppose a single Mysql Database in the cloud (read AWS).
--- Suppose a single WebHost which holds a website and the php files that are accessed.

The user install the java desktop app.
The user put the login and password and click LOGIN -> The app,  goes to the webhost, sends the data to a certain php file and requests the database url and data that comes ENCRYPTED through JASPYR and it also comes through https. Once the data is returned, we decrypt it and login to the database directly.
...

Certain data can be accessed direcltly to the website through php files without the java app. So the php logic should be able to decrypt the database url as well.

--

I know this isnt perfect but its a small system and its safe enough for its purposes.

In Summary:

Open x.jar --> Click Login --> Send POST with data --> receive ENCRYPTED database url and data --> login directly to database.

What is encrypted? Database URL in the database.
Who should decrypt it? Java app and php
How safe should it be? Enough to avoid simple hacks and not so much that is slow or causes problems to the users.

And since it uses HTTPS, it already has some additional protection layer.






 
Stephan van Hulst
Saloon Keeper
Posts: 12027
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please don't quote entire posts, especially not if they are the last post in the topic. It makes the topic harder to read. I have removed the quote from your post.

Your requirements don't really make sense to me. You say that the Java application (that runs on client machines) does the encrypting. Why are end-users encrypting a database URL?

Assuming that the client application is the one encrypting the data, and the encryption is done to prevent interception of the data while it is sent to the web service, why are you encrypting the data at all if you're also already relying on a secure protocol like HTTPS?
 
Castiel Snow
Ranch Hand
Posts: 30
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(Sorry, didnt mean to)² . The quarantine is affecting my attention


1- The database URL is previously encrypted by the 'admin version' of the app. So both apps are supposed to decrypt it.

2-Paranoia. And, if someone, somehow, get access to the database, they still would need to decrypt those informations. Which may seem irrelevant since they would already had access to the database itself. However, I think that a small encryption would suffice just so its not plain-text.
 
Stephan van Hulst
Saloon Keeper
Posts: 12027
257
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, to get things straight:

  • There are actually four components: A web service written in PHP, a MySQL database, an admin application written in Java and a client application written in Java.
  • The admin application logs in with the web service and sends a database URL. The web service stores it somewhere.
  • The client application logs in with the web service and retrieves the database URL.
  • The client application uses the database URL to access a database directly.

  • Open questions:

  • Where is the database URL stored? Surely not in the same database that the URL points to? How would the web service know where to retrieve the URL from?
  • How does the admin application log in? Does it use a fixed password that is shared with the client application? This is a super bad idea.
  • Where does the admin application run? Also in untrusted domains?
  • Why does the client application access the database directly, rather than through the web service?
  •  
    Castiel Snow
    Ranch Hand
    Posts: 30
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Where is the database URL stored? Surely not in the same database that the URL points to? How would the web service know where to retrieve the URL from?
    How does the admin application log in? Does it use a fixed password that is shared with the client application? This is a super bad idea.
    Where does the admin application run? Also in untrusted domains?
    Why does the client application access the database directly, rather than through the web service?

    1- In the same database but in a different schema. What happens is that, depending on the user login, it points to a different schema.

    2- The admin is just another java app that encrypts the information and stores it there.

    3- The admin app just run in my machine.

    4- Because since im a solo dev, I dont have time to implement a web service to be the middleware. its a future feature though.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 12027
    257
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Castiel Snow wrote:1- In the same database but in a different schema. What happens is that, depending on the user login, it points to a different schema.


    This still doesn't make sense. For the web service to retrieve the database URL, it must know where to retrieve it from. If the web application already knows the URL, then what is the point of storing it in the database as well?

    2- The admin is just another java app that encrypts the information and stores it there.


    I suppose that the admin application accesses the database directly as well and has no need to ever call the web service?

    3- The admin app just run in my machine.


    Okay, so you trust the machine it is running on and you can load a secret key from there?

    4- Because since im a solo dev, I dont have time to implement a web service to be the middleware.


    I think you're confused in what the word 'middleware' means. Middleware is software that handles low-level systems so you can focus on writing high-level code.

    A system that runs between two other systems to prevent direct communication is called a 'proxy'. Having all database access done through your web service is not very difficult, and you can probably do it quicker than fudging around with a cryptosystem to implement some sort of scheme that gives a false sense of security in the first place.

    Let me condense all of this to the core problem: You're trying to access a database directly from a client application running on an untrusted system. Because the end-user doesn't know where the database is located and doesn't have the credentials to access it, your application needs to retrieve this data from your web service. You want to encrypt this data even though it is already encrypted, because you don't trust HTTPS enough. By the way, HTTPS is built on top of similar encryption primitives that you will be using in your hand written solution, by a team of very experienced people.

    The interesting thing is that you don't trust HTTPS to sufficiently secure yourself against a determined attacker, but somehow it is secure enough to decrypt the database's credentials on the client machine (where all a determined attacker has to do to get the plaintext credentials is perform a memory dump).

    I hope you see the flaw in this plan. If you are still determined to implement it, I will show you how, but consider what I said first.
     
    Castiel Snow
    Ranch Hand
    Posts: 30
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Having all database access done through your web service is not very difficult.

    Hmm, Ive heard its very difficult.
    Im using hibernate on java currently.. Would I need to make major changes?


    2- Yes, I want to insist in this solution for now. But im interested in what you said about webservice. I might do that afterwards.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 12027
    257
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hard to say, because I don't know what your database looks like or how you are accessing it from PHP. How big is your PHP application? Can't you convert it to a Java servlet?
     
    Castiel Snow
    Ranch Hand
    Posts: 30
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    "Can't you convert it to a Java servlet?"
    Yes. Good Idea actually.

     
    Stephan van Hulst
    Saloon Keeper
    Posts: 12027
    257
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Well in that case all you need to do is call an action on your servlet from your client, and the servlet will then use the credentials that are stored on the server to access the database and return the data to the client. That way the client doesn't need to know anything about the database.
     
    She'll be back. I'm just gonna wait here. With this tiny ad:
    Devious Experiments for a Truly Passive Greenhouse!
    https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
      Bookmark Topic Watch Topic
    • New Topic