1

Say I have one website created with the LAMP stack and another with the MEAN stack. I want to create a program which estimates the entropy of a password so that I can add a password strength meter to the sign up pages on both sites. I do not want to write the same same program in both PHP and Javasript.

What is the best (or at least standard) way of facilitating interop between my entropy program and LAMP/MEAN servers?

It seems like the easiest way would be to use PHP's exec or Node's child_process.exec to call my entropy program, but I always read literature warning against direct system calls. Or is it the case that it just has to be done right?

Should I use UNIX sockets?

Should I create a REST (or WS*) API for the entropy program which is only accessible from the same server?

Is there another method?

In this case I plan on using C for the entropy program, but I am looking for a solution which works with any language: complied or interpreted.

Sean Letendre
  • 71
  • 6
  • 1
    Why don't you use the zxcvbn password strength meter ? Its originally written in JavaScript but a PHP port is also available. – bdsl Jul 20 '18 at 17:58

3 Answers3

3

I suggest a web service approach.

Create a json formatted rest service in any language (c, nodejs, whatever).

Service takes arg of password and returns json structure with analysis results.

This service is then a module that can be easily used from either existing website for example via simple curl calls.

Security of this service can be achieved in many ways but one simple example is the service can be configured to only listen on a private localhost port so it's as secure to the existing webservers as a subroutine call would have been.

Note this is intrinsically quite similar to the exec approach you outlined but because the service is always running this approach is more efficient: same interprocess communications but no need to start process and initialize it's data for each request.

Lewis Pringle
  • 2,935
  • 1
  • 9
  • 15
  • do I need a separate server daemon to run the web service on? – Sean Letendre Jul 20 '18 at 06:05
  • 1
    This approach requires you to package your password analysis service as a web-service. This can be done myriad ways (which is best depends on your language choice, which I gather in C/C++). First, there are language independent ways to wrap code as web-service (e.g. cgi integrated with Apache or nginx), but this will negate any performance advantages found in the approach I suggested, and create security holes (just due to complexity of configuration). – Lewis Pringle Jul 20 '18 at 15:17
  • 1
    There are libraries you can use, such as https://github.com/SophistSolutions/Stroika, or https://github.com/cesanta/mongoose or https://www.cs.fsu.edu/~engelen/soap.html to turn C++ code into a webservice. My favorite of those is Stroika (cuz I wrote it), but I've used gsoap before, and both are good choices. Integrating ANY library will have learning curve. Interestingly - one of the lowest learning curve approaches is to write your own simple C++ (limited) web server. – Lewis Pringle Jul 20 '18 at 15:21
  • 1
    If you use a language like nodejs, or python, these come with builtin webservice libraries, making this effort completely trivial (very little learning curve, except you need to know those languages). – Lewis Pringle Jul 20 '18 at 15:22
  • 1
    So in essence, you are packaging your code up as a daemon which provides the webservice. – Lewis Pringle Jul 20 '18 at 15:23
3

What you're trying to achieve is described as an SOA (Service Oriented Architecture) which defines an application as a set of very loosely coupled, fine-grained, independently deployable services interfaced with a lightweight technology-agnostic protocols. This kind of architecture puts emphasis on modularity, testing, continuous refactoring of individual modules (also called microservices). It's a very young concept and an overall consensus in regards to best practices has yet to emerge, therefore, it's hard to directly answer your question. What people usually agree on is:

  • each service should represent a philosophy of "do one thing and do it well"
  • each service should use best language for given task
  • selected protocols shouldn't be language dependant
  • not everything should be a service

This last bullet is an example of the usual criticism towards the SOA concept which seems to be focused around the tendency of creating "nanoservices" (i.e. services too fine-grained to justify the overhead of inter-service calls).

As there's no real "standard" or commonly agreed "good practice" in regards to such services, I've seen several applications over the years where literally each service used different stack. Even though they communicated with each other rather easily and efficiently, I'd personally advice against it due to the high entry threshold for new developers.

Above said, the most common solution I've seen was C/C++ daemon listening on a Unix socket. It's pretty scalable as these can be communicated locally or over the network, also C/C++ language is widely used and there's high chance somebody new to the project will know it or be able to quickly find help on the Internet. Slightly less popular were using a shell script + Unix socket. The rest of SOA services I often ended up replacing with a piece of JavaScript that I kept in shared memory and just included wherever needed (it's a breeze in both typical PHP and JavaScript SPA style applications).

cprn
  • 196
  • 1
  • 4
2

A password strength meter is highly security-sensitive software. The password should ideally never be transmitted to the server.

This also resolves your dilemma: implement the password strength meter as a client-side widget in pure JavaScript. You can then easily reuse this widget on both websites.

When you heard that running child processes should be avoided that is mostly right. Launching a process takes a long time, relatively speaking, which noticeable limits the requests per second you can handle. Even more so when the child process is an interpreter. Error handling of child processes can be nontrivial.

There are also some potential security issues: command line parameters are not private. Secrets should be communicated through a pipe instead. It can be difficult to guarantee that you are running the process you intended due to features like the PATH variable and filesystem symlinks. If you were to accidentally run the wrong process, the passwords might be compromised. While none of these security concerns should apply if you are running on a private server, it is important to consider them.

A note on using C: it is a perfectly fine language, but writing secure software with it can be challenging unless you are an experienced C programmer. It is easy to accidentally introduce buffer overflows, and it is easy to forget correct error handling. The Spiderman Principle “with great power comes great responsibility” applies.

Running a persistent password strength meter program and communicating with it via sockets or an API could be interpreted as a kind of microservice. This would allow you to reuse the same service on multiple websites as the programming language of the microservice is independent of the rest of your website. But as discussed above, a client side implementation is vastly preferable here.

amon
  • 132,749
  • 27
  • 279
  • 375
  • Passwords are sent to servers over https all the time for log in. In fact it is better to have the entropy calculations done server side for two reasons. First, there will be a dictionary of English words and common weak passwords which would be huge files to transfer to the client. Second, I am not just providing the strength meter as a convenience: I want to validate that passwords meet minimum requirements. A hacker or someone with Javascript disabled on their browser would be able to circumvent the client-side strength meter. – Sean Letendre Jul 18 '18 at 06:57
  • 1
    @SeanLetendre Ok, if those are your requirements then building some kind of password rule microservice might be better. While writing this answer, I was thinking of purely informational password strength indicators. It's good that you are going to check dictionaries as entropy estimation alone is [problematic](https://www.troyhunt.com/password-strength-indicators-help-people-make-dumb-choices/). Note that you can easily [check compromised passwords](https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByRange) from the client side as well. – amon Jul 18 '18 at 08:27
  • 1
    "While writing this answer, I was thinking of purely informational password strength indicators." - You should probably put that in the answer. Maybe in bold or even header text. Right now, your answer reads like you're saying that you should never trust the server you control and always trust the client you have no control over. – 8bittree Jul 26 '18 at 19:14