Tag Info

New answers tagged

0

should I make the API retrieve an auth token or the users password before the details are updated? NO because I am assuming that this backend app will be used mainly by the web admins/operations and why should they have access to the user's password or auth token? Also, whoever is going to use this app must login to the system themselves and you ...


1

Biding your applications to your AD can be done by using a single sign on solution (Web seal) such as (among several others) IBM Tivoli Access Management. This requires you to create the objects accounts (users, systems and computers), set the permissions through groups, implement the web seal login and an authentication interface for every single target ...


1

It's very hard or impossible to exploit this vulnerability over the network as Nic Barker already stated. I want to mention that it's best practice to define a lockout threshold for authentication mechanisms. For example: If a client authentication fails for the 7th time, further authentication for this client is blocked for at least 5 minutes. If a lockout ...


0

How feasible the attack is depends on how much noise you have to remove to get to the signal you want to have. If you can do a lot of tests against the website you should be able to increase the level of signal which might be enough to filter out enough noise to make this kind of attack feasible. But details depend a lot on the actual setup of the system you ...


1

While this is certainly a very interesting idea, in practise I think it's pretty much impossible to exploit. We're on a fiber connection here, and even the response time direct to our ISP is all over the place: If the difference you're looking for is a few nanoseconds, you'd literally have to already have access to the local machine to even begin to hope ...


2

Yes, using MD5 is safe. When a client wants to authenticate, the server sends a random salt value. The client uses that value, along with the password to generate a MD5 hash. Because a random salt is used, an attacker can not use a dictionary attack. Also, because the salt is changed each time a client authenticates, this is no ability to replay old ...


1

You should look not into IDS technologies but Database Activity Monitoring (& Prevention). DAM(P) software shims itself in to watch all SQL queries and results and uses a combination of generic rules and guided knowledge to detect and in some cases prevent inappropriate use. An IDS will catch SQL injection, which is more specifically aimed at web ...


4

How data is related or not within the database has nothing to do with SQLi. Flat files, NoSQL, etc. will not affect the ability for a user to perform unauthorized access to data. SQLi is about unsecured direct access to the database (in whatever form that is), resulting in a user manipulating that access in order to obtain data without the expected ...


1

In general, if you lock down the requesting IPs, the DB authentication requests will never hit the DB, so you won't have to worry about a DOS attack on the DB directly. With AWS specifically, you have the ability to take advantage of a VPC. This is sort of like a VPN but instead you could provide the 3rd parties with their own server endpoint inside of your ...


1

Taking AES-128 as an example, you have a 128 bit key. The "stupid" brute force attack would require you to check every possible 128-bit key until you get back plain text that makes sense. There are 2^128 possible keys and hence the complexity of brute force on AES-n, where n represents the key size is O(2^n). Now obviously there are ways to constrain the ...


0

If you are going to go down that route a key derivation function (KDF) from the users password might be the way to go. That way the encryption keys are generated from the user's input so you would not have to store any of the keys. However this also runs into the issue that if the user cannot remember his or her password the data will be lost and KDF's can ...


3

One of her key requirements is, that the data stored will be encrypted in a way that only the user will be able to access it. The only way to truly guarantee this is to have the encryption key reside on the client, under the control of the user. This introduces (at least) two problems - Having a thick enough client to support key management and ...


1

The tool NoSQLMap includes a lot of functionality that directly targets MongoDB. https://github.com/tcstool/NoSQLMap There is an even-better video available that shows all sorts of attacks. You will also find that NoSQLMap calls out to the metasploit-framework, e.g., exploit/linux/misc/mongod_native_helper The project also suggests a viewing of this DEF ...


0

In addition to the excellent answer given by Thomas Pornin in the linked question, I would add that for security reasons in your case you probably want to do some hashing on the client side, and some hashing on the server. The reasoning goes like this: Pros of server-side hashing: Lets' say you only do client-side hashing, then you are taking the string ...


0

I would definitely hash before the upload. If a user device is connected to a network with someone sniffing packets, a plain text password being uploaded is easily read. Not very secure.


-2

The answers about encryption are not wrong, but the approach is wrong. You should not encrypt. You should use a one way hash function. This means that you do a NON-reversible mathematical operation on the password, and store the result. When someone wants to log in, you perform the operation again on the password they supply, and compare it to the result on ...


0

If you are looking for details, RFC 4880 describes all the details for implementing OpenPGP, which as far as I can tell is the most common method of encrypting data with one key (KEY1), encrypting that key with a second key (KEY2) to generate an encrypted key ("Enc_KEY1"), storing both the encrypted data and the encrypted key. Later only people who have (or ...


2

Whenever you have a human password and want to process it into some format that "leaves traces", then you need to do it with a function that is resilient to brute force (e.g. PBKDF2). You thus need to do that when you hash the password to obtain a password verification token that you store; you also need to do that when you are turning the password into a ...


1

The string length of a bcrypt hash isn't compatible as an AES key because of length and illegal characters such as periods and dollar signs. How does one deal with this problem? Base64 encoding is your friend. Base64 encoded character are all legal characters with AES When it comes to decrypting Enc_KEY1, I have to first generate KEY2 from a hash ...


0

Here a list of mitigation actions you can perform to avoid disclosing the database's path: Internet Information Services & Server Make sure you do not list the C:\inetpub\wwwroot content, otherwise s/he might be able to navigate through all folders Disable any kind of FTP and just use SSH (if needed at all). Needless to say that FTP is insecure. Keep ...


2

So assuming here that the database is only intended to be accessible by the ASP code and not clients of the web application a better alternative to keeping the database in a "random" directory under the web root, would be to keep the database outside of the webroot altogether. That way it would not be possible for an attacker to directly address the ...



Top 50 recent answers are included