A security audit at our company found that the prefix of our bcrypt hashes are "$2a$". According to [1] and [2] this could indicate that an older, vulnerable bcrypt implementation is used.
So - here my questions:
Does Spring Security's bcrypt implementation contain the vulnerability?
Does Spring Security support the "$2x$" and "$2y$" prefixes?
References:
[1] http://blog.ircmaxell.com/2012/12/seven-ways-to-screw-up-bcrypt.html
[2] http://www.openwall.com/lists/oss-security/2011/06/21/16
The links you provide is about a vulnerability in the C implementation of BCrypt. The Spring Security implementation is a fork of jBCrypt, which is a different implementation written in Java.
Looking at the source code, as of version 3.2.5, Spring Security doesn't support "$2x$" and "$2y$" prefixes. The implementation does not contain the C vulnerability but it is not inter-operable with current C based implementation (like PHP).
Related
As spring-security-oauth2 obsoleted ref: EOL for Spring Security OAuth,
cannot use #oauth2.hasScope([scope]) in xml config provided by OAuth2SecurityExpressionMethods.java
Expected to see ast parser or similar handler in either spring-security-oauth2-jose, spring-security-oauth2-client, spring-security-oauth2-core to accomplish that in the following example, #oauth2 security expressions on method level.
Is there something i missed for xml config for oauth2 scope checking?
Or i must implement it by hasAuthority('SCOPE_[scope]')
thanks
have to switch to hasAuthority("SCOPE_scope")
Spring Security converts scopes that follow the granted authority naming convention
ref: OAuth 2.0 Migration Guide
I have a web application that was built on Spring Security 4.2.17 and uses Md5PasswordEncoder. I plan to upgrade it to Spring Security 5.3.3.RELEASE. I understand that Md5PasswordEncoder is removed from Spring Security 5.x. Let's put aside the strength of the MD5 algorithm. I would like to continue to use it, the exactly same way of how MD5 works in Spring 4.x. Here is how I use Md5PasswordEncoder in the app based on Spring Security 4.2.17:
Md5PasswordEncoder passwordEncoder = new Md5PasswordEncoder();
String encryptedPassword = passwordEncoder.encodePassword(plainTextPassword, salt);
I understand that in Spring Security 5.x, I can continue use MD5 in this way (I understand it is deprecated)
MessageDigestPasswordEncoder passwordEncoder = new MessageDigestPasswordEncoder("MD5");
However, I don't see a way to add the "salt" in encryption because this class (MessageDigestPasswordEncoder) does't seem to use "salt" the same way as in Spring 4.x.
I have Rest API which require authentication. The application is completely written in java. Is there any libraries present for oauth server side implementation for Rest API ?
I have already checked the spring ouath2 security but I am not sure about the support towards Jersey library as I am using it for development. Can you suggest libraries or documentation for ouath authentication in java
Spring Security appears to be the only framework that provides complete implementation for Oauth 2.0 specifications. Spring supports almost all of JAX-RS implementations (including Jersey).
You might need to tweak these Jersey properties to suit your needs.
Check out this known customization required when using Jersey.
Spring Security OAuth 2.0 developer guide.
The Spring Security – Kerberos Extension is listed as version 1.0M2 on the Spring Source web site. It was started in 2009.
Why hasn't it made a 1.0 release?
Is it suitable for production use?
If it is not suitable for production use, what is the best alternative to plug into Spring Security?
We use successfully Spring Security Kerberos/SPNego in production since more than one-year, and we are quite happy with it!
However, I can't say why 1.0 is not released.
I'm currently working on a project running on JBoss AS 7 that requires authentication from a variety of sources. I'm trying to get an understanding of the various components that combine to provide authentication.
I have some assumptions / guesses as to how this all fits together, but I need to make sure that my understanding is correct. So below is what I understand to be the authentication process for JBoss AS7.
You have a security realm that defines how users are authenticated. This realm is then exposed to your application in order to secure some or all of it. In AS7 this is configured in the <subsystem xmlns="urn:jboss:domain:security:1.0"> element.
The realm can be configured to authenticate users against a variety of sources using login-modules, such as a database, LDAP, a local file or something else. Multiple login-modules can be defined, and you can specify some combination of login-modules must "succeed" in order for authentication to occur.
The actual username and passwords are passed in via a mechanism defined in the web.xml file (for servlets), defined in the <login-config> element.
Assuming that the above process is correct (and it may not be):
Does this whole authentication process fall under a specification like JAAS, or is JAAS just a small or optional part of this procedure?
Do all types of <auth-methods>'s (i.e. BASIC, DIGEST and FORM) work with all kinds of login-modules? This page would seem to suggest not, but I haven't seen any clear documentation matching <login-module> options <login-config> options.
The username and password flow from a login-config to a login-module seems straight forward enough, but what happens with systems like OpenID or OAuth where there are intermediary steps (like redirection to external login pages)?
How do projects like Seam 3 Security, Apache Shiro and Spring Security fit into this picture?
JavaEE security specification leaves a lot of space to container implementors so I will focus on JBoss implementation to answer.
JBoss security implementation
JBoss relies on JAAS authentication to implement JavaEE security. That way it takes benefits from a stable API and can use existing LoginModule implementations. Login modules are used to authenticate a subject but also to add roles to Subject. JAAS provides mechanisms for authorization, permission checking and JBoss uses it internally.
JAAS LoginModule does not only supports password-based authentication but also token-based authentication.
Token based authentications
A good example of what can be done in JBoss thanks to JAAS is the HTTP Negotiation support for Kerberos SPNEGO: an additional auth-method named SPNEGO is implemented thanks to a Tomcat Authenticator and token validation uses JavaSE standard Kerberos LoginModule.
By the way, the LoginModule API is not a requirement, it may even be too complex for some protocols. For instance, the implementation to support OpenID with PicketLink only uses Servlet API.
Third party security libraries
These libraries often provide security layers to an application running a JavaEE or pure Java context, even if it does not take benefits from JavaEE specifications for authentication or role-based authorization.
Spring Security provides other abstractions than JavaEE security for applications developers to implement authentication and authorization, mainly thanks to ServletFilter when a web application is concerned. A large panel of choices is available to secure his application: it is possible to mix multiple options like: JAAS usage, JavaEE container security usage or Spring Security specific implementations (the case of OpenID and OAuth). There is no dependency to JavaEE either so it may be use almost in any situation when running on JavaSE. Most architect choose to build application security on Spring Security to have the liberty to switch specific implementations in the future.
Apache Shiro is really similar to Spring Security but it is younger and probably easier to set up.
Seam security does not rely on JavaEE security or JBoss but only on Servlet and JSF APIs. It is obviously the easiest option for JSF/Seam-based web application. Behind the scene, it uses PicketLink implementations.
As a conclusion, the question to use third party libraries in addition or in replacement to JavaEE security depends on architectural choices: application complexity, vendor independence and portability, control on implementations for bug fixes or improvements. In your specific context, having multiple authentication sources requires a flexible solution like Spring Security which supports authentication provider chaining (or Shiro).