So I've been looking at the email package provided in apache's org.apache.commons.mail. The basic tutorial is simple , straightforward, and works well.
https://commons.apache.org/proper/commons-email/userguide.html
The problem I am experiencing is that I don't wish to create cleartext passwords. What I wish to do instead is to hash the password using MD5, store it that way, then create an email later at the appropriate time. The important thing is not to store a cleartext password in the system.
Reviewing the wiki article on SMTP Authentication
implies there are at least three methods to do this -- DIGEST-MD5, CRAM-MD5, and MD5 itself.
Googling, however, does not reveal any obvious way to make this happen with apache. It appears that Jetty wrote their own digestauthenticator to replace Apache's DefaultAuthenticator.
http://download.eclipse.org/jetty/stable-9/apidocs/org/eclipse/jetty/security/authentication/DigestAuthenticator.html
And Apache's Tomcat likewise has a DigestAuthenticator.
However, since neither of these inherit from
javax.mail.Authenticator
I can't simply swap them in.
So ... is there a simple way to configure org.apache.commons.mail.Email and its children to use digest authentication? I haven't been able to find any examples or tutorials , nor have I been able to find anything on kindle. But given that no one's used cleartext since about 1975 , I can't imagine this setting doesn't exist.
Respectfully,
Brian P.
Related
I know this is a pretty noob question but I've been reading some manuals and documentations and can't figure something out.
I have an automation suite (in Java/Groovy) that in some cases needs to query an email inbox to check that a message with a given subject has been received and also probably delete all messages older than X. That's pretty much all I need to do and I've been looking into creating a gmail account and using the Google API Java client that's available here -> https://developers.google.com/api-client-library/java/apis/gmail/v1 but I can't figure our how to actually do it.
Right now what I have absolutely no clue how to do is the authentication. I can probably figure out how to interact with emails by going through the methods/code but I can't find any examples on how to authenticate so that the code can get access.
I tried looking for examples here and checking the code here. I know the answer is there but I still can't wrap my head around how to implement the code to sign in/authorize based on a username and password.
Thanks!.
This is the link you need. In this page it's explained authentication mechanism for Google API. They are using OAuth 2.0, which is probably the most used authentication method nowdays.
There is a standard flow that takes the client from credentials to an access token that can be used to perform authorised requests. This flow is described in the OAuth specification which is very useful to understand. Many APIs use it.
If you have specific questions, please let us know.
I've configured servlet, and other things needed to have role-based access to resources. I'm using JDBCLoginService to access roles data from DB. All works great, my only problem is: how to configure Jetty that in database I'll have passwords encrypted (preferably not MD5).
I found several docs saying you can run some tool given by jetty and it produces you MD5 or OBF, etc. But I wonder how to get list of avail ciphers?
I believe in table with users, column with password should have something like "MD5:897897979".
But I want to add users to this table by functionality like register/signup. So I need to encrypt password sent from browser and put to DB. But I can't control algorithm which is used by JDBCLoginService to check data sent by user from login page.
I believe it's implemented in some smart way that not much extra code is needed, but I can't just find info how to do it :/
I had a similar problem and tried to resort to the facilities provided by the Password class in the Jetty distribution.
However, eventually I couldn't adopt that approach since I was in need of storing the passwords hashed with a specific algorithm (namely sha256 or sha512) and I couldn't find a way to get the JDBCLoginService work with such hash algorithms.
This was kind of a let down, especially because Tomcat comes with the support of those algorithms out of the box when it comes to handle database-backed authentication scenarios.
I found this problem today. And the solution I ended doing is to have the sha256 calculated for the password input field in the browser side. You can do it on form submit or any other event if you are careful not to re-hash. Simple check or password length less that 64 would be sufficient to avoid rehash. I used the below to do the hash
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest
Paradoxically this solution makes it stronger as the password is hashed from the browser itself. Of course it could be exploited from this same web app but not in others that do not use hashing from browser if the is is used for other authentications.
Sorry in advance if this question has been posted before. I have look around but couldn't find an answer.
I am creating a server in Java that has a SSL socket to accept clients. I have been looking around on how to create the socket and have started to add the code to my application. After looking around the find out how to allow a self-signed certificate for testing I found that I create a keystore and add the certificate to that. To use the certificate I would need to add "System.setProperty("javax.net.ssl.keyStore", "keystorename.jks")" The only problem is I have to specify the password in the code as well if I go off other developers examples.
I would like to know if I have to specify the password and if I do need to what is the security implications?
Thanks in advance,
Yes you do, and the security implication is that the password is (1) fixed by the code and (2) probably visible in the object code. The solution to (2) is ultimately physical security of the software and the host it runs on.
This question may seem like a novice, and perhaps 'stupid' question but please bear with me...
I'm still struggling to find a way to get my Java application to use a keystore located inside the JAR file, and I'm very tempted just to disable certificate validation all together using the method here. However, before I do so, I just wanted to confirm why you should not do this and whether those reasons actually apply to me.
I've heard that no certificate validation can make your application liable to "Man In The Middle" attacks (I think), but even if I am correct, I am unsure as to what these actually are so please could somebody explain. Though, if they are what I think they could be, I'm not sure whether my application ever be subject to them because, my application only uses an SSL connection to obtain data from my website, so users do not tell the application which URLs to visit - if that makes sense...
Here's, an attack scenario. Other's might want to contribute some more.
Your application accesses a URL. At some point along the way (any intermediate network hop), an attacker could position himself as a "man-in-the-middle", that is, he would pretend to be a "proxy" for your communication, being able to read everything that goes through, and even modifying it on the way: the attacker could act on behalf of the user, mislead him as to what information he gets, and basically access al data being transferred.
Enter SSL: your client receives a certificate from the server, with a valid key (Signed by a known certification authority, or present in your keystore). The server will then sign and encrypt all it sends using that key. If an attacker where to place himself in the middle, he would not be able to read the data (it's encrypted) or modify it (it's signed, and modification would break the signature). He could still block communications altogether, but that's another story.
So that's that... if you ignore your keystore, you can't verify any server side certificate, and you open the door to man-in-the-middle attacks.
Though, if they are what I think they could be, I'm not sure whether
my application ever be subject to them because, my application only
uses an SSL connection to obtain data from my website, so users do not
tell the application which URLs to visit - if that makes sense...
If you connect to a server via SSL and you don't do any authentication, effectively you are have no security.
You have no idea who is the endpoint you are talking to.
The fact that the user does not type in a URL, but the URL is a hardcoded URL to your site is irrelevant. A simple proxy that forwards the data from your client to the server can steal all your client's data since there is no kind of authentication (this is the Man in the Middle Attack).
I would suggest you put the code you are using to load the keystore so that you get help on that.
Otherwise, if you don't have any requirements on security and you don't have any sensitive data you should go for plain connection (i.e. non-SSL) so that your performance does not deteriorate due to the unecessary (in your case) SSL overhead
I am writing a web service that handles financial data which needs to be protected. Currently, I am developing and debugging the service but start to think of the production environment.
It is possible to log the sent payload --- the financial data --- for debugging purposes. This is the only way for me to see whats going on as a developer. The log information is written to a log file with java.util.logging.
Do you have an idea how I could encrypt the log file? Or do you have any suggestions how to make this secure?
I think rather than encrypting the entire file you could just encrypt the sensitive data, while keeping the other logging information intact. In this case you may need to create decrypting program as well.
Or better if possible when logging the data just mask it (like credit card numbers are masked using X character) so that it will be impossible to decrypt but the developer will be able to have an idea about what happened there. As per S.L. Barth's answer you could use built in encryption to do the encrypting.
Java has built-in encryption facilities; the javax.crypto packages.
However, you probably don't want the logfiles themselves encrypted, you only want them to be encrypted when you send them over the net.
In which case, you should look for software for securely sending information; for example, a VPN.
EDIT: your problem is actually addressed in the Java tutorials.
From the looks of it, though, their example is vulnerable to a Man-In-The-Middle attack, as it does not seem to verify the origin of the sender like SSL/TLS does. So, I would recommend a VPN or other piece of third party software for secure transmission.