Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Can a blockchain data structure be implemented without the need of a currency?
My idea is to store cryptographic public keys in a distributed and incorruptible data structure. The need is to get the cryptographic public key associated with an identifier and to be sure that the key is really associated with this identifier. Though there is no guarantee without a certification authority or WoT the idea is to be sure that the key obtained was the first published in the data structure with the identifier and was not overwritten by a malicious node.
So if we have an identifier I can get a cryptographic public key and be sure that it was the first key published with this identifier.
I first though of a DHT but a data can be easily overwritten by the node storing the key.
So I thought of a blockchain data structure for its property of being secure against corruption.
Does a DHT can be used for that purpose? And how? Can a blockchain be used for that purpose and without the currency involved? Another data structure?
The Linux Foundation's Hyperledger Project implements a blockchain that does not require a currency/incentive. There are others that have emerged recently including JP Morgan's Juno and Intel's IntelLedger.
The block chain is simply a directed graph of records where the links are hashed, so if you have a particular head of that data structure all reachable entries from that head are included in that hash. So you can establish a sequence of time.
The crucial part is that the network needs to reach consensus about the current head of the chain and how to decide what the next entry shall be.
So at any given point you can trust the entire past history as long as you can establish that a particular block ought to be the current head.
What the blockchain brings to the table is an incentivized proof-of-X scheme that drives the consensus forward in to the future while making forging even a single new block expensive and forging an entire history prohibitively expensive.
Adding a proof-of-X scheme is fairly easy. But incentivizing people to invest considerable resources into that scheme so that a takeover becomes too expensive to perform is not as easy.
One spontaneous idea (not vetted at all!) would be needing refresh of the identifier-key mapping. If they are not refreshed after some interval of X blocks they expire. That way you have to invest in your proof-of-X scheme to keep your own mappings alive, creating value for yourself while also creating the threat that anyone who could control the network could simply let entries expire by refusing to append any transactions to the chain that would renew the mapping.
I think you might want to take further discussion of such theory to the cryptography or bitcoin stack exchanges.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
What exactly is backend code? Is it just APIs? Is there business logic in the backend?
For instance, if I have a timesheet app and the user enters their time for the day, is the logic to add that information to the database all in the frontend? And the backend is just for exposing an API to add/update information to the database? For this simple timesheet app, generally speaking, what would be in the frontend vs the backend?
This is a very broad question/topic, but I'll try to explain my view on those terms and how to decide where to put what:
In general, the "front-end" is what the user will see. To make this possible, that code has to be "stored and executed" on the users device. I'm quite certain that this means (experienced) users will be able to look into the code of the frontend and might be able to understand how it works. (I'll later explain more about why that is relevant.)
The "back-end" on the other side is usually provided as an "as is" service that somebody is offering, which is reachable via one or multiple of the many available communication protocols and its interface is usually documented in some way, even if it's not public. The most prominent examples nowadays are REST APIs and Graphql APIs.
As you already mention, centralized state management (e.g. storing data) can be an essential part of that (, but it doesn't have to).
When "making a call" to the back-end, some code gets executed on some server and the response (if any) is the only new information the frontend or user get to know.
What goes where?
There are many aspects to consider to make the decision what part of the code goes where. There is no silver bullet: I'm sure examples of all possible combinations can be found.
There can be many different front-ends for a single back-end, based on user preference (e.g. browser based, mobile apps, command line interface, ...).
They can have different release cycles and update mechanisms, so changes to the back-end might need to stay backwards compatible.
For security, operational or data consistency reasons, you might need to implement handling of wrong/invalid input in the back-end, especially if the (kind of) communication protocol changes. Especially since offering a frontend also means that it's possible to know how to call the back-end, so it's also possible to call it differently (be it on purpose or by accident).
Since operations between front-end and back-end are most likely async, certain error handling (like connection issues) can only be handled on front-end side.
Authentication and authorization / secrets management: If you back-end is only an API to the database, it needs to know the right credentials, so they need to be delivered to the user in some way and can be inspected (and potentially "mis"used)
same for business logic: there might be intellectual property or strategic reasons for not delivering it into the hand of users or potential competing companies.
And of course you need to consider how much resources you have available to implement a solution that suites your needs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I've already run several times into the issue of creating a desktop client app for working with some server, and every time I ended with ugly code, which becomes just impossible to support after couple of releases.
I have highlighted the following key points:
All operations must be asynchronous, without any dummy windows for relative fast operations (i.e. less than 30 seconds)
App has to periodically connect with the server and check, for example, user account
All heavy operations must be cancelable
But, most important, all of this must be "naturally" in code, without creating unnecessary difficulties (singletons, hacks, etc)... only really needed code with minimal overhead.
How would you design such kind of app? What pattern would you use? What open source project with good architecture you can recommend?
This seems a little too broad, but instead of flagging I'll try and give an answer as I find the question interesting. I invite you to add more details if they come to mind.
Even though your design concerns the design of the application, there are a number of languages, patterns and technologies that would suit your requirements.
Keeping it general,
If your want your operations to be asynchronous, you are going to
need multiple threads. Their implementation and use may vary
depending on the language that you are using, but the concept behind
is the same. So, just spawn a thread every time you need an
asynchronous task, and implement a way to be noticed when the task is
done (with or without errors). This can be done in a number of ways,
since you asked for pattern I suggest you have a look at
observer.
The second requirement is not completely clear to me, I assume you
want to periodically check that the client's data is aligned with the
server's, and maybe perform security checks ("Are session and
authentication credentials still valid?"). The first solution is to
actually ask the server every n seconds, again using another
thread. This kind of polling might not be the best option though: how
do you factor in the possibility of connectivity issues? Even if your
client cannot operate without a working connection to the server, it
might bother the user to be disconnected and lose his work just
because his Wi-Fi router rebooted. I would suggest you perform
alignment checks at I/O, perhaps distinguishing between critical and
non-critical ones. For example, if you decide the user's profile
has to be aligned, then you would retrieve updated data from the server upon viewing it. On the other hand, if your app offers the
user a list of cooking recipes and you don't care about him not
viewing the one that has been inserted on the server 10 minutes in
the past, you could simply cache these items and refresh them in a
background thread every minute, without even noticing the user in
case the update fails. Last but not least, if you are also
concerned with concurrent modifications of data, again based on your
requirements you can decide to implement locks on data being edited,
to performs checks on save operations to see if the data has
changed in the meanwhile, or to simply let the user overwrite the
data on the server no matter what. All in all, hoping I interpreted
your question correctly, this requirement is nontrivial and has to be
adjusted to your particular use case.
Assuming the data is eventually saved on some sort of database on
the server, one answer are transactions, which allow you to
treat even complex sequences of operations as "all or nothing",
atomic instructions. You might implement your own system to have the
same result, but I don't really see the point of not using this
powerful instrument when possible. Keep in mind one thing: I'm
assuming "cancelable" means "cancelable before some point in time,
and not after" (a sort of "undo"). If you're looking for complete
revertability of any operation of data, the requirement becomes far
more complex, and in general not possible to guarantee.
I believed I already answered in a way that helps you minimize "hacks" in code where possible. To recap:
You are going to need threads, and the observer pattern can help you
keep the code clean.
Again, you can use threads, or focus on check on I/O operations. In
the second case, you might consider an application layer
specifically for client-server synchronization, embed it in one or
more classes, and perform all your checks there. Have a look at the
proxy pattern.
Use transactions to revert operations, and issue a COMMIT only
when you are sure that the operation is confirmed, a ROLLBACK in
every other case. Encapsule this logic in your server's code so that
the client is not aware of the actual transaction system being used,
and your code should be quite clean.
Please comment if my answer is not satisfying or clear.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have researched on each element or system that I am willing to implement into a generic software licensing system for my soon-to-be apps (irrelevant, as this should work, or be usable on all of my applications).
I have created a DLL with my licensing class in it.
It is as follows:
(1)
I have applied the InternalsVisibleTo() attribute main class (with child classes), which makes all of the internal classes, and their methods, which are declared Friend, visible to external assemblies with the sepcified PublicKey.
I have made the reference to the app name, and it's PublicKey. (Both the licensing, and the external assembly, are signed with the same key (.snk file)
(2)
All (where possible) members, properties etc. are delcared Friend or Private or just Dim...ed .
(3)
My licensing class has a String variable; declared:
Private Shared _Key As String = "H58N2-00V93"
This variable is the special password, if you will, of my DLL, and is required to access the methods in my DLL.
There is also a Public String variable (let's call it "AccessKey"), which should be initialized with the main class, like so:
Dim licDLL As New LicensingAssemblyName.LicensingMainClass With {.AccessKey="H58N2-00V93"}
(4)
Then, I have a Function (let's call it "CheckKey"), which checks whether the Public, initialized variable ("AccessKey" is equal to the pre-defined, Friend key ("_Key"), whereupon an exception will be thrown, if they are not equal - preventing method from continued/used.
(5)
At each first line of every Sub, Function etc., I have inserted a call to this function.
These are just the 'security' measures I've taken to prevent external assemblies from using my DLL in another app, to perhaps exploit the system or generate keys.
Now for the licensing measures.
(1)
I have a key generator (very basic), which generates codes upon a given format (Like: "#-$" for a number, a dash, followed by a letter.)
I have included an encryption class in this program, which uses Rijndaenal, and applies salt.
I have set the key generator to encrypt each separate key upon generation, then append it to a new line of a file, which we'll call "my_licenses.txt".
I use the same password for each one (obviously). It is quite long, and includes many different characters (if that makes ANY difference). I considered this to be a secure way since I didn't think ANYONE could decrypt a string without the password, until I was told by another programmer, who advised against using plain text encryption as a method to secure these keys. Please help me with this.
(2)
In my licensing DLL, I have a declaration:
Friend Shared Function IsKeyValid(ByVal KeyDB As String, ByVal Key As String) As Boolean
This function decrypts each key in the file (the specified database, using the same pass code used when encrypting them in the key generation program).
Then I do a For Each, Next loop to, determining whether the specified "Key" value equals any in the key 'database', "my_licenses.txt". But here's the catch.
I have an Function which returns a unique code for the computer it's running on (using hardware IDs etc.). This Function helps me protect against the use of the same key on multiple computers (unless I implement a system for allowing this, limited times) and is required as the last 5 characters of the "Key".
After checking, this Function returns a value of the result (True or False).
Finally (phew), each assembly (the licensing one, and any external ones which utilize it) are obfuscated -and likewise signed (all assemblies, with the same key (.snk) file)- by CodePlex's Confuser (A free, and highly recommended obfuscator for .NET).
I hope this hasn't been too long/not detailed enough/difficult to understand. (If so, tell me what you don't understand).
This is my first post/question of any kind, so be nice. Also thank you for reading.
I hope you can help.
And just to confirm, my question is this: Would this system be secure enough to protect against the average hacker?
P.S. I am only a beginner, so answers for a beginner would be especially appreciated ;)
*UPDATE: I have actually reduced the length of this question, and improved its understandability (believe it or not). So this is the best I can do.
That's an insane wall of text so you kind of lost me. And, to be honest I stopped reading seriously when I saw you had a hardcoded key inside the binary that you plan to distribute... But there are two questions you ought to ask yourself:
Is your application likely to be so successful that there is sufficient demand for it so that people with the appropriate skillset will be inclined to reverse it and release a keygen and/or pirated version?
And wouldn't your time be better spent adding cool features to the application instead of licensing code which does nothing to improve the application itself?
Don't get me wrong. I'm all for people getting paid for their work and I don't object to people licensing their software; as a matter of fact, one of the projects I worked on was a custom licensing engine which was tracking a little over 100,000 licenses last I checked. But make sure that if you decide to implement licensing that the effort you put into it doesn't exceed the effort you put into the actual software you're licensing.
With all that said, here's what I would do:
Generate a lot of licensing keys (using whatever format you want)
Hash those keys using something like SHA-256 or SHA-512.
Create an array (using whatever syntax is appropriate to your language of choice) that contains the key hashes.
Include the array inside your application.
With that setup, to verify a license, all you need to do is:
Hash the input using the same algorithm as before.
Iterate the array, comparing it with the result of the hash. If they match, the key is licensed. If they don't, continue.
If you get to the end of the table the key is not licensed.
Do not immediately exit the application if the key isn't licensed. Instead set a flag that prevents the use of important commands (e.g. "Save") or set a timer for 60 seconds plus a random number of to exit the application.
Compile and then digitally sign your application with Authenticode. Have the application itself validate the signature to try and discourage casual tampering.
If you are so inclined, you could even encrypt the hashes, although that is unlikely to help against the sort of attack that someone would mount against this scheme.
To be clear: this is not bulletproof (then again, no licensing mechanism is) and it's possible for someone sufficiently skilled to break it in a number of ways. But it's almost certainly going to be more than good enough for your project.
Security doesn't have an absolute value, it has to be measured against the payoff. If your app is holding some nuclear codes I'd say go pay a specialized consultant for this. If you're storing grandma's secret recipes - you're good to go.
I read the whole post and it's still not clear what's the purpose of the hard-coded key or how do you manage the individual encryption keys for each license: encryption is not just about how strong an algorithm you use or how long your password is; it's also about how do you hide your passwords, how do you transmit them, what do you do in edge cases (interrupted connection, failed decryption etc) and many other things.
From the looks of it I'd say you're in the "good to go" category only because your app doesn't sound like a high-profile target to crack and you mostly want to deter the casual cracking attempt from a frustrated developer who doesn't like your licensing scheme (: and the obfuscation alone would deter most when it comes to reverse-engineering your code. I'm not familiar with your code to tell if there's any other, easier ways to bypass licensing, such as the popular method of copying the licensing file itself if it's not tied to the machine or user profile...
There are many workarounds online, but only hashing system described here or something based on public key cryptography can be secure enough to serve licensing.
I personally prefer and use commercial product: http://www.treekslicensinglibrary.com - Treek's Licensing Library. It's cheap, easy to setup and really secure as it uses previously meant public key cryptography to work with license.
Edit: To compare with hashes of serial numbers - this solution does not require to predefine accepted serial numbers. 1000 hashes in apps = 1000 licenses, for more you need to update your app. Public key cryptography based license systems do not have this disadvantage.
You can use a .NET Obfuscate application to secure it. All .NET application may decompile with .NET Reflector, so search in your browser the application to obfuscate .net application. This will work as i know, everyone that want to decompile your application will prevent by the obfuscate
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am researching Key Management Solutions in order to become PCI compliant. I have spoken to a number of vendors in the arena, and while I like their products, the cost is beyond my budget. Is anyone aware of any open source or low cost solutions for Key Management? I use a Windows/.NET environment, so I would prefer solutions that target that environment, however I would be interested in hearing about anything that is out there.
Thanks
Take a look at KeyManager, which is the key management component of the OpenStack suite. The application can be used as a stand-alone key management solution outside of OpenStack.
Being a component of OpenStack, KeyManager is being actively developed with new features planned on six month cycles.
We had a similar experience as you. We needed a key management solution for PCI compliance and all the commercial products we saw were too expensive. Some key managers cost more than our product for small customers!
We ended up making a software based key manager. We made requirements and offshore developers coded it. At one time they were looking for other customers to use it. I don't know if they still are or not.
Let me explain the options we explored. First thing to remember is that PCI compliance and security are different things, you can be PCI compliant and not very secure.
Option 0 - Assign a key per DB column, and store keys in a DLL file. Your application links in the DLL file to access the keys to encrypt and decrypt the data. No one knows the keys. For periodic key replacement you make a new DLL with new keys, take down time to decrypt all data using old keys and reencrypt data using new keys. Then restart your application using the new DLL with new keys. (Note if you ever consider restoring a DB backup, you need to keep the old keys.)
The first time I heard about Option 0 I was surprised it was PCI compliant. We do not use Option 0.
Ways to improve on Option 0.
If you have an HSM in your environment, use the HSM to encrypt the keys in the DLL file. When your application starts it will decrypt the keys using the HSM. If you want more security, decrypt the keys every time they are needed.
Once your keys are encrypted, it is safe to store them in a DB table. If you assign each key (old and new) a small integer key-id, you can store the key-id with the encrypted data. That lets you do incremental key replacement and avoid down time.
Having your keys in the clear in memory in lots of processes, increases your exposure to a memory scan attack finding the keys. You can create a new process that is the only process that decrypts the keys. Your applications talks to this new process to encrypt and decrypt data. This new process should be on a box with a small "surface area" to protect it. Since sensitive data is going over the network now, this communications should be encrypted. SSL is a good option.
I realize this is an old thread, but there are couple of options:
A completely free and open-source key-management solution is at http://sourceforge.net/projects/strongkey. I will admit, the software is a little dated and is fairly complex to setup because it assumes you have a PKI to issue digital certificates to application clients for communicating with the key-management server, and for securing keys on the client device.
The original StrongKey software was simplified drastically three years ago and integrated into an appliance with a cryptographic hardware module (TPM and HSM) to provide stronger key-management. Unfortunately, even though the software on the appliance is all FOSS, the integrated solution itself is not free - its price is listed on its website (http://www.strongauth.com/products/key-appliance.html).
However, there are many advantages with option #2 as it allows you to leverage Public Clouds while being fully PCI-compliant (search for "Regulatory Compliant Cloud Computing (RC3)" and click on the link at IBM - I can only post two links in my answer) with more announcements about how to leverage this appliance being announced at RSA 2013 in San Francisco.
I hope that helps.
KLMS over KMIP is good and easy to use solution for key management.
This is an open source solution written in Java. See the below link for reference. http://www.ibm.com/developerworks/library/se-kmip4j/
The package named stubInterface will contains all the api required to use KLMS over KMIP.
KLMS: Key Lifecycle Management Systems
KMIP: Key Management Interoperability Protocol
I will add to this list as I found it in a search and others may benefit from an expanded list.
I have recently found KeyWhiz which appears to be in alpha.
SNipeit is the best one I have seen that is open source, very robust, and very easy to use, even for non-techies.
https://snipeitapp.com/demo/
Check it out there.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
After the user enters his / her license key, my application activates itself with that key (online). How do I store this activated state and the license key so that the next time the user opens the app, the app will know that it is already activated?
Apple provides a comprehensive facility for this kind of requirement. What you want is the Keychain API.
I just wrote the users license key and matching email to a file in "~/Library/Application Support/MyApplication/License.myApplicationlicense". I think this is better than using NSUserDefaults because the user will expect to be able to toss their prefs without having anything dramatic happen like having to re-register their application.
The file is just the contents of a NSDictionary written using writeToFile:atomically: and read using dictionaryWithContentsOfFile:. The contents are not encrypted but that is typically not important depending on how your license scheme works.
I would also suggest you take a look at AquaticPrime if you have not done so already. I decided to roll my own license scheme because I wanted license codes and not license files. In the end I feel I would have been better off sticking to AquaticPrime which is much more cryptographically secure than my own license scheme. When I had been using AquaticPrime during my beta I stored the license file in the same location mentioned above.
I suggest making the key dependent on a user specific thing, ie email or full name or perhaps a machine specific id if necessary. Then you can store it in the NSUserDefaults or a plain dot named file in the users home directory. This without needing to encrypt it or make some crazy obfuscation. There will be piracy be sure about it, I believe this is people who would never pay for anything anyway so you do not actually loose anything. By making the key dependent on a user specific thing makes the user a little more resistant to share it.
About piracy. How far do you think they can go? I made a small tool that worked fine without paying anything. But as a treat for those who would like to support the effort in creating it I added a small feature to change color of the graphs in it for only $5. Well, what did they do? Someone actually reverse engineered the key and they created a keymaker. I admit I didn't put too much effort in obfuscating the algorithm, but hey, I focused more on making it easy for all real nice users to input than making life hard for any cracker. I'm more happy about that they thought my little app was worth the effort to reverse engineer the key for.
Links:
Original AirPort Flow
Cracked Torrent
I've decided to use NSKeyedArchiver because it keeps the data encoded so it's harder to manually access and change sensitive data like license key and activated state.
You can either use NSUserDefaults or a system of your own devising.