Tag Info

New answers tagged

0

I try to avoid stored proc's if at all possible. But when I have to for security, my goal is a compromised approach. I use stored proc's for updating commands (INSERT, UPDATE, DELETE) and the ORM for everything else. Further, each stored proc does a single operation on a single table. The application code coordinates all of the calls and manages the ...


0

Modern Object Relation Mapping libraries, and even the lower level libraries allowing you to run SQL against the database, have guards in place to prevent SQL injection attacks. To use stored procedures because all other solutions are not secure is both short sighted and false. If you must hard code SQL, you can use parameterized queries, which guard against ...


1

Sprocs are very good for implementing a secure data access layer - you write sprocs for reading and writing data, and give the client execute access to the sprocs only - no access to the underlying tables or views. This gives your DB an API that clients use, in much the same way as any class implemented in your business logic code would, but much more ...


1

For casual protection, you can hash some identification fields (including the ID) and include the hash in the page. When the page is posted, you hash the fields again, and compare them with the hash stored in the page. Make sure it's a salted hash so that it's difficult for the attacker to recreate the hash algorithm and make their own fake hash. For ...


0

You want to use strtoll(3) (assuming long long fits, or is the same as, int64_t from <stdint.h>, which is almost always the case). It is able to convert hexadecimal, and it can set some end pointer to the first non-hexdigit character. But really, you should not have asked here. Please read some good C programming book or consult some C programming ...


0

What it sounds to me like you are describing is what package managers do: they take files from a repository, copy them to the target machine, and run scripts within them. This is usually done for the purpose of installation of software, but it doesn't have to be, so long as you are OK with their idempotency. They typically use a remote filesystem full of ...


4

Let's say you want to crack passwords which are stored as MD5 Hashes (This is very old technology). Since brute force takes a real long time, and this function is "non-reversible", then the attack is the Reverse Lookup table. The idea is that you create a table storing what you enter as input and the hash it generates. After you run your routine with as ...


0

Yes, you are correct, you can either treat the server as trusted and put an unencrypted (or encrypted with the password next to it) private key in the server to let the server do the signing itself or you treat the server as untrusted medium and do the signing on the local machine. The latter can't be done with JavaScript solution though, as the JavaScript ...


1

Nonce is used for just that it's a number, possibly passed in the message header and it can be only used once and the subsequent requests with the same number are rejected by the serve. For details on how the value is determined please have a look at the article.


0

Presuming the "hash phrase" is client-unique, your integration already entails a level of statefulness. It's not much more of a leap to provide the client with unique request tokens. The server can issue replacement token(s) as part of the response for each request. The unique request tokens can either be/replace the "hash phrase" itself, or simply operate ...


3

You're on the right track, but missing one key point: All validation/authentication must be done (or double-checked) by the server, because you cannot trust the client. Maybe you already had this in mind, but it's worth stating explicitly. And yes, you definitely need to do both 1 and 2. In principle the logic for 1 and 2 should be exactly the same. A type ...


3

Just to clear up some concepts first... I believe data access through a webservice provides security - I don't need to pass in the db server user name and password etc. I think you are conflating the concepts of (1) Transport Layer Security (TLS) and (2) access controls in the above statement... Whether a user name and password needs to be supplied or ...


17

Ah, back when we had sticks and stones. Before the Internet, we had something called "client/server" architecture and Local Area Networks. If you weren't trying to establish a connection with a server several miles away, these networks worked perfectly fine to accomplish most anything. You could even establish drive letters and use connections to file ...


10

Depending on what you call a web service. Before WSDL and REST, there was still HTTP, so basically everything you can do now could be done before as well. There was a lack of uniformity (which is why WSDL and REST were created in the first place), but it provided the same level of data confidentiality and security you are talking about. You can actually ...


0

The usage of permanent cookies depends on how you use it. It can be an asset for improving user experience such as automatic login etc.. But remember that leaving a cookie for a long time might even turn into a vulnerability. So it's best to set the cookie to remain for how long you actually need it rather than opting for permanent thing.


0

You need to store the API token in your sever and need to validate it in database for each API call , So when u need to revoke access , remove the API token from the database , so it will invalid during next call


3

As the other answers say, if you can see the binary you can reverse engineer the function of the program, although possibly with difficulty. The cutting edge is therefore to prevent the user from getting at the binary. Old arcade systems did this by storing the program or critical parameters in battery-backed RAM linked to tamper switches. Open the case and ...


3

Don't let anyone else access the program. Run it in a secure* server you control, and let users interface with it only by providing the input over the network and receiving back the output. See http://en.wikipedia.org/wiki/Software_as_a_service The downside is that you now have to manage the server. *Securing a server is far from trivial. For truly high ...


3

Remember me cookies are a special kind of cookie because they allow the user to bypass providing the authentication information, while other cookies may just track what pages you have been on or what is in your shopping cart as a non logged in (unauthenticated) user and aren't really risky except to the extent that such information is assumed to be private. ...


1

To make C almost impossible to reverse engineer? It is possible - write your C such that the entire logic is dependent on the input AT RUNTIME (perhaps now you have to protect your input, which hold the secret to your logic in the C program). So reading the C source code really has no meaning. How? One way: Using lots of function pointers. So ...


2

Possible? Yes. You should be able to download a word list (example) and compare each word's first five letters with your string, however it isn't going to be very efficient. IMHO. If you need to check more than a few words, then it may be useful to look into optimizations. For example, you could precompute a giant HashMap which contains all valid 5 letter ...


2

Simple, at least in the U.S. You just put an anti-reverse-engineering clause in the program's EULA, and threaten to sue the pants off of anyone who cracks it (this is no joke; the DMCA actually lets you do so).


10

Many anti-debugging techniques can be used to make reverse-engineering a hell of a task, but it's not impossible. Malware authors use them regularly, and many are applicable to any native machine code, including that compiled from C. A simple example that was really popular in the early years was inserting thousands of breakpoints to make running to a ...


2

If someone can observe the program in operation, they can reverse-engineer it. Even if you could somehow prevent the user from accessing the internals of the program, they can perform black-box reverse engineering to build up a model of how the program reacts to various inputs.


4

You can reverse engineer any program, the result will not be the original source code with comments, descriptive variable names, structure etc. but its functionality will be the same. You cannot prevent this, you can make it more difficult but you cannot not prevent it because at the end of day it will be instructions that the CPU will understand and thus ...


31

It is impossible to prevent reverse engineering for any program that runs on your computer. But you can make steps that make it harder... Program languages like Java and .NET are trivial to recreate human source code for, as they are byte code 'compiled'. Meaning the programming language is compiled into a set of tokens that are interpreted by a run time ...


15

Any program can be reverse engineered, because of the very simple principle that anything that a computer can execute has to be in a format where a person that understands machine code can read. (With the proper tools of course.) The real question is, how easy is it to reverse engineer? C is trivial to decompile; I've seen some surprisingly clean C code ...


6

Look at the source code of Guid.NewGuid method: public static Guid NewGuid() { Contract.Ensures(Contract.Result<Guid>() != Guid.Empty); ... } See the code contract? The Guid.NewGuid method never gives an empty GUID.



Top 50 recent answers are included