Is my glassfish 4.1 realm secure enough ? if not, what’s wrong with it

[Mehdii Hafid]

First JPA Entities:

@Entity
@Table( name = "USER")
public class User implements Serializable {

	private static final long serialVersionUID = 1L;
	
	@Id
	private String email;

	private String password;
	
	@Column(name = "RAW_PASSWORD")
	private String rawPassword;

	@OneToMany
	@JoinTable(name = "USER_GROUP_JOIN", joinColumns = @JoinColumn(name = "USER_ID"), inverseJoinColumns = @JoinColumn(name = "GROUP_ID"))
	private List<UserGroup> userGroups;
}	 
@Entity
@Table(name = "USER_GROUP")
public class UserGroup implements Serializable {
	private static final long serialVersionUID = 1L;

	@Id
	@Column(name = "GROUP_ID")
	private int groupId; // 5
}

Tables with data:
USER

USER_GROUP

USER_GROUP_JOIN

Java EE 7 / Glassfish Security Realm:
Realm Name: QTubeRealm
Class Name: com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm

JAAS Context:   jdbcRealm
JNDI:   jdbc/qtube
User Table:   qtube.user
User Name Column:   EMAIL
Password Column:   PASSWORD
Group Table:   qtube.user_group_join
Group Table User Name Column: USER_ID
Group Name Column:   GROUP_ID
Password Encryption Algorithm:   none
Assign Groups:
Database User:
Database Password:
Digest Algorithm: SHA-256
Encoding:
Charset:

web.xml

<login-config>
		<auth-method>FORM</auth-method>
		<realm-name>QTubeRealm</realm-name>
		<form-login-config>
			<form-login-page>/loginAdv.xhtml</form-login-page>
			<form-error-page>/loginAdv.xhtml</form-error-page>
		</form-login-config>
	</login-config>
	<security-role>
		<role-name>User</role-name>
	</security-role>

glassfish-web.xml

<glassfish-web-app>
	<context-root>/qtube-ee8-v1</context-root>
	<security-role-mapping>
		<role-name>User</role-name>
		<group-name>5</group-name>
	</security-role-mapping>
</glassfish-web-app>

User Account Creation:
CDI Bean: create, login, logout methods

@Named
@RequestScoped
public class RegisterAdvanced extends BaseBacking implements Serializable {
	private static final long serialVersionUID = 1L;

	private static final String LOGIN_PAGE = "/loginAdv.xhtml?faces-redirect=true";
	private static final String REDIRECT_PAGE = "/redirect.xhtml?faces-redirect=true";
	private static final String LOGIN_ATTEMPT_REACHED = "/loginAttemptError.xhtml";

private String email;
	private String password;

	@EJB
	private UserDao userDao;

	@EJB
	private LoginAttemptDao loginAttemptDao;

	public RegisterAdvanced() {

	}

	public String createUser() {

		System.out.println("Creating new user");
		User user = new User();
		user.setEmail(email);
		user.setRawPassword(password);
		user.setPassword(PasswordHashing.encrypt(password));
		try {
			System.out.println(user.getEmail() + "\t" + user.getPassword());
			userDao.createUser(user); // sets user.getUserGroups().add(userGroup);		
} catch (UserAlreadyExists ex) {
			System.out.println("caught : UserAlreadyExists");
			getContext().addMessage("email", new FacesMessage("Email already in use"));
			return null;
		} catch (Exception ex) {
			ex.printStackTrace();
			getContext().addMessage("email", new FacesMessage("Error, try again"));
		}

		return LOGIN_PAGE;
	}

	public void login() throws IOException {
		try {
getRequest().login(email, password);
			User currentUser = null;
			try {
				currentUser = userDao.find(email);
				currentUser.setPassword("");
			} catch (Exception e) {
				System.out.println("Exception is thrown, user : " + currentUser);
				e.printStackTrace();
			}
			getContext().getExternalContext().getSessionMap().put("user", currentUser);
			getContext().getExternalContext().redirect(getContext().getExternalContext().getRequestContextPath() + REDIRECT_PAGE);

			// Successful Login
			
			getRequest().changeSessionId();
		} catch (ServletException e) {
			// Handle unknown username/password in request.login().
			getContext().addMessage(null, new FacesMessage("email/password combination not valid, try again"));
		}
	}

	public String logout() {
		try {
			getRequest().logout();
			getContext().getExternalContext().getSessionMap().remove("user");
			return LOGIN_PAGE;
		} catch (ServletException ex) {
			return "/redirect.xhtml?faces-redirect=true";
		}
		
	}
}

Util Class: PasswordHashing

public class PasswordHashing {
	
