I'm using imageresizer with diskcache, and it works great. The only problem is that if i turn on FIPS compliance on the server/client ( see How to enable FIPS on windows 7 for an example on how to do this if you need it ), it doesn't work at all. I can clear out the images from the diskcache folder, and imageresizer won't fill it back up when this setting is turned on. See
https://gist.github.com/vishnu4/ced29ca01b37957a90f6 for a diagnostic sheet, which doesn't seem to show any errors.
Is there a good workaround for this, or is FIPS compliance just not supported?
We don't use FIPS compliant modules exclusively. There are a few reasons for this, but primarily it's to escape implementation bugs in the Windows cryptography modules and portability issues with the same.
That said, we could probably create and maintain a FIPS-compliant operating mode if we had a support contract with a user who needed FIPS-compliance.
But using FIPS-compliant modules wouldn't be a good choice for default operation, so it's not something we would consider a bug or design flaw. Also keep in mind that unless you're using the RemoteReader plugin, ImageResizer isn't doing any cryptography, just hashing for cache optimization purposes. Unfortunately, FIPS-compliance is quite context-blind.
Related
I am trying to build a desktop app.
I am thinking of using electron on the recommendation of a web-developer friend of mine, but as I am the only sole developer, I don't have the means to test the software on different platforms(OS, hardware etc.).So I am anticipating that this will cause a problem later, in the end, to test/debug software on different platforms and different OS.
I have ruled out web-apps because of some privacy concerns of the users for the remote data hosting.
Software is pretty lightweight and is almost equivalent to the image viewer apps with some slight modifications.
How to solve the problem of variations of different platforms?
Any literature suggestions pointing me in the general direction are also welcome.
Sometimes it helps to think of Electron as two processes.
The renderer vs the main processes. Generally the renderer process which runs the HTML/CSS/JS is it's own isolated component, and you communicate to the main process using IPC.
So generally for the UI, you can use mostly any web based testing framework to test reliability. At Amna, for example, we use Cypress as our E2E testing platform. You an also use something like QAWolf. Both should work with localhost. In general, most website testing tools should work fine, and consistently across platforms.
Where this gets tricky is when a UI functionality makes a call to the OS or the main process. For example, saving to the disk, or launching a program.
The general flow is this, and I've yet to find radically simpler options:
Set-Up a VM or buy a machine with the corresponding OS. I used Spot VMs in Azure for this.
Manually test the scenarios you care about in each VM before you ship
If you have a lot of cases that rely on the OS, then you should be able to further optimize this by using an automated test runner like Spectron.
From experience, what I've realized is that most of the iterations I do happen more on the UI than the underlying functions with the cross-platform capabilities. And if your code has good separation (e.g. contextIsolation:true, nodeIntegration:false), it should be pretty obvious when you need to do an entire "cross-platform" test vs just UI tests.
I'm not familiar with a lot of large-scale electron testing frameworks, I do know that ToDesktop handles package building and generating binaries to perform a smoke test and verify things open across different operating systems.
It depends.
The answer depends on what you are building, so it makes sense to figure out what you actually want to build. Some questions you might ask yourself:
Do I need a database?
Do I need authentication?
Do I need portability?
Do I need speed to market?
Do I want to pick a language I'm familiar in?
These are all good questions and there are dozens more we all ask ourselves. However, back to your original question.
Electron is a fine choice
Yes, there are alternatives. But Electron is used for Visual Studio Code, Facebook Messenger, Microsoft Teams and Figma. Choosing Electron means there are other developers making apps and there are proven apps in the market so you don't have to worry about a dead ecosystem.
Electron is easy to onboard if you know web technologies, think js, html and css. If you know these, you can transfer your web dev knowledge and make a cross-platform app. You don't have to worry about learning each OS since the UI is the webpage which will look mostly* the same between each OS. (*some very minor differences, but essentially the same).
Cross-platform deployment is easy
There are a few ways of bringing your app to multiple platforms, I happen to be most familiar with electron-builder, but the other two solutions work as well.
Many templates to start with
I am biased, since I'm the author of secure-electron-template which is one of the many templates you can choose from when starting an app. However, I recently reviewed all Electron templates and found that only 4 do not have serious security vulnerabilities.
The Electron framework frequently is updated, and over the course of the past few years there has been a shift in the way Electron apps are made. Some earlier frameworks didn't have good secure defaults which some of the older Electron templates inherited and thus, aren't as secure as new frameworks that follow security guidelines.
If you decide on Electron, give my template a try. It's got a number of features I'm building out in order to help the community with features they might want (ie. internationalization (i18n), saving local data, custom context menus, page routing, e2e unit testing, and how one can use license key validation, to name a few things).
I have tried my firefox 62 and chromium on various webauthn examples and I could not make any of them work. Are those supposed to work without special hardware? I activated security.webauth.webauthn_enable_softtoken in about:config. Though I can't find much documentation on what exactly it does. Is webauthn ever supposed to work without special hardware?
https://webauthn.bin.coffee/
https://webauthn.io/
https://webauthndemo.appspot.com/
To be able to use the "softtoken" in Firefox you have to enable it and disable the usbtoken:
security.webauth.webauthn_enable_softtoken=true
security.webauth.webauthn_enable_usbtoken=false
Then you can test on https://webauthn.bin.coffee/ and https://webauthn.io/ .
However, I have no idea how exactly it works and where its documentation is located.
As for the question how to use Webauthn, it should be possible according to the standard, but if browsers support it is another thing. Check this comment: https://github.com/w3c/webauthn/issues/1027#issuecomment-411441722
The spec is indeed written with hardware-backed authenticators (external or built-in) as the main concern, but WebAuthn does not in any way forbid integration of purely software-based authenticators.
...
It's perfectly possible for browsers or browser plugins to provide support for software authenticators, although WebAuthn provides no standardised API for doing that.
Well, WebAuthn is evolving technology. Supported only in Firefox/Chrome Desktop and Chrome Mobile browsers.
You'll need some U2F stuff like https://www.yubico.com/products/yubikey-for-mobile/
or AddOns like https://krypt.co/
Webauthn is pretty widely supported now, and it works in modern browsers without a roaming authenticator (a USB device or similar). It's very easy to test on the site you mentioned, https://webauthn.io/
https://caniuse.com/#search=webauthn
We have developed a software in vb.net using Visual Studio 2013. Now we want to build a custom installer with following steps/features:
User Start to install our software.
At 'Enter Serial Key' option, user enters the 16 digit Serial which have we provided.
When clicking 'OK' button, our software connect to our IP and save the Serial Key with some other user's information to our database.
A confirmation Key is returned back to our software.
Software writes a file and save it to the system folder.
It is almost like Adobe or Corel registration process.
We are open to other techniques also which must secure that our software must install on a single machine only.
Please be noted that we are a group of novice programmers(not so advance level), so; if the process is elaborated, it will be very helpful to us.
One-Shot Setups: "A setup is run once, an application can be started again - in order to resolve and debug problems interactively - with meaningful error messages show to the user."
Hence: avoid license validation in the setup.
Short version on licensing.
License Key: Preferring to deal with license keys in your application seems logical for several reasons: the one-shot nature of setups
yields poor reliability (no interactive debugging - poor ability
to resolve problems). The end result is lots of support calls for something very trivial.
Further, the risk of piracy and hacking is a major concern when
exposing a license validation DLL in the setup. And finally
communication over the Internet is difficult with today's setups (proxies, firewalls, etc...) - which is a modern way to validate license
keys (in the future setups might have full Internet access, but be careful assuming too much since corporate users may have lots of restrictions and poor deployment could hurt sales and acceptance of the software for corporate use).
Finally your application must usually support a trial version,
and then you need a license dialog in your application anyway.
Why complicate your setup too?
CAs: Custom actions are complex and vulnerable to failure in general - due to complex sequencing-, conditioning- and
impersonation issues and overall poor debugability. More information:
Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
Overall Complexity of Deployment: A short, attempted summary of the overall complexity of deployment:
Windows Installer and the creation of WiX
(section "The Complexity of Deployment").
I would remove all licensing features from the setup and add them to the application. Your setup can still write a license to disk or to the registry by passing it to msiexec.exe as a public property -
UPPERCASE properties (or you can "hide" things a little more by using a transform to apply the serial property - it has exactly the same effect as setting the property on the command line). You can also set the LICENSE property from a dialog in the setup when it is run interactively, but my favorite approach is to allow adding the license key unvalidated to the registry in silent deployment mode, and to instead enter the license key directly in the application, and not the setup, for interactive deployments (the above description is for silent deployment):
msiexec.exe /I "C:\Install.msi" /QN /L*V "C:\msilog.log" LICENSE="123-456-789"
This will allow the license to be easily added to each machine in a corporate deployment scenario. The license value is simply written to disk or registry without validation. The application will verify it (more secure than a validation dll in the setup).
There is no need to mess with any complex setup dialogs, but you will need a license dialog in your application as explained below.
As a setup developer you should offer to help implement the feature in the application instead of the setup so it doesn't seem like a case of "passing the buck". This is all for overall software reliability and foolproofness - and several reasons are listed below.
Almost all large corporations deploy MSI files silently, so the setup GUI will be ignored most of the time anyway. You are then simply adding risk and wasting resources if you deal with licenses in the setup.
One drawback: An application run as a non-admin user after installation can not write to HKLM to share a serial between all users on the computer (a setup running with elevated rights can). It must either write to HKCU or the setup must have prepared write access to a specific HKLM location in the registry for the application to write to. I prefer writing to HKCU for each user since the license is then less available for copying by others, and it is kept as user specific data (allows roaming, though that is a hated feature by most IT professionals). However, a HKLM license key written by the application or the setup during installation (as explained above with a public property set) allows all users to share a license when launching the application.
There are several more concrete reasons to keep license handling and validation out of your setup:
A significant number of support requests always result from people who have problems registering their license keys in the setup. A setup is run once, an application can be started again if there are problems. This is more important than you might think for inexperienced users. You also have better features available to handle exceptions and error conditions and whatever unexpected problems may occur in the application.
Serial validation in the setup exposes a validation dll / method that is easily cracked by pirates. You won't prevent piracy by eliminating it from your setup, but at least you make it more difficult. It is more secure in the application if you cloak things a bit (static linking, encryption, obfuscation, putting the validation process online, and / or whatever is done by security professionals that I am unfamiliar with).
Allow application trial version: If the setup needs to support a trial version of the application, you should allow the user to enter a license key if they end up buying the product - preferably without having to re-run the setup or uninstall / reinstall just to add the license key. In other words you will likely need to deal with licensing in your application anyway, why complicate your setup too? More risk, more QA, more potential support requests and potential for multiple required fixes in both setup and application. High total cost?
If your application runs with different editions, what if the user buys an upgraded license? They should just be able to enter it into the license dialog and unlock features if possible and not uninstall and reinstall with all the clunk that involves. For some upgrades this is hard to achieve though, and you often end up with separate setups for different editions.
If the network is using a proxy server for Internet access, you will have problems registering the license over the Internet during the setup (often asked for by marketing). You have more features to check and deal with this in the application - it can try again and wait for access (generally you hook up to IE for automagic proxy configuration if possible). For corporate deployment you need a silent install option too which doesn't validate the key but just writes it to the registry. Trying to access the Internet from a silent install of an MSI is in my opinion a rather extreme deployment anti-pattern. I find it dubious in the setup GUI as well. Do the registration in the application - much less controversial, and you can set up firewall rules to allow it to access the Internet (msiexec.exe is likely blocked - and for good reason). There could also be hardware firewalls and / or security software to deal with that makes Internet access difficult or even impossible without some clunky admin server configuration. This could kill your software from consideration is my experience: "Just get this off our network and application estate - there must be better options - far too clunky and error prone".
UPDATE: As deployment technology matures and becomes more "Internet based" this "truth" may change, and we could end up doing everything "online" with deployment designed specifically to run via online "repositories" for example. We will have to wait and see. For now my opinion is that any setup Internet access requirements are erroneous and undesirable.
Setups that mess with licensing may sometimes cause license data to be deleted during upgrades, patching and migration scenarios due to bugs in the setup. This is a lot more serious at times than you would think - the package might hit thousands of workstations in large companies and be cumbersome to fix.
There is a rather bad "anti-pattern" in the MSI technology itself whereby self-repair or manually triggered repair will reset values in the registry that has been changed by the application. This can wipe out license keys. We see this all the time, and it is the technology's fault. It is just not logical in this area.
There are some fixes - or rather workarounds - for this (use a permanent component, write license from a custom action instead of from a component, etc...), but I find them quite clunky and you have to have a lot of experience to know all the pitfalls - and even experienced users mess this up.
Licensing is a huge corporate headache - often what is desired by a company or corporation is that licensing is centrally managed on a server, and not based on text serial numbers at all (for example concurrent or floating licenses acquired on application launch via the network). Just mentioning this though it is sort of out of scope for the question. In these cases what you specify during installation is generally an IP address pointing to the license server, or just a regular host name to be resolved by WINS or DNS.
As you might have already guessed Windows Installer doesn't provide any out the box feature to handle licencing. But there are commercial licencing solutions which you can go for if affordable.
LogicNP
DESAWARE
Since this is very broad question difficult to explain low level implementation details. I can give you a direction.
First of all you will need a custom UI where user can type in the License/Activation key. There are ways to incorporate a custom UI into windows installer, I have already explained few approaches in SO, refer to the following threads.
Show custom Form during installation
How to add additional custom window to VS setup projects UI flow
By following above approaches you should be able to add a UI where user will type in a key. Once user added the key, he will press Activate button on the custom UI, Button click event handler will invoke the necessary logic to Insert/Validate the activation key entered by the user.
Maybe you could try Inno Setup which is free (even open source) installation system.
It is script based which allows you to tune your installer and perform in it everything!
Creating custom page with entering serial number is really easy, see this example: CustomPage for Serial Number in Inno Setup
and there is also integration for Visual Studio.
I am using IBM workLight 4.0 version, currently i am developing a simple insurance applicatoin, everything is done well. After Android setup has taken, from the .APK (android setup file) i can extract the HTML5 and javascript source. I felt it is insecure from the hackers and might be missused by someone.
Can you please anyone can tell me how to secure code in Setup/deployment?
The answer to this is Obfuscate you code before you create an APK. For more information on obfuscation visit wiki.
I previous stackoverflow post tell how to do it for android.
How to avoid reverse engineering of an APK file?
For Javascript obfuscation visit this stackoverflow question
How can I obfuscate (protect) JavaScript?
And one more thing HTML cannot be obfuscated, you can see the HTML source and associated css by pressing F12.
Worklight 4.0 was still in use in 2013? :)
Android Proguard is unavailable to Worklight-based Android apps in Worklight v4 to v6.2 (current release).
The only way to add some degree of obfuscation to an Android app in Worklight is by using the Google Closure compiler. You can follow the steps to do so in the following blog post by Anton Aleksandrov: Obfuscating JavaScript code in Worklight applications.
Note:
Wikipedia defines code obfuscation in a following way
In software development, obfuscation is the deliberate act of creating obfuscated code, i.e. source or machine code that is difficult for humans to understand. Programmers may deliberately obfuscate code to conceal its purpose (security through obscurity) or its logic, in order to prevent tampering, deter reverse engineering, or as a puzzle or recreational challenge for someone reading the source code. Programs known as obfuscators transform readable code into obfuscated code using various techniques.
Two important things to be noted from the above definition are
- The purpose of code obfuscation is to conceal its purpose, prevent tampering, deter reverse engineering or puzzle someone reading the code.
- Obfuscated code is difficult for humans to understand.
So basically obfuscating your code means converting it to a format that is difficult for humans to read. Not impossible. Just difficult.
Therefore - it is very important to understand that code obfuscation, especially in JavaScript, is a relatively weak security measure. Most modern web debugging tools are smart enough to "prettify" the obfuscated code reverting it to a much more readable (however still not original) format.
I'm investigating the use of mono in real world high traffic web applications. There are some references on the mono site (companies using mono), but I couldn't find a high traffic website sample other than Deki powered ones. And I've read some mailings about mod_mono stability problems because of inexistence of compacting GC.
Please reference your app and give some info, if is there anyone using mono in production.
...or do I have to look at Java ?
Regards,
sirmak
Wikipedia is using Mono for search (also listed on the companies using Mono page)
A ton of people use Mono in production and development. I'm sure this page will change dramatically over the next year or so, but look at http://www.mono-project.com/Companies_Using_Mono. This is a good reference, but projects using Mono are popping up every day, so we'll see more soon.
Lunchwalla.com uses Mono for its website. It receives fairly high traffic. There is also a little blog item regarding the set up - http://blog.lunchwalla.com/2010/04/23/the-tech-behind-lunchwalla/
Go for it. Beyond the initial setup work and tuning you can have a very stable and fast server with all the advantages of low-resource required do the the job, at least with nginx/lighttpd. mod_mono (Apache) resources will go way faster according to a lot of feedback I've been reading on the all the major places this topic is discussed
From #mono (IRC)
<ruionwriting> ahall: in apache what is your feel about the performance compared with nginx?
<ahall> the fastcgi implementation is just a bit buggy and buy sending few concurrent requests to it it hogged 99% cpu and didn't get out of it. I will switch to nginx + fastcgi as soon as its suitable for me in production
<ahall> buy = by
<ahall> but yeah i always use nginx instead of apache whenever possible, but with mono i dont recommend it
This last part I don't have to agree based on the setup I have.
This question on stack overflow must me included here.