We're in the middle of developing a e-commerce application that will be used by our customers on a pay-monthly-plan.
We have thought a bit about offering encryption of all personal data that is stored in the database, to make our application a notch safer to the final consumers.
The encryption would be handled completely transparent in both front and backend and make sure that even if someone would gain pure database access, it would be impossible to decrypt the personal details of the final consumers without the encryption key.
Is this common sense, or are we taking on a too big bite to chew compared to the increased safety this would add to the final customers?
I might be out of my depth here, as I'm not a security expert, but here's a few questions that come to mind:
What are the chances of an attacker gaining access to the data?
Does the data contain anything confidential?
What could an attacker stand to gain from accessing the data?
What could you, or your company, stand to lose if an attacker gained access to the data? It's not just the data, it's potentially your reputation too.
How much will it cost to implement?
What are your legal obligations with regard to customer data?
If data are encrypted using a single global key, how will you keep the key safe?
If the key is really safe, how will you use it to encrypt and decrypt data?
If data are encrypted using multiple keys (perhaps one for each customer login), how will you recover data if a customer loses their key/password?
If you are able to recover customer data, how does that affect its safety?
What access will computer repair technicians, sysadmins, etc., have to your database server, and how will that affect data security? (It's not just about external hackers).
What are the performance effects of encryption and decryption?
What other mechanisms, like firewalls, physical security and employee vetting can be put in place?
Here's a quote from the UK FSA Your responsibilities for
customer data security (pdf):
Getting data protection wrong can
bring commercial, reputational,
regulatory and legal penalties.
Getting it right brings rewards in
terms of customer trust and
confidence.
My answer is: Sometimes. I've worked for a few companies that employ e-commerce solutions. Security and Encryption need to be better than what the information is worth. Names and address not as "valuable" than say credit card numbers and transaction information. The setup I'm most familiar with is one where all general CRM data - names, address, etc - that is typically fetched more frequently are stored on servers databases - plain text - and the security for the server is increased (Firewalls, patches, etc) and the script accessing the database is of course - secured to the best of the developers knowledge.
Credit card, transaction information, the real down and dirty "information people would want to steal" was contained on a server - encrypted, secured, and only available via local lan. The encryption key was on a second server access to these machines was dictated by a rotating authentication key that only a third server knew. The two key/data servers were unaware of each other. When purchases were made the third server - accessed by a forth - would "magically" make it all come together to complete the purchase.
It's a very convoluted, and terrible answer. In short - protecting/encrypting the very sensitive data is a must is you wish to ensure your customers protection from theft - but ALL information may be an unnecessary overhead for your application. Security is only worth what the data is worth to the thief.
Doing this you lose many of the relational database advantages (searches, reports for the business intelligence and so on).
Furthermore, if you store the keys you just add a layer of 'security': an attacker will have to obtain the keys in order to read the data, but if he has full access to your database, he probably has access to the keys' repository, too (as must have access to that repository the frontend and backoffice applications).
If you instead give the users the responsibility to store their own keys, you lose the possibility to restore the data in case an user lose his key.
Get the real sensible information, put it in a separate server, put as much security as possible around it and acces the data only when needed.
In my opinion the main threat of your approach will be the (false) sense of security that the encryption will give. Sensible data must be treated with all the due caution in storing, but also during elaboration and use: put your money in good system administrators, prepared software engineers and periodical security assessments, if your business require.
Why is it safer?
You need to store the decrpytion key in order to provide that data to the user - it's not really relevant that its only held in the 'front-end' system - in order to get to the back end a hacker must get through the front end first.
You also eliminate a LOT of the searching functionality.
You have to do a lot of coding to imlpement this.
You're placing much heavier demands on the system (i.e. more hardware cost, poorer performance).
IMHO your money and time would be better spent on improving security elsewhere.
C.
Related
I am developing a SAAS service that allows my clients to connect third party emailing tools (eg MailChimp). I therefore ask to enter their API key associated with the desired service to allow certain actions to be performed automatically on their account.
For that I record in their database their key (s) API and the connection is done. But from a security point of view, if my database comes to be hacked despite all the predispositions taken in terms of security (prepared requests etc) ... These are all the API keys of my clients that are revealed and also email addresses of their own customers that can be retrieved, used, resold ... Because the tools I connect essentially allows to store contacts, organize and send emails.
So I wonder what is the best practice to allow my clients to use the API of their favorite tools without endangering the security of their own accounts and data of their customers (emails, etc). I am aware that currently launching my web application with this data in clear in database would be dangerous.
I thought of several solutions:
Encrypt API keys in database, but I do not see how to test them (decryption) since it's not like a password?
Store API keys on a different database hosted elsewhere, but the problem of encryption remains the same ... no?
Use an OAuth stream: it seemed to be convenient, but all the services I want to connect via API do not offer this and I'm not even sure that this is really suitable for me.
I intend to host my SAAS on Amazon web services, I saw that it was proposing a service called "KMS" Key managament storing but I do not know if it is really adapted once again to my problematic ...
If someone has already had to answer this problem, or knows how to solve it, I want to be enlightened on it!
Note: Sorry for my bad english, i'm French.
All of the solutions you mentioned are somewhat valid and a combination is most likely the best answer. Your application needs access to these API keys so it's not really possible for a hacker to gain full control of your application and not gain control to the API keys. Full control being the key part - you can make it a lot harder to get to them.
Encryption
You would need encrypt them, not hash them, with something like AES. As you need to be able to decrypt them and use them in your requests towards the 3rd parties. This will help you protect against, eg. a database leak - if someone gets your database they would have to crack the encryption to get to them (as long as the encryption is properly implemented). The encryption/decryption key would of course have to be NOT in the database otherwise the whole thing has no point :)
Separation
Different database also makes sense - if someone dumps your main database they won't get to the API keys database and would have to get deeper into the application to access this database (ideally would be a completely separate DB server only accessible from your application).
Architecture of the solution matters too - you can have one server posing as a web-interface that is internet facing and that would talk to the backend server that is not internet facing over some limited (as much as possible) API to lower the attack surface. Only the backend server would then have access to the keys database and would perform the requests to the 3rd parties. Now an attacker has to jump through several servers to get even close to the keys.
Combining the above-mentioned will ensure one would have to obtain full control of your application (and all its parts) to get to the keys, the encryption key and bypass whatever other protection you might put in place.
I have a php/js site where the information is encoded and put into the database. The encryption key for the information is randomly generated, then given back to the users after they send a post through a form. The encryption key is not stored in my database at all. A seperate, randomly generated, ID is formed and stored in the database, used to lookup the item itself before deciphering it.
My question is, is it possible at all to look through the logs and find information that would reveal the key? I am trying to make it impossible to read any of the SQL data without either being the person who has the code (who can do whatever he wants with it), or by a brute force attack (unavoidable if someone gets my SQL database)?
Just to re-iterate my steps:
User sends information through POST
php file generates random ID and access key. The data is encrypted with the access key then put in the php database with the ID as the PRIMARY KEY.
php file echos just the random ID and the access key.
website uses jQuery to create a link from the key and mysite.com?i=cYFogD3Se8RkLSE1CA [9 digit A-Ba-b09 = ID][9 digit A-Ba-b09 = key]
Is there any possibility if someone had access to my server that can read the information? I want it to be information for me to read the messages myself. The information has to be decodable, it can't be a one way encoding.
I like your system of the URL containing the decryption key, so that not even you, without having data available only on the user's computer, will be able to access.
I still see a few gotchas in this.
URLs are often saved in web server logs. If you're logging to disk, and they get the disk, then they get the keys.
If the attacker has access to your database, he may have enough access to your system to secretly install software that logs the URLs. He could even do something as prosaic as turn logging back on.
The person visiting your site will have the URL bookmarked at least (otherwise it is useless to him) and it will likely appear in his browser history. Normally, bookmarks and history are not considered secure data. Thus, an attacker to a user's computer (either by sitting down directly or if the computer is compromised by malware) can access the data as well. If the payload is desirable enough, someone could create a virus or malware that specifically mines for your static authentication token, and could achieve a reasonable hit rate. The URLs could be available to browser plugins, even, or other applications acting under a seemingly reasonable guise of "import your bookmarks now".
So it seems to me that the best security is then for the client to not just have the bookmark (which, while it is information, it is not kept in anyone's head so can be considered "something he has"), but also for him to have to present "something he knows", too. So encrypt with his password, too, and don't save the password. When he presents the URL, ask for a password, and then decrypt with both (serially or in combination) and the data is secure.
Finally, I know that Google's two-factor authentication can be used by third parties (for example, I use it with Dropbox). This creates another "something you have" by requiring the person accessing the resource to have his cell phone, or nothing. Yes, there is recourse if you lose your cell phone, but it usually involves another phone number, or a special Google-supplied one-time long password that has been printed out and stashed in one's wallet.
Let's start with some basic definitions:
Code Protecting data by translating it to another language, usually a private language. English translated to Spanish is encoded but its not very secure since many people understand Spanish.
Cipher Protecting data by scrambling it up using a key. A letter substitution cipher first documented by Julius Caesar is an example of this. Modern techniques involve mathematical manipulation of binary data using prime numbers. The best techniques use asymmetric keys; the key that is used to encipher the data cannot decipher it, a different key is needed. This allows the public key to be published and is the basis of SSL browser communication.
Encryption Protecting data by encoding and/or enciphering it.
All of these terms are often used interchangeably but they are different and the differences are sometimes important. What you are trying to do is to protect the data by a cipher.
If the data is "in clear" then if it is intercepted it is lost. If it is enciphered, then both the data and the key need to be intercepted. If it is enciphered and encoded, then the data, the key and the code need to be intercepted.
Where is your data vulnerable?
The most vulnerable place for any data is when it is in clear the personal possession of somebody, on a storage device (USB, CD, piece of paper) or inside their head since that person is vulnerable to inducement or coercion. This is the foundation of Wikileaks - people who are trusted with in confidence information are induced to betray that confidence - the ethics of this I leave to your individual consciences.
When it is in transit between the client and the server and vice versa. Except for data of national security importance the SSL method of encryption should be adequate.
When it is in memory in your program. The source code of your program is the best place to store your keys, however, they themselves need to be stored encrypted with a password that you enter each time your program runs (best), that is entered when you compile and publish or that is embedded in your code (worst). Unless you have a very good reason one key should be adequate; not one per user. You should also keep in-memory data encrypted except when you actually need it and you should use any in-memory in-clear data structures immediately and destroy them as soon as you are finished with them. The key has to be stored somewhere or else the data is irrecoverable. But consider, who has access to the source code (including backups and superseded versions) and how can you check for backdoors or trojans?
When it is in transit between your program's machine and the data store. If you only send encrypted data between the program and the data store and DO NOT store the key in the data store this should be OK.
When it is stored in the data store. Ditto.
Do not overlook physical security, quite often the easiest way to steal data is to walk up to the server and copy the hard drive. Many companies (and sadly defence/security forces) spend millions on on-line data security and then put their data in a room with no lock. They also have access protocols that a 10 year old child could circumvent.
You now have lovely encrypted data - how are you going to stop your program from serving it up in the clear to anyone who asks for it?
This brings us to identification, validation and authorisation. More definitions:
Identification A claim made by a person that they are so-and-so. This is usually handled in a computer program by a user name. In physical security applications it is by a person presenting themselves and saying "I am so-and-so"; this can explicitly be by a verbal statement or by presenting an identity document like a passport or implicitly by a guard you know recognising you.
Validation This is the proof that a person is who they say they are. In a computer this is the role of the password; more accurately, this proves that they know the person they say they are's password which is the big, massive, huge and insurmountable problem in the whole thing. In physical security it is by comparing physical metrics (appearance, height etc) as documented in a trusted document (like a passport) against the claim; you need to have protocols in place to ensure that you can trust the document. Incidentally, this is the main cause of problems with face recognition technology to identify bad guys – it uses a validation technique to try and identify someone. “This guy looks like Bad Guy #1”; guess what? So do a lot of people in a population of 7 billion.
Authorisation Once a person has been identified and validated they are then given authorisation to do certain things and go to certain places. They may be given a temporary identification document for this; think of a visitor id badge or a cookie. Depending on where they go they may be required to reidentify and revalidate themselves; think of a bank’s website; you identify and validate yourself to see your bank accounts and you do it again to make transfers or payments.
By and large, this is the weakest part of any computer security system; it is hard for me to steal you data, it is far easier for me to steal your identity and have the data given to me.
In your case, this is probably not your concern, providing that you do the normal thing of allowing the user to set, change and retrieve their password in the normal commercial manner, you have probably done all you can.
Remember, data security is a trade off between security on the one hand and trust and usability on the other. Make things too hard (like high complexity passwords for low value data) and you compromise the whole system (because people are people and they write them down).
Like everything in computers – users are a problem!
Why are you protecting this data, and what are you willing to spend to do so?
This is a classic risk management question. In effect, you need to consider the adverse consequences of losing this data, the risk of this happening with your present level of safeguards and if the reduction in risk that additional safeguards will cost is worth it.
Losing the data can mean any or all of:
Having it made public
Having if fall into the wrong person’s hands
Having it destroyed maliciously or accidently. (Backup, people!)
Having it changed. If you know it has been changed this is equivalent to losing it; if you don’t this can be much, much worse since you may be acting on false data.
This type of thinking is what leads to the classification of data in defence and government into Top Secret, Secret, Restricted and Unrestricted (Australian classifications). The human element intervenes again here; due to the nature of bureaucracy there is no incentive to give a document a low classification and plenty of disincentive; so documents are routinely over-classified. This means that because many documents with a Restricted classification need to be distributed to people who don’t have the appropriate clearance simply to make the damn thing work, this is what happens.
You can think of this as a hierarchy as well; my personal way of thinking about it is:
Defence of the Realm Compromise will have serious adverse consequences for the strategic survival of my country/corporation/family whatever level you are thinking about.
Life and Death Compromise will put someone’s life or health in danger.
Financial Compromise will allow someone to have money/car/boat/space shuttle stolen.
Commercial Compromise will cause loss of future financial gain.
Humiliating Compromise will cause embarrassment. Of course, if you are a politician this is probably No 1.
Personal These are details that you would rather not have released but aren’t particularly earth shaking. I would put my personal medical history in here but, the impact of contravening privacy laws may push it up to Humiliating (if people find out) or Financial (if you get sued or prosecuted).
Private This is stuff that is nobody else’s business but doesn’t actually hurt you if they find out.
Public Print it in the paper for all anyone cares.
Irrespective of the level, you don’t want any of this data lost or changed but if it is, you need to know that this has happened. For the Nazi’s, having their Enigma cipher broken was bad; not knowing it had happened was catastrophic.
In the comments below, I have been asked to describe best practice. This is impossible without knowing the risk of the data (and risk tolerance of the organisation). Spending too much on data security is as bad as spending too little.
First and most importantly, you need a really good, watertight legal disclaimer.
Second, don’t store the user’s data at all.
Instead when the user submits the data (using SSL), generate a hash of the SessionID and your system’s datetime. Store this hash in your table along with the datetime and get the record ID. Encrypt the user’s data with this hash and generate a URL with the record ID and the data within it and send this back to the user (again using SSL). Security of this URL is now the user’s problem and you no longer have any record of what they sent (make sure it is not logged).
Routinely, delete stale (4h,24h?) records from the database.
When a retrieval request comes in (using SSL) lookup the hash, if it’s not there tell the user the URL is stale. If it is, decrypt the data they sent and send it back (using SSL) and delete the record from your database.
Lets have a little think
Use SSL - Data is encrypted
Use username/password for authorisation
IF someboby breaks that - you do have a problem with security
Spend the effort on fixing that. Disaster recover is a waste of effort in this case. Just get the base cases correct.
We have to be sure that this temporary data will be persistent and that deletion is compliant with the DoD's security standards (wiping data on the disk / avoiding storage on the disk).
I thought to store the data encrypted with the RIJNDAEL 256 algorithm + a crafted secret into memcache but I'm afraid of data loss / corruption.
I thought as well to MySQL and the memory heap storage engine but I don't know the reliability of the thing so far.
Any thoughts on the subject?
It's probably more trouble than you're expecting. As soon as you persist card details to disk the whole weight of PCI-DSS bears down on you. That means your whole network (and indeed company) comes under close scrutiny to ensure it is secure and follows strong best practice advice.
Using AES (256 bit Rijndael) is a step in the right direction, but the actual encryption is trivial compared to the difficulty in organising a PCI compliant key management system. Keys must be split (dual knowledge), cannot be stored on the same box as the data, must be able to be rotated at least yearly, and so on. Getting key management right is challenging.
Ultimately though, you will need to prove whatever solution you have come up with is PCI compliant. You prove your compliance by enrolling the assistance of a QSA (Qualified Security Assessor). The best advice would be to bring in a QSA now, so that they can advise on what approach to take, and guide you around the pitfalls where necessary.
Bringing in a QSA when the project is complete is a false economy, because if they fail your solution, you start again.
Is storing card data absolutely necessary? There are vendors (Braintree for example) that will process cards without requiring your site to store card info, thereby relieving you of the burden of being PCI compliant.
I read all posts on HTTP over SSL. So far, I know how to get the data securely in a Web form. But I miss the part of recover and keep the data in the same way.
I need in my Website a form to collect sensible data from customers (may be also credit cards numbers for booking, but no credit card authorization process is required) and later keep and read that data in a secure way.
Then, for a basic secure Web application I need:
a) Web site with SSL Domain Validated (DV) Certificate (I don't have fixed IP address. I use basic shared or "virtual" hosting service).
b) Develop a simple PHP & MySQL application that collect sensible data of customers, putting all the app PHP files on the SSL secure folder.
c) All the collected data is gonna be stored in the server MySQL database.
This is the questions part of my message:
1) If I enter later using phpmyadmin to take look at the database over regular hoster services (HTTP), isn't this insecure??
2) What about the hosting administrators? They could also read all sensible data if I use plain text in the database. But encryption methods for data on the server (not only in transmission over SSL) could be enough? Isn't true that the encryption encoding/decoding method could be intercepted by the hosting administrators?? (consider this: the method is inside the application in the same server).
I can't pay the convenience and security of an own server.
3) Considering those things, and assuming that they are true... really matter if I go for a database encryption?
May be I missed something or I misinterpreting some issue.
Thanks a lot for your help and patience.
These shared hosting plans are not really up to the job of collecting credit card numbers - you are betting using a payment gateway and not storing them yourself.
See some regulations on this: PCI
Yes. HTTP is insecure.
Yes, plain text in the database is insecure. Encrypted is slightly more "secure" - it'll deter someone who casually looks through - but anyone with access to the server also has access to the script doing the encrypting / decrypting.
I'd say yes. Encryption in your case won't do a thing against a dedicated attacker, but it'll prevent some sysadmin idly browsing through from immediately having the data without having to make the deliberate step to break in.
I hope you're not storing credit card or other sensitive data, particularly if covered by privacy laws in your jurisdiction. Storing that sort of stuff on a shared server will probably get you sued. If nothing else, storage of credit card data in this manner will be a violation of your merchant account - if they get wind of it, Visa and MasterCard will become unavailable to you.
1) Seeing the data with phpmyadmin over HTTP is insecure, of course.
Regarding 2), if you don't have physical security, then you can't have any security (perhaps with the exception of storing encrypted data which you encrypt and decrypt outside the hosting site).
As your hosting company has access to the computer, they can read all your data.
Having said that, in my experience hosting providers will not do that and try to keep your data safe (because that is their business), pretty much in the same way banks' business is to try to keep your money for you and safeguard it and not taking it.
3) Go for database encryption only if you keep backups. For running the live version it provides little more security (if at all) and makes things more cumbersome.
It is.
They can.
Not really but it could still be a good idea. Someone could get hold of your database and not the PHP source code. Then encryption in the database would be a good thing.
You are correct. The only way to be sure is to run your own server. Also you should know about the Payment Card Industry Data Security Standard.
I think that bobince is totally correct. Public key crypto can help you but keep in mind that you loose comfort of using PHPMyAdmin to view the data - you will see garbage that will need to be decrypted somewhere on the side. See http://www.php.net/openssl to learn more about PHP and public key crypto.
Having an encryption/decryption process entirely on the server is, as you suspect, mere obfuscation and not secure in itself. It can help in cases of a partial compromise, where an attacker gains read access to the database (typically through an SQL injection hole) but no ability to read the site scripts or run arbitrary code.
If you only need to write out sensitive data (canonically credit card numbers) that the server doesn't need to be able to read back in, you can do that with public key cryptography. Encrypt the data with your public key, then read it only on a known-secure machine that has the corresponding private key. This protects past data in the case of a greater compromise where the scripts are readable, and in the case where an attacker gains write-access to the scripts, they at least only get new incoming data leaked, and not the old stuff. Hopefully that would give you time to detect the intrusion and rebuild.
Isn't true that the encryption encoding/decoding method could be intercepted by the hosting administrators?
Yes. But then the hosts have physical access to the machine, so could bang a rootkit on it that intercepted everything the webapp was doing on the fly from day one, if they really wanted. There's no way around trusting your host, so pick a reputable one and don't run sensitive systems on shared servers.
I understand the mantra of "don't roll your own" when it comes to site security frameworks.
For most cases anyway.
I'm going to be collaborating on a site that integrates text-messaging into the system.
I'd like to use an existing, well-tested security framework to protect the users data, but I need it to also protect a users phone number as well.
I wouldn't want to be the one responsible for a list of users cell phone numbers getting jacked and spammed.
What suggestions can the community offer?
Note that techniques applied to passwords aren't applicable here. You can store a password salted and hashed (although the value of doing so can be disputed), but that doesn't work for phone numbers.
If someone jacks your server, they can do anything the server can. This must include recovering the phone number, but doesn't include recovering the password if it's hashed well. So the phone number is just a particular case of protecting confidential data.
If phone nos truly are the only sensitive data in the app, then you could look at walling off the part of the app that sends the texts, and asymmetrically encrypting the phone nos. In a different process (or on a different machine) run an app that has the key to decrypt phone nos. This app's interface would have maybe one function taking an encrypted no and the message to send. Keep this app simple, and test and audit the snot out of it. Either hide it from the outside world, or use authentication to prove the request really came from your main app, or both.
Neither the db nor the main part of the app is capable of decrypting phone nos (so for example you can't search on them), but they can encrypt them for addition to the db.
The general technique is called "Privilege separation", the above is just one example.
Note that phone nos would generally need to be padded with random data before encryption (like salting a hashed password). Otherwise it's possible to answer the question "is the encrypted phone number X?", without knowing the private key. That may not be a problem from the POV of spammers stealing your distribution list, but it is a problem from the POV of claiming that your phone numbers are securely stored, since it means a brute force attack becomes feasible: there are only a few billion phone nos, and it may be possible to narrow that down massively for a given user.
Sorry this doesn't directly answer your question: I don't know whether there's a PHP framework which will help implement privilege separation.
[Edit to add: in fact, it occurs to me that under the heading of 'keep the privileged app simple', you might not want to use a framework at all. It sort of depends whether you think you're more or less likely leave bugs in the small amount of code you really need, than the framework authors are to have left bugs in the much larger (but more widely used) amount of code they've written. But that's a huge over-simplification.]
Since you need to be able to retrieve the phone numbers, the only thing you can really do to protect them (beyond the normal things you would do to protecting your db) is encrypt them. This means that you need to:
Make sure the key doesn't leak when you inadvertently leak a database dump.
Make sure your system doesn't helpfully decrypt the phone numbers when someone manages to SQL inject your system.
Of course the recommendation of not rolling your own still applies, use AES or some other well respected cipher with a reasonable key length.
I’m pleased to announce the release of hole-security system for PHP
This project stands for bring to PHP the kind of security that is provided in Java by Spring Security the formerly Acegi Security System for Spring. It’s designed to be attractive to Spring Security users because the philosophy is the same. It’s an unobtrusive way to add security to a PHP site. The configuration is made using substrate IoC/DI as Spring Security use Spring IoC/DI.
An example configuration ship with the framework and can be used like this:
$context = new substrate_Context(
'./path/to/hole-security/hole-security-config.php'
);
$context->execute();
$hole_Security = $context->get('hole_FilterChainProxy' );
$hole_Security->doFilter();
Just be sure that the bootstrap code of the framework is executed before the bootstrap of the MVC of your choice.
WebSite:
http://code.google.com/p/hole-security/
Documentation:
For the moment you can use reference documentation of Spring Security where it’s apply. You can get a general idea using the Acegi Security reference documentation because hole-security use the same way of configuration, but keep in mind that it’s based on Spring Security.
License:
It’s released under Apache License Version 2.0.
Features:
hole-security brings an pluggable security system where you can adopt the security requirement of your environment. Currently there is a very simple security system because it’s on the first release but with the base foundation that it brings you could suggest or request for new features to be added to the project.
Currently Features:
In memory dao authentication as a proof of concept, you can switch to your preferred dao or implementation that get’s user data from database or wherever you store it. In futures release an PDO based implementation will be created.
Configured filters for be applied to url patterns. Url path matcher can be plugged to, currently it ship with a ant styles path matcher.
Authorization Manager can be used in your application to decide wherever or not do something, always obtaining the reference from the substrate context.
Shared Security Context accessible from any code of your application if hole_HttpSessionContextIntegrationFilter is applied. You can use this context to save information related to the session without use the session object directly.
You can use a custom login page and customize it according to the hole_AuthenticationProcessingFilter configuration, or customize hole_AuthenticationProcessingFilter according to your custom login page.
The default password encoder is plain text, without encoding. Futures releases will have implementations for MD5, Sha based, Base64 and others related encoding. You can create your own password encoder and get configured.
All the objects are loaded as required, if something like a filter it’s not used for a request would not be loaded. This increase the performance of the application
There are others features related that hole-security have.