I wonder if someone might be able to help us or offer some advice. We are a Java focused team, and are looking at extending our in house Authentication service, to offload most of the authentication , to use an LDAP server. That way we can simply use an out of the box password policy, which meets our criteria, plus we can use stuff such as replication etc. We are investigating which is the best free LDAP server to use.
So far we have investigated :
OpenLDAP (We found this is written in C, and documentation is not all that great).
Apache DS (We found this is good, but has a basic password policy. Mainly it does not seem to be extendable to fit one of our requirements (that the password policy should enforce mixed case characters, etc etc). This is surprising as the basic config options are ofcourse supported, eg. minimum length of password, maximum retries before being locked out etc etc.
Sun OpenDS (This fits all our needs, but no longer seems to be supported??. Please advise us if this assumption is wrong?It has great support for Password Validators, so that we can handle enforcement of mixed case passwords etc etc).
Oracle Unified Directory - This is the SUN DS server which is supprted. However, Oracle Unified Directory is not free unfortunately.
So, basically the question is 2 fold :
(1) Does anyone know how to extend the passowrd policy on Apache DS, such that we can support mixed case character enforcement. eg password must contain a mix of upper case and lower case chars aswell as atleast one digit etc etc. Or is this out of the box? I personally couldnt find any documentation on it?
(2) Does anyone know of any good and free LDAP servers that support this sort of stuff. Any ideas please?
Many Thanks,
R
After all of this, we finally found 389ds (ironically the last one we investigated). This we found was the best (for our needs anyway). The reason is that, it is has a great administration UI, does everything we need to do out of the box, plus, best of all, it is available in a costed option under RedHat. We didnt take the supported option, but nonetheless, as it is supported by RedHat, the documentation , we found was superb. Therefore, we felt confident that everything we needed to do wasexplained 100% rather than with some of the others, was half explained on some unmaintained wiki. So we advise all to look at 389ds.
I know ApacheDS doesn't support any extensions for ppolicy checks, can you file a feature request on ApacheDS's JIRA? We might try to get this included in the upcoming release.
I have filed this request https://issues.apache.org/jira/browse/DIRSERVER-1858
You should look at the http://forgerock.com/ OpenDJ which is an active and supported if you subscribe spin from OpenDS.
-jim
Related
I'm new in SSL concept , Sorry I don't know my question is correct or not ...
Recently I wanna know root_certificates.hpp should be specific for every clients? I mean that clients should create it by openssl?? or it's general and all clients can use it?
root_certificates.hpp is only there to make the examples portable.
On your system, you typically can use set_default_verify_paths.
If your application additional requirements, which is often, you will want to include your own certificate store in the way that your application chooses. There are more details to customize the verification process: https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/reference/ssl__context.html (see also https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/reference/ssl__stream/set_verify_callback.html).
I am starting to investigate the good practices about Public API, specifically about how to deal with breaking changes. There is a lot of technicalities related to the versioning (or non-versioning!), but I am more interested about the code base implication.
Imagine a basic scenario where you have a business rule "password must have at least 10 caracters". And you have a "Create User" scenario exposed in a public API, accepting a password.
You have hundreds of clients using it, and one day, you decide to change the business rule to "password must have at least 15 caracters". Even if you did not change the semantic of the API signature and payloads, you just introduced a breaking change in your API because you changed the behavior of this API.
How would you deal with this?
I only find wrong approaches:
Modify your domain invariants (business rules) with dated/versionned invariants: this would create a nightmare in the code readibility / testing / etc.
Duplicate your code base per API version: this would create a maintenance nightmare
Hope one day you will be able to deprecate all this and become clean again: in your dream...
Any real life experience on this in your job?
The easiest way is just to communicate with your clients and warn them of the upcoming change weeks/months before. This way they can prepare and be ready for the breaking change.
If you absolutely must support old clients, another option is to keep the domain invariant to 10, but add an additionnal api call for the create user scenario which checks the password length and verifies it is of length 15 outside the domain. Then, encourage your users to migrate to the new CreateUser endpoint. This works for simple cases like this one but will become very hard to do for complicated invariants or if your domain is used in different contexts (multiple Apis, desktop app etc).
If you decide to go with this route, a good tip is to make sure you have metrics to know how many clients use the old endpoint vs how many use the new endpoint. When you have reached a certain threshold you can shutdown the old endpoint and move the minimum password length of 15 invariant from the Api to the domain,
I'm running rpcapd on a Raspberry which serves as a WiFi access point to trace/sniff network traffic by WiFi users.
I can run rpcapd in null authentication mode and access the interfaces from my windows machine using wireshark and it works perfect.
However, I'd like to expose these capture interfaces to multiple users and i thought it might be good to not use null authentication but have at least a little barrier for unwanted users.
If i don't use the "-n" argument, what is the user/pass? I searched Google but i can not really find a source which leads me to the answer.
I tried creating a second user which has a password and ran rpcapd from this users but still if i use these users Linux credentials, wireshark tells me it can not find any interfaces. When i re-run rpcapd with the -n argument everything works.
So... i must have overseen something!? What is the username and password for non null authentication operation or where can i specify one?
Thanks a lot!
Let me know if you need further info to help. Thanks!
When not using RPCAP_RMTAUTH_NULL authentication it will instead use the other type, RPCAP_RMTAUTH_PWD : https://www.winpcap.org/docs/docs_412/html/group__remote__auth__methods.html
And according to some old copy of the manual I found (ftp://ftp.tuwien.ac.at/.vhost/winpcap.polito.it/301a/docs/group__remote__auth__methods.html) which helpfully listed code references : "Referenced by daemon_checkauth(), and rpcap_sendauth()."
..which leads us to to the code that does the authentication : ftp://ftp.tuwien.ac.at/.vhost/winpcap.polito.it/301a/docs/daemon_8c-source.html#l00626
I downloaded the source (http://www.winpcap.org/install/bin/WpcapSrc_4_1_3.zip) to check it was still current and found in file "wpcap\libpcap\rpcapd\daemon.c" the current information for "daemon_AuthUserPwd" which shows not much has changed.
Hope this helps :-)
My current application I am working on has following line at response fields:
Server: Microsoft-IIS/6.0
I feel embarrassed. I am thinking about writing http module to cloak this field. However am I little afraid that browsers use this value, in order to achieve maximum performance, to alter some aspects of http implementation. So what can go wrong?
No, the Server field is purely informational, it does not concern the browser at all.
The HTTP Protocol RFC 2616 does not specify any behavior associated with this field:
14.38 Server
The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
It does note though:
Revealing the specific software version of the server might
allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server
implementors are encouraged to make this field a configurable
option.
Well, in short: unless the browser is some sort of robot looking for this information (mostly for the bad, you bet) there's nothing bad about deleting it.
This is useful for purposes of statistics, for example, and even some great web services that could just don't use it and save real money (actually, almost nothing for such given company) doesn't do that.
You have to have a form on your website for people to send an email to a friend if they found something interesting. You can force people to be logged in (which is not a good option in my case). You can make time delay (this is not really urgent email, so it can wait for 5 minutes). Do you have this problem? How would you solve it?
Edit: I am mostly interested in stopping manual spam
Do you have a problem with automated scripting of your form, or people genuinely using it too much?
The simple solution to the bot problem is a Captcha, such as ReCaptcha. The user-friendliness is questionable, but it would perhaps solve your problem.
You can also use something different from all those captcha scripts. Let me tell you what I do:
- I create a md5 hash:
$secretWord='TryToHashMe';
$formID='myForm';
$md5Value=md5($secretWord.$formID);
echo '<input type="hidden" name="form-check" value="'.$md5Value.'">';
echo '<input type="hidden" name="bot-check" value="">';
those are 2 very simple ways because: 1) auto bots try to fill all your inputs and 2)the hash is not provided, this mean you have a post request from outside your site. The hashing could be extended with some session or cookie, too.
All the best!
I would recommend a Captcha or if you would like something a bit less intrusive, have a simple math problem(which changes) so you just have something like:
For spam protection: Type what Two Plus Two is here _________
I did this on my personal website and never had a problem(and I had a lot of attempts that failed by spambots)
This service has very good anti-spam measures.
http://www.tellafriendking.com/features.php?showall=1#spam-free
FYI, I am involved with the company, so I'm not entirely unbiased, but we do get a lot of refugees who come to us to end their spam problems with other services or downloaded scripts.
Edit:
If you feel the need to vote down, perhaps you should leave a comment too...
The best solution is to use an all-purpose bot filtering solution. I know this is an old post, but a new botnet was discovered that uses these send to a friend modules to send spam (not a new technique but some interesting new advancements).
According to one security vendor (good tips), “At a minimum, they should include a rate-limiting mechanism that will prevent an IP address from issuing unreasonable numbers of requests over a specific period of time. Other DIY solutions are to have all users fill in CAPTCHAs and to enforce registration as a prerequisite to sending out an email message.”