Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
According sites like apache signing a file (generating a checksum) using GPG is more secure than plain old MD5. I don't understand why most people use MD5 instead. Can some explain the real differences in plain technical English?
An MD5 checksum can be generated by anyone who has access to a file. An attacker who breaks into a site, or executes a man-in-the-middle attack, can easily change the MD5 checksum so it matches the compromised file.
A GPG signature, on the other hand, can (in theory) only be generated by the owner of the corresponding private key. If the signer is in your web of trust, the signature verifies the integrity of the file contents and demonstrates that the key owner vouches for the file contents.
Also, MD5 has begun to show some weaknesses in the last several years; GPG tends to use more up-to-date algorithms.
Probably MD5 checksums are still commonly used because they're easier. (SHA-1 is better than MD5, and is becoming more common.)
UPDATE (4 years later): MD5 should now be considered insecure, and distinct files with identical SHA-1 checksums have been demonstrated. There are better checksum algorithms, but I won't recommend a specific one; I suspect this answer will still be here after they've been broken.
Related
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 3 years ago.
Improve this question
We have a web service that needs a somewhat POSIX-compatible shared filesystem for the application servers (multiple redundant systems running in parallel behind redundant load balancers). We're currently running GlusterFS as the shared filesystem for the application servers but I'm not happy with the performance of the system. Compared to actual raw performance of the storage servers running GlusterFS, it starts to look more sensible to run DRBD and single NFS server with all the other GlusterFS servers (currently 3 servers) waiting in hot-standby role.
Our workload is highly read oriented and usually deals with small files and I'd be happy to use "eventually consistent" system as long as a client can request sync for a single file if needed (that is, client is prepared to wait until the file has been successfully stored in the backend storage). I'd even accept a system where such "sync" requires querying the state of the file via some other way than POSIX fdatasync(). File metadata such as modification times is not important, only filename and the contents.
I'm currently aware of possible candidates and the problems each one currently has:
GlusterFS: overall performance is pretty poor in practice, performance goes down while adding new servers/bricks.
Ceph: highly complex to configure/administrate, POSIX compatibility sacrifices performance a lot as far as I know.
MooseFS: partially obfuscated open source (huge dumps of internally written code published seldomly with intentionally lost patch history), documentation leaves lots to desire.
SeaweedFS: pretty simple design and supposedly high performance, future of this project is unclear because pretty much all code is written and maintained by Chris Lu - what happens if he no longer writes any code? Unclear if the "Filer" component supports no single point of failure.
I know that CAP theorem prevents ever having truly consistent and always available system. Is there any good system for distributed file system where writes must be durable, but read performance is really good and the system has no single point of failure?
I am Chris Lu working on SeaweedFS. There are plans to commercialize it. (By adding more advanced features.)
The filer does not have simple point of failure, you can have multiple filer instances. The filer store can be any key-value store. If you need no SPOF, you can use Cassandra, Redis cluster, CockroachDB, TiDB, or Etcd. Or you can add your own key-value store option, which is pretty easy.
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 4 years ago.
Improve this question
I just want to ask regarding transaction logs in SQL Server. We can take backup of those log files in .bak format at our any system location.
The problem is to extract SQL statement/query from transaction log backup file. We can do it using fn_dump_dblog function. But what we want is to extract the query or data on which transaction has to be done in logs.
I want to do it manually same as "apex" tool do for sql server. And don't want to use any third party tool.
Right now I am able to extract table name and operation type from logs. But still searching for SQL statement extraction.
Decoding the contents of the transaction log is exceptionally tricky - there is a reason Apex gets to charge money for the tool that does it - it's a lot of work to get it right.
The transaction log itself is a record of the changes that occurred, not a record of what the query was that was executed to make the change. In your question you mention extracting the query - that is not possible, only the data change can be extracted.
For simple insert / delete transactions it is possible to decode them, but the complexity of just doing that is too large to reproduce here in detail. The simpler scenario of just decoding the log using fn_dblog it analogous, but the complexity of that should give you an idea of how difficult it is. You can extract the operation type + the hex data in the RowLogContents - depending on the type of operation, the RowLogContents can be 'relatively' simple to decode, since it is the same format as a row at a binary / hex level on the page.
I am loathe to use a link as an example / answer, but the length of the explanation just for a simple scenario is non-trivial. My only redemption for the link answer is that it is my article - so that's also the disclaimer. The length and complexity really makes this question un-answerable with a positive answer!
https://sqlfascination.com/2010/02/03/how-do-you-decode-a-simple-entry-in-the-transaction-log-part-1/
https://sqlfascination.com/2010/02/05/how-do-you-decode-a-simple-entry-in-the-transaction-log-part-2/
There have been further articles published which built on this to try automate this logic into t-sql itself.
https://raresql.com/2012/02/01/how-to-recover-modified-records-from-sql-server-part-1/
The time / effort you will spend attempting to write your own decoding is sufficiently high that compared to the cost of a license, I would never recommend attempting to write your own software to do this unless you planned on selling it.
You may also wish to consider alternative tracing mechanisms being placed in-line with the running of the application code, and not something you try reverse engineer out of a backup.
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 9 years ago.
Improve this question
No doubt that, DBMS plays vital role in today's developer's life which is easy way of retrieving the data particularly when we don't require JOINS. But apart from easy factor, which is faster? Files or Databases?
Depends upon the situation. One might conclude that a filesystem is faster, under the belief that the DBMS must use a filesystem to store its data and therefore is only adding a layer of buffer. That is not strictly true as some DBMS (eg Oracle) implement and can use their own filesystem. One might conclude that a filesystem is faster, under the belief that system calls (eg fread() and fwrite()) have less overhead than a SQL call (eg SELECT *). That also is not strictly true, as the overhead from reading multiple files and joining multiple files may be less efficient than the DBMS implementation of data storage (eg btree in file).
The only way to know is to choose a scenario and benchmark it. As with any design, one must balance the tradeoffs: complexity of a DBMS vs ease of filesystem, ease of DBMS selection vs complexity of filesystem reads, etc.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm going to be receiving a username and password and storing it in a struct.
What can I do to prevent someone from viewing the memory for my process and seeing the users username/password?
My first idea was to encrypt the username and password in memory, and zero it when i'm done with it. But then I would have to store a key somewhere in memory, which could be retrieved.
Well that would make recovering the credentials very difficult, it's still possible.
Is there any safer method than this?
Take a look at the Data Protection API. It's used by Windows components as well as third-party software for exactly this kind of scenario, and basically handles the encryption and key management for you.
Keys are tied to the current user's password, but you can supply "optional entropy", which is effectively a per-operation source of extra key material, which might e.g. be derived from a password entered by the user to secure the service credentials.
As for "is there any method safer than this", I think you need to define exactly what level of threat you're trying to protect against. For other (non-admin) users on the same machine, DPAPI is probably perfectly fine, along with things you've already mentioned like securely zeroing plaintext. For malicious software running in the same login session, very little will help you.
The simplest solution would be to scatter the password around in memory. Don't store it as a string. Declare a set of byte variables and scatter the password among them. This doesn't make the password irretrievable, but it makes it difficult... the attacker needs access both to the computer and to your source (or reverse engineering your binary) to discover how and where the bits of the password are stored.
If the attacker has access to your system and your source, or the ability to reverse your binary, you'd be just as well off to e-mail him the passwords.
The more likely angle of attack in your scenario would be to grab the password in the act of being passed to the service than to try and assemble it from memory.
EDIT: If you want to significantly increase the difficulty of gathering the password, you could use dynamic memory allocation, as well, to prevent the bits from having a fixed location in memory. But, honestly, that's overkill... it would be just as easy for the attacker to snag the password when you're passing it to the service.
Hash the password with a good function (e.g. SHA1/2) and store the digest. When you want to check the password against the stored one, hash the input and compare the result with the stored one.
Basic property of a cryptographic hash function is that it's a one-way function: it's very hard to compute the inverse function. That's the reason these functions are used in situations such as your's.
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
By best I mean more time tested, easier to implement and easier for the users to work with. I do not want my licensing crap to interfere with their work.
I was thinking of launching a WCF service that check with my license DB if it's a valid license and if it is, send a True.
If the returned response is False, then shut down the program after telling them to fix their license.
Do you think this is a good way to handle it?
You will need to develop or find an algorithm that creates sufficiently complex strings for your license keys.
Generate the license key based on some bit of information unique to a user, like their E-Mail address.
Your program would then require the user to enter their E-Mail address and license key. It would then ensure the license key is correct by running the same algorithm you did to generate it in the first place.
The approach i have used in the past is a simple one but effective. I generate about a 1000 keys to my software and run them through a hashing algorithm. I then include them within my program (maybe as an array which takes up little space)
I then give out one unique key of the 1000 generated to each customer and when they enter that into my software it is hashed with the same hashing algorithm and compared against the included hashes. If it compares true you are registered so save it in your config file.
Every so often i update the program by another build number and recreate the keys and hashes included in that build. You just have to keep track of what keys go with what build, but you can control this with a nice database, etc.
Never had any trouble with this system as it can all be fully automated.
You could try generating license keys strings using the user's name + dob + user-selected-password.
OR
Use the user's h/w serial numbers and give them a license key online post install. I am assuming at this point only one computer per license is allowed.
Pinging the web service will not work if a net connection is not available. You should use a combination of pinging and a grace period. If a customer cannot validate/activate the license within 'X' number of days, THEN you declare it as unlicensed.
Try CryptoLicensing which supports this scenario.
I suggest you take a look at OffByZero Cobalt (obligatory disclaimer: it's produced by the company I co-founded). You're better off buying an existing proven solution than rolling your own.
As we point out in Developing for Software Protection and Licensing:
We believe that most companies would
be better served by buying a
high-quality third-party licensing
system. This approach will free your
developers to work on core
functionality, and will alleviate
maintenance and support costs. It also
allows you to take advantage of the
domain expertise offered by licensing
specialists, and avoid releasing
software that is easy to crack.