BJ, Yes there are plenty of options to improve and enhance security of login methods but they can still be stolen/copied/lost etc with varying degrees of ease and success. When that happens you're exposed to data leakage.
The point of the feature is to limit that damage should a valid access method be compromised. For example if you have 10's of thousands of clients the reality is no one user would likely access more than N clients a day for normal work purposes, the number depending on the role of the user. Armed with that knowledge you can limit the access per day to a maximum number, should it be reached it can be reported, investigated and dealt with. Ray BJ Freeman wrote: > sorry I have not responded till now > Inline: > > Jacques Le Roux sent the following on 12/9/2008 7:37 AM: >> From: "Jacques Le Roux" <[EMAIL PROTECTED]> >>> BJ, >>> >>> The client concern is in case a login/pwd couple is used but not by >>> the right person (lost, stolen, etc.). Only biometric security >>> could deal with that I guess. > have to think on this one. > using encrypted USB devices for login works with PGP. > >>> By limiting the number of time a page can be visited in a period of >>> time you don't really prevent using UI to pull out confidential >>> data but you make it so long (years) that it's not usable. It's >>> something used in spam fighting known as tarpitting. It has proven >>> to be very efficient and is now used in the gray list concept wich >>> works great. Anyway for the moment it's the requirement I have >>> BTW I wonder if it should not better block the account and send a >>> message to the admin in such case. He/she would then be able to reset >>> the login/pwd to secure anew the login. > yes use tarpitting works very well. I found it really slows down the > spammers. However if there is a heavy use of tarpitting, you are using > up a lot of threads and memory. > I think blocking the account, and sending a email to the person's > registered email with a link back to the login would validate them. > the link would let them validate the email then another email would send > them their logging information. > CC the Admin would be an option as well. >>> I will put the check in at end of RequestHandler.renderView just after >>> the block where ServerHitBin.countView is used. This would >>> clearly separate this new security aspect. And having it at the >>> framework level is clearly easier : you only have to define a list >>> of pages to constrain by PartyRoles. > have to review code before I comment. >> I had a better idea : to use a preprocessor event. I will though need to >> make a small change to allow to return a specific message from the >> event. I guess it will be the only thing I will commit, except if some >> people are interested in the tarpitting feature. > interested but not knowledgeable enough to understand how it works. >> Jacques >> >>> In the check I will need >>> . PartyRole(s), >>> . The list of pages to constrain access by PartyRoles. I will be an >>> ConstrainViewByRole entity with 2 fields : partyRole viewName >>> (pages are actually views in OFBiz) >>> . Max number of page access allowed, and the period of time for >>> counting the number of page accesses in security.properties >>> . An AccessedPage entity with fields loginId viewAccessed >>> dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed) >>> >>> I think it's a feature generic enough to be used in Framework if >>> someone is interested in future (if nothing is defined in >>> security.properties the block would be simply skipped so it's >>> harmful). So if nobody see a problem with that I will implement and >>> commit. Any comments welcome >>> >>> Thanks >>> >>> Jacques >>>