	public static String encrypt(String text){
		String encryptedPassword = null;
		try {
			MessageDigest md = MessageDigest.getInstance("SHA-256");
			md.update(text.getBytes("UTF-8"));
			byte[] digest = md.digest();
			encryptedPassword = String.format("%064x", new BigInteger(1, digest));
		} catch (NoSuchAlgorithmException | UnsupportedEncodingException e) {
			e.printStackTrace();
		}
		System.out.println("encryptedPassword " + encryptedPassword);
		return encryptedPassword;
	}

Can you please show me what’s wrong with my implementation?
I want to use AES instead of SHA-256. How can I do that?
And if you there is books, articles that cover this particular subject (realm in glassfish 4), please give me the links. Because I searched and found nothing.
Note: I know Java EE 8 has a new Security API, however I want to learn glassfish 4.1 first.
Thanks.

[Tim Moores]

AES is an encryption algorithm, whereas SHA is a hashing algorithm - you can't substitute one for the other. Why do you want to? SHA-256 is state of the art, although you could use SHA-512 instead.

[Mehdii Hafid]

Tim Moores wrote:

I know the difference. I need the right config/code plus I want to use AES.

[Tim Moores]

I know the difference. I need the right config/code plus I want to use AES.

If you know the difference then you should understand why this is not possible. Whether or not you want to use AES is therefore irrelevant.

As an aside, why do you think that there's something wrong with your implementation? In which way?

[Mehdii Hafid]

I don't know if my config & code is the right implementation that's why I'm asking. Thanks for your help though.

this is off-topic, but Can you check my sent box. because I'm having trouble a thread I posted, I contacted  Campbell Ritchie https://coderanch.com/forums/user/profile/109202 . He did not get back to me yet.
my message link: https://coderanch.com/forums/pm/read/1128146/false
If you want to, I can post the content of it here.

[Tim Holloway]

Item #1: If you're using a J2EE security Realm, you don't write your own login/logout logic. The J2EE and JEE standards consider the login process to be the server's job, not the application's job, and the login code is already written, secured, and debugged as part of the original server software installation. All you do is provide the forms that the server will present when a need for login is detected. These forms should be basic JSPs or HTML forms, NOT JSF, Struts, or some other page that requires routing through a dispatching servlet, since the server does logins external to the webapp and its servlets.

On a related note, you do not log in a user by using the login form as a URL. The login form is automatically presented by the server whenever an attempt is made by a non-logged user to attempt a secured URL (as defined in the security URL patterns in web.xml). If you invoke the login form directly, it will not work, because the j_security context hasn't been set up properly. Only the server can do that and it will only do so when it's actually trying to authenticate someone.

Item #2: One of the two fundamental axioms of JavaServer Faces is that Request Scope in JSF is almost 100% useless. Most of the time it will just get you into trouble, so it's better to avoid it altogether.

[Matt Wong]

neither I understand the topic nor read it - BUT: you're saving raw, un-hashed/-ecrypted, plain-text credentials in your database - NOPE! It's this point you're doing it wrong. NEVER, under any circumstances, save private credentials in plain-text!

passphrases should always be hashed with a salt - so that even two users choose same password it creates different hashes when random salts are used.

also, as already asked: why you want to change hashing with encryption? AES would allow you to securely store the passphrases in encrypted form - but to use them you either have to decrypt them - or encrypt user input and compare - this means: you have to store the AES-key somewhere - and if you do this - you most likely end up same key and IV on more than one dataset - wich breaks AES as you can then compute key an IV from two datasets wich uses same values - same as saving the key right next to the encrypted passphrase - wich, when leaked, is same as saving plaintext


correct way to do: challenge-response:

when a user registers, you randomly generate a salt - concat it with the passphrase the user chose and save the salt an hash in database
when a user wants to login - you generate a session nounce - send it to the client - and the client then have to perform some hashing based on its passphrase and the given nounce - and reply back - you're donin same on server side and compare results - if they match - user proven knowledge of phrase - or at least something generating same hash - wich, with sha256, takes 32 bytes of input to find a collision - larger than most passphrases - therefor pretty much secure - without the real passphrase ever is transmitted - and so it can'T cought on mitm - and session nounce denies replay-attacks

[Tim Holloway]

I'm going to qualify my previous statement.


It's true that JEE Container-managed security does the actual login, but a major change between J2EE and JEE was that addition of an API method that permits program logic to internally invoke the container login instead of always depending on a URL request to invoke login. That makes it convenient if you're the type that likes to put an explicit Login button on application web pages.

You can put a mini-form on a page that way with a login button and userid/password fields. Although if you must allow credentials on that mini-form, I highly recommend you keep them in a separate backing bean. Because credentials SHOULD be wiped between attempts, you MIGHT even be able to do that in Request Scope.

But assuming that that's what this particular example is all about, it's annoying to me for 3 reasons.

o First and most fatally, it's combining authentication AND user identity maintenance in the same bean. That raises your security exposure and complicates the bean. Better to have a separate bean for identity maintenance.

o Secondly, it has database logic in the View Model (backing bean). I realize that having more components can offend, but it's really better if the backing bean concentrates ONLY on the view and delegates the business logic and persistency to a business bean. In fact, I generally go one further and have the persistency in a separate bean from the business logic as well, but that depends on how complex things are.

o Thirdly, the bean is far too knowledgeable about HTTP and JSF internals. I prefer to include a bean called JSFUtils in my JSF webapps. Its exact makeup tends to vary, but basically, it's an abstraction where I put stuff like direct access to the scoped objects (which should mostly be avoided in favor of JSF injection), security role checking, cookies, and posting of JSF error messages. The advantage here is that since it's plug-replaceable, I can switch it for a mock bean and do offline unit testing of my backing beans. And, of course, it insulates them from potential future changes in JSF itself.

[Mehdii Hafid]

Matt Wong
Do you recommend a book that explains what you have talk about in detail, preferably in Java?
Thanks for your input.

Tim Holloway
Thanks for your input,
I'm actually very happy with my design. Having programmatic sign up, login, logout in the
same Bean is OK .So I don't see the point of separating
login, logout and sign up.

If you're talking about moving this code:

User user = new User();
		user.setEmail(email);
		user.setRawPassword(password);
		user.setPassword(PasswordHashing.encrypt(password));
		try {
			userDao.createUser(user);

to userDao EJB, you're right (this part was the first I wrote, and at the time I needed
to get it up and running ASAP, an update is due soon). However this is an exception
because all of my code is placed at the right place.

"Thirdly, the bean is far too knowledgeable about HTTP and JSF internals."
is that supposed to be a bad thing? my application is monolythic not a micro service.
so the fact that my CDI bean plays perfectly with JSF is a requirement in my case.

[Tim Holloway]

Users may be confused about what I'm answering here, because the previous ghost was posted while Mehdii resolves differences with the Ranch administration, but I feel like it's important that everyone should know the answers to these questions:

Mehdii Hafid wrote:
I'm actually very happy with my design. Having programmatic sign up, login, logout in the
same Bean is OK .So I don't see the point of separating
login, logout and sign up.

Authentication and user registration are two very different things. For example, when you authenticate, you don't write to the database, whereas by definition when you "sign up" you are writing, By placing these two functions in the same module, you have made it so that if an attacker can subvert the login code, that person has a direct route to the user administration services and can thereby potentially wreak major havoc.

A really secure system wouldn't even have the user administration functions in the same webapp, but would hand over control to a different app so that the primary app could use a database connection that had fewer security rights than the app that managed user accounts did.

Aside from that, when you're using J2EE container security, the webapp doesn't need a database connection to the user credentials at all. That's handled by the Realm. So you're adding database connectivity to an otherwise innocent module.

Mehdii Hafid wrote:

Tim Holloway wrote:Thirdly, the bean is far too knowledgeable about HTTP and JSF internals.

is that supposed to be a bad thing?

Yes it is.

1. JSF is designed to be a JavaBeans-oriented framework that does most of its work by Inversion of Control. In short, an "ideal" JSF backing bean is so generic that you can reuse the entire bean in a non-web application. Failing that, at a minimum you should avoid coding any references to resources that aren't in the javax.faces.model packages wherever possible.

2. As I mentioned previously, not using resources that are only available in a live webapp server (HTTP and JSF) means that you can unit-test the bean offline. This saves a lot of development time (== money) and makes maintenance simpler.

3. The JSF internals have already undergone major changes in times past. There are definitely some things I'd like to see fixed in some future version of JSF. By abstracting the functions that only JSF or J2EE can provide to an external support module, it's possible to "future proof" the bean code. It's a lot easier (== less time/money) to change interfaces in my JSFUtils module than it would be to have to hunt down and change every JSF backing bean that used JSF or J2EE internal services.

Consider this: Struts was an early attempt to create a Model/View/Controller framework in J2EE for the web. Struts required developers to implement certain interfaces and to subclass certain classes. Objects designed for Struts were useless outside of Struts and changes to Struts required changes to otherwise innocent application code. The creators of Struts realized that this was expensive and painful and quite a few of them were later part of the group that designed JSF. The pain that they had suffered is why JSF is based on POJOs and not specialized classes. JSF does have some specialized classes, of course, such as custom validators, but these are adjuncts to the JSF Controllers. not part of the application's core UI and business functionality.

Actually, the initiall design for JSF not only didn't assume that only HTML was an option (back then, cheaper smartphones didn't use HTML), but JSF also didn't assume that it would only be used for webapps or even on the Internet. They had more of a portable GUI platform in mind that could work in places where the Java desktop GUI systems like AWT and Swing didn't apply. It's only that in actual practice that web and HTML are the primary uses for JSF, and you never know - someday that may change. After all, who uses Gopher on the Internet anymore?