Manage API key on mobile platform As I am currently working a lot with mobile applications a question arised:
How to properly store and transmit API keys within mobile applications?
When I analyze mobile applications most of the times it is easy with the right tool to extract secret information (e.g. dump the keychain, reverse engineer crypto functions, detect hardcoded secrets with static analysis, ...) from the app. Therefore often is is possible to get a used API key at rest.
The other way is to monitor the traffic and perform a MITM attack.
Therefore the API keys can often be sniffed at transit. Even if certificate pinning is used, there are easy ways to circumvent client side mechanisms like that.
Now I would like to get a understanding how to mitigate the risk, that someone like me can have access to these used API keys. What is the best practice to communicate via a mobile app with a remote API, that requires an API key?

My congratulations. You seem to be a very informed developer in terms of security and that is always good to see :)
The Difference Between WHO and WHAT is Accessing the API Server

Now I would like to get a understanding how to mitigate the risk, that someone like me can have access to these used API keys.

First I would like to clarify a usual misconception that arises often among developers of any seniority level, that is about knowing the difference between who vs what is in an API request.
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

So, think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
Now, I hope we are in a better mindset to find some possible solutions to your questions.
Locking Down the API Backend to the Mobile App

How to properly store and transmit API keys within mobile applications?
What is the best practice to communicate via a mobile app with a remote API, that requires an API key?

So, usually mobile apps use the API key to identify themselves to the API backend, but this not enough for the API backend to have a very high degree of confidence that the request is coming from what it expects, a genuine and unmodified instance of the mobile app.
Depending on your budget and resources you may employ an array of different approaches and techniques to defend your API server, and I will start to enumerate some of the most usual ones.
You can start with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution.
Google reCAPTCHA V3:

reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.

...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.

WAF - Web Application Firewall:

A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.

UBA - User Behavior Analytics:

User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.

All this solutions work based on a negative identification model, by other words they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite of the advanced technology used by some of them, like machine learning and artificial intelligence.
So, you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that this solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at same time they are properly keeping at bay the attackers.
A Possible better solution
Regarding APIs serving mobile apps a positive identification model can be used by implementing a Mobile App Attestation solution that attests the integrity of your mobile app and device its running on before any request is made to the API server.
I recommend you to read this StackOverflow answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
In a nutshell, the Mobile App Attestation solution will allow the API backend to identify with a very high degree of confidence that what is making the API request is indeed a genuine and unmodified instance of the mobile app.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10

The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.

For Mobile Apps
OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

OWASP - Mobile Security Testing Guide:

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.


Stateful Signatures in an IPS I am researching IPS devices and their signatures both stateful and stateless. The test network I am looking to implement the IPS in has asymmetric traffic so stateful inspection would be nearly impossible. What percentage of threats can only be mitigated from stateful inspection?

If I were to turn off stateful inspection on the IPS what threats am I leaving the test network open to?

Stateful network intrusion detection, and even more so prevention, is a tough task in face of multiple upstream links. When traffic can flow in at one link and exit at another, a single monitor cannot reconstruct end-host state effectively. You can either accept this situation with all its implications (e.g., mediocre protection at best) or resort to a distributed solution that propagates state amongst the nodes.

Ideally you would push the monitors to the network edge [1], but it sounds like you have no control over the edge. Without detailed understanding of the network topology, this is a hard question to answer. For the remainder of this answer, I assume that you have at least the ability to deploy several monitors in your network to approximate the ideal of inspecting all upstream traffic.

The NIDS Cluster

The Bro network security monitor has a cluster mode, where a node can propagate state to other nodes. For example, when node A sees a FTP control connection, it may propagate this information to node B, so that it knows how to interpret the following high-port data connection. Another scenario where this comes in handy is distributed scan detection. If you have an infected machine in your network that performs outbound scans through multiple links, each node may keep a local counter and exchange it regularly with other nodes. For a more detailed analysis of state exchange, have a look at the NIDS cluster paper.

Scalability

This cluster approach scales well do to the following insights:

The granularity of analysis and clustering is an entire connection. As long as you can ensure that packets belonging to the same connection end up at the same cluster node, you get good scalability. In single-upstream environments, a frontend typically slices the input traffic to achieve this constraint. In medium-sized networks, a Click router that rewrites MAC address often suffices, but larger environments often have to use dedicated high-performance devices. Our research group has very good experiences with cPacket CVU frontends, which can load-balance multi-10-Gbps links at line rate without dropping packets.
The size of the exchanged state is typically orders of magnitude smaller than the traffic a node observes. For example, if one nodes observes an big ISO image download, it will not propagate the very ISO image to other nodes, but for example just the name of the ISO image. Moreover, intra-connection analysis are already stateful, e.g, Bro follows the TCP state machine and exposes the HTTP message pipeline to the user.

Applying this to your scenario is a little more complicated, because you do not have a single upstream link. In order to scale well, you need to ensure that traffic from the same connection is inspected by the same node. In other words, the notion of a frontend is a little bit blurry because you have to manually route the packets to the corresponding cluster node. The exact overhead of this approach depends on your concrete topology.

[1] This does not preclude defense in depth. Adding more monitors at the core is a good idea as well, for example when no "roadwarrior" subnets are established to isolate mobile devices.


Convert SHA-256 to SHA-1 and MD5 - Increase bit length/entropy? I know this is a real dumb question and I am certainly talking complete rubbish, but let me explain:

We have a long SHA-256 hash, e.g.:  474bfe428885057c38088d585c5b019c74cfce74bbacd94a7b4ffbd96ace0675 (256bit)
Now we use the long hash to create one SHA-1 and one MD5 hash and combine them.
E.g.: c49e2143913627ea178e66571189628a41526bf3 (SHA-1; 160bit) + 6bb225025371aaa811748da8e011773d (MD5; 128bit)

So now we got this:
c49e2143913627ea178e66571189628a41526bf36bb225025371aaa811748da8e011773d
(SHA-1 + MD5; 160bit + 128bit = 288bit)

And it is longer than the input string, with 288bit instead of 256bit. So did we actually increased the entropy?

In short this is this:

hash = sha256(input) # 256bit
result = sha1(hash) + md5(hash) # 288bit

(That is supposed to be pseudo-code, don't know if it is valid through.)

What is the error in reasoning here? I am sure you cannot increase entropy/string length in this way...

Edit: Also important: Did I possibly even decreased the entropy this or stayed it the same?

And it is longer than the input string, with 288bit instead of 256bit. So did we actually increased the entropy?

No, you did not increase the entropy.

In this context, "entropy" basically refers to the probability of any particular guess about the content or value being correct.

If I tell you that I have hashed a single lowercase US English letter's ASCII representation using SHA256, and that the hash is hexadecimal ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb, then the entropy of that value isn't 256 bits, but rather closer to five bits (log2(26) ~ 4.7) because you only need to make at most 26 guesses to arrive at the conclusion that the letter I hashed was a. (For completeness, what I really did was printf 'a' | sha256sum -b on a UTF-8 native system.)

The entropy, thus, can never be greater than that of the input. And the input is, at best, the initial hash, which has 256 bits worth of entropy. (It could have less, if the string you hashed has less than 256 bits of entropy and the attacker can guess that and its value somehow.) Each hash calculation can be assumed to be O(1) when the input size is fixed.

So by concatenating the SHA-1 and MD5 hashes of a string that is a SHA-256 hash, you can never get more entropy than 256 bits' worth. All you are doing is making it longer, and possibly obscuring its origin.

Now, in some situations, using multiple hashes actually makes sense. For example, many Linux package managers use and validate multiple, different hashes for the same file. This isn't done to increase the entropy of the hash value, though; it's done to make finding a valid collision harder, because in such a situation the preimage or collision attack must work equally against all hashes used. Such an attack against a modern cryptographic hash is already difficult enough for most purposes; mounting a similar attack against several different hashes simultaneously would be orders of magnitude more difficult.


How can I safely back-up files from an infected computer? Imagine a laptop that's been infected by malware, and that the owner hasn't backed-up their files.* They have pictures, videos, and documents they'd like to preserve, so they're hesitant to immediately nuke it from orbit.

The objective is to back-up the files they wish to keep before wiping their machine, but how can they know that one of their files isn't infected? A common suggestion I've seen here is scanning said files after moving them to an external hard drive, for example, and then moving them back to the machine which has just been wiped. In this case, the concern is the malware evades detection and restoration reinfects their computer.

How can the user safely back-up files from an infected machine so that they avoid reinfection when transferring them to a clean machine?

*By "files," I mean documents, images, video, programming projects, etc.; not system files, like registry settings and scripts.

"How can they know that one of their files isn't infected"?  You can't.  Well you can if you get down into the bits of the file, but that's pretty tedious and expensive.

If you have an idea of the date the device got infected, files not altered before that date stand a higher chance of not being infected.  That's not a guarantee, because changing a file's date isn't hard.  So even that's not foolproof.

Really the only halfway decent option is to scan the file, copy it to an external drive, then scan it again and copy it back.  Odds are that it's a generic and not a targeted infection.  By waiting a couple days, to give AV vendors time to update their virus definitions, you stand a better chance of removing the infection when you move and scan the files.  That's not 100%, though - unless you know the infection and that the AV in question resolves the infection, you could set yourself up for a reinfection.

The only safe alternative is to wipe everything and have the user buy an external hard drive.  Then they should use it regularly to back their files up.


Multi factor authentication on Ubuntu workstations, where to start? Is it possible to have Ubuntu users log in with multi-factor authentication? I was thinking of a combination of pass(word|code) and smartcard (with screen locks when for example smart-card is removed)

Are there any libraries/apps present in Ubuntu that support multi-factor authentication? What would be good resources to find more about this?

Duo Security's open source duo_unix project demonstrates how to do this with PAM and sshd (and Duo's two-factor service).  Disclaimer, I am a Duo engineer.


Is drag-and-drop safer than using the clipboard when it comes to protecting sensitive data from keyloggers? I noticed that multiple password-locker applications recommend that you use the drag-and-drop feature to transfer passwords to login forms instead of copying the passwords to the clipboard or having the password locker type the password for you using simulated key presses. The basic argument its fairly easy for a keylogger to record key presses or to peek inside the contents of the clipboard.

I know that nothing can totally protect your data if your computer has been compromised but is it true that its harder for spyware to get the password if its transferred using drag-and-drop?

Though it's better in the sense that communication is automatically between two windows (and you can hope the object disappears after it's transferred), I'm voting no¹ because:

It uses Automation, its interface is public
It's not thread-safe (so it's global)
Windows in Windows can be hooked

The only protection I saw was at the process level: you can't DnD from a non-elevated process to an elevated one (prevents shatter attacks).

¹ I don't have a Windows system to test on so I'm just referencing things that seem to disprove it.


*NIX shadow file password format I'm trying to get shell access to a router and have managed to retrieve its /etc/shadow file:

root:$1$$N76hdwGfg11g0KdKbtyh21:0:0:root:/root:/bin/bash

I've tried to use john to crack it but couldn't:

$ ./john --show passwd
0 password hashes cracked, 1 left

I've also made a test account and managed to crack it on ubuntu/debian:

$ ./john --show passwd_test
testtesttest:test:16626:0:99999:7:::

1 password hash cracked, 0 left

where testtesttest is the user and test the password.
What format is the password hash in?

Edit:

Found it here. It would be nice to know its format though.

The most common format for hashes on Unix-like systems has the form $ALG$SALT$OUTPUT where ALG is a small number identifying the algorithm, SALT is a salt for the hash and OUTPUT is the output of the hash function. SALT and OUTPUT are encoded in base64.

Algorithm 1 is “MD5 crypt”, a construct based on iterating the MD5 hash function. This algorithm was not (and still isn't, as far as I know) defined by a formal standard. It was introduced by Poul-Henning Kamp in FreeBSD in 1994.

Normal APIs add a salt. The original implementation forced a 48-bit salt. The iteration count is fixed to 2477, which the author benchmarked for 34µs on a high-end PC of the time. Your hash has an empty salt, which is unusual and required the developer or administrator who configured it to bypass the usual tools and probably call a library function directly.

Current Linux systems usually use algorithms 5 and 6, which are based on iterating SHA-256 and SHA-512 respectively. These constructs are broadly based on the same principle as PBKDF2, but compute the iterated hash differently.

You can find a wealth of information about password hash algorithms in the documentation of the passlib library, and of course the library gives you Python implementations. This algorithm is passlib.hash.md5_crypt.


Shimmers inside chip and pin devices Recently shimmers made a lot of noise in the news and became popular to be installed in ATMs as they are very small.
Can they be installed inside chip and pin devices? Or where else can they be installed?
How to protect yourself from it?

UPDATE: By chip and pin devices I meant a type of chip and pin devices that are small and typically used to pay in restaurants, shops, etc. - POS terminals.

Like the one on the picture:

Its not possible to "skim" a chip'n'pin card in the regular sense, as the card does have a encryption key (EMV), that is used to calculate a response to a challenge sent from terminal, which will both be verifyed by the bank. The key is known only by the bank and by the card.

The name "shimmers" came from a portmanteu of the word "shim" and "skimmers", shim refers to something thin, think padlock shims that are used to open spring-loaded padlocks. The "skimmer cards" are so thin so they fit between the actual payment card and the reader.
Such "smart card" shims are used also to illegally tamper with operator-locked mobile phones so they can be used with any operator. (basically, the shim will reside between the operator SIM and the phone, and "lying" to the phone that a SIM from the right operator is inserted)

However, there is 2 cases where a chip card can be misused, despite the security features:

1: Its possible to skim the details of the cards, EXCLUSIVE the CVV, as these are stored in clear-text on the card (its mainly required to store these details in clear-text as the bank must know which encryption key to use to verify the result of the transaction). This card number and expiry date can be used at any web shop where CVV is not required.

However, such a transaction would be easy to dispute, as according to standards, a initial transaction MUST have a CVV unless its a recurring transaction (CVV may not be stored anywhere). A bank can easily verify if you had any initial CVV enabled transaction with that merchant. (even if the initial authorizing transaction is later cancelled because the merchant don't want to charge right now, it still counts as a initial transaction)

Also, the merchant also very often takes the hit if VbV/3Ds is not used.

2: If a merchant does not have a valid online connection, the extra high security of the chip cannot be used. Instead a "offline transaction" will be used, where the card reader assert it has verified the PIN (or performed a signature transaction) correctly against the smart card, and supply a static signature/authorization code to the bank. Since the card reader has no means to verify a genuine card was used, it either has to deny all cards (so no goods are given to someone with a fraudulent card), or the bank has to accept all cards, including fraudulent ones (so a genuine card holder cannot use a fraudulent copy of his own card to gain goods and then claim he don't know anything of it).

This means, its possible to clone a chip card and use it in a offline terminal, along with the right PIN, or by signature.

The main defense to this is to require online verification of cards. Normally, a terminal is set to only allow a certain number of offline transactions before forcefully going into online mode (eg, refusing to process offline transactions). This number is then set by the aquirer, depending on the agreement with the merchant. In some cases, the terminal can request phone authorization, where the card will be validated "online" via a phone call made by the merchant.
A issuer can also require online verification by setting certain flags and bits in the static data portion of the card, then a terminal that lacks a connection will refuse to process the transaction. (This can be set specific on transaction amount, and differently if PIN, signature or no cardholder verification is used)

Note that a "online only" card can STILL be used for offline processing if a terminal is incorrectly set up, eg not following the EMV standard. A bank that conforms to the EMV standard should then refuse to process such transactions, as the merchant was told at processing time that the bank will not accept offline transactions.

The article that was linked, refers to this second method. With "not verifying the dynamic CVV value", it means basically that the bank allows transactions to be processed offline, either by allowing offline transactions based on the flags, or processing offline transactions even tough the card's flags tells that it may only be used online.

Note that for offline transactions, CVV is never verified, not even magstripe CVV for a mag transaction. The reason is for the same reason I outlined above - if the cardholder modifies the CVV value on the card or produces a counterfeit copy of his card, the cardholder could then purchase goods and then claim the transaction was made with a counterfeit card, and then not having to pay for the goods.

Thats why an transaction with an invalid CVV or cryptogram response, that was made offline, MUST go trough if the card's flags indicate offline transactions is permitted, regardless of the validness of the response.
(The invalid CVV or cryptogram response can however be used to automatically block* the card for future transactions)

*And same here: A bank MUST process a transaction made offline, on a offline permitting card, even if the card is barred (eg, you called into the bank's hotline and told them you lost your card) until a specific time passes. Theres a set limit of time that must pass before the card is definitely barred, this time is the interval the merchant has to update its blacklist. This is why transactions may appear on your account despite you have called and told them you have lost the card. The list of lost cards must be distributed to every offline terminal, and those might only be recharge its list of lost cards each 6/12/24 hours.


Security in Windows Update Procedure? Assuming I have Windows 10 and updating Windows, how does Windows verify the integrity of the downloaded packages and how does the the download procedure work? I know that in Linux the packages are checked with checksums. But from where it will be checked? From the official download website or does the paketmanager do it by her own? And where can I find the downloaded packages and take a look at the hashes? Can someone explain me the Windows Update Procedure please?

Many Thanks

As far as I know:

Windows 10 is using a technology called Unified Update Platform (UUP).
This Service works with differential download packages.
A differential download package contains only the changes that have been made since the last time you updated your device, rather than a full build.

How does it work:

The UUP Service sends a list with all installed Updates to UUP Cloud Service (the Azure Cloud),
the Cloud Service merges the list with the latest update list and tells the UUP Service if there are any new differential packages.
The UUP Service starts Downloading these differential packages.

You can find the downloaded differential packages in the C:\Windows\SoftwareDistribution\Download folder.

Source: https://blogs.windows.com/windowsexperience/2016/11/03/introducing-unified-update-platform-uup/#cD5BkKJkUTT2vory.97


PCI DSS 3.0: 11.3 - What happens if a low risk vulnerability prevents compliance with another requirement? As I understand the PCI DSS 3.0/3.1 penetration testing requirements, a company is compliant with 11.3 if the penetration test does not return any high risk vulnerabilities.

However, what happens if a low risk vulnerability identified during the penetration testing affects a requirement outside of 11.3? Is the company considered to be non-compliant?

For example, discovering an internal IP address is low risk from an external perspective, however this would affect compliance with 1.3.8, which states that private addresses must not be disclosed.

Yes, you are responsible for addressing any gaps that you are aware of. It does not matter how you became aware you had a 1.3.8 violation; you're responsible for remediating it. The fact that it doesn't meet the threshold for remediation under 11.3 is not relevant.


If my company receives credit card statements showing credit card number, does it have to be PCI compliant? I understand PCI requirements on the storing, processing and transmitting of credit card information (PAN, expiration date, no on CVV, etc.).

However, I found nothing about receiving PAN (no expiration date, no cvv, etc.) ON document format (PDF). A good example of this is the credit card statement that the cardholder usually receive via mail or in electronic format (PDF downloaded from the bank website).

If I store these credit card statements in my computing environment, do I have to be PCI compliant? The statements will be in PDF format and only show the PAN and nothing else (no CVV, no expiration date, no magnetic stripe, etc.)

Yes, your company needs to be PCI compliant.
It doesn't matter if your customer's credit cards are stored in that format or the other (PDF\in DB \ paper ...) as you wrote as long as you store transmit or process you are required to be PCI compliant.

regarding your question in the comment regarding "I don't even know if storing such document requires me to be a Merchant or Service Provider"
than the answer is you are a merchant and you might be considered as a Service Provider for your customers PCI compliant under requirement 12.8


Multi flows snort rule Is it possible to write a snort rule that match on 2 different flows?

For instance on a communication from host-a <--> host-b that happen at the same time as a communication on host-a <--> host-c ?

The short answer is "no."  Snort primarily operates on a stream-by-stream basis.  But it would help to know specifically what you're trying to do.

If you only want to generate a single alert when both events happen and those two events are dissimilar, you cannot do this with a text rule.  However, if you want to detect that host A does the same thing to host B and host C at the same time, you could use detection_filter with track by_src to see that the host is doing something it shouldn't.

The long answer is that you can do all sorts of things using shared object rules and abusing the power and flexibility that they give, but explaining this on a Web forum would be difficult.


SQL injection can bypass login but not drop table I've setup a test environment for running some SQL Injection against my code and learning how to defend against it. I can bypass the login form using the following in the password field:

' OR username = 'admin

Which gives me the query:

SELECT * FROM customer_data WHERE username = '' AND password = '' OR username = 'admin'

This works fine but I'm having trouble with dropping a table. I've tried various attempts along the lines of inserting something like this in the password field:

OR '1' = '1'; DROP TABLE temp; --

I created a table called temp just to try it against but nothing I can think of has worked. If I login to the PHP MyAdmin (same credentials as the page is using) I can manually insert the query that would be constructed above and it works just fine.

Answering your question
mysql_query() doesn't support multiple queries as documented:

  mysql_query() sends a unique query (multiple queries are not supported) to the currently active database on the server that's associated with the specified link_identifier.

Which means that DROP TABLE temp; -- is never executed.
It is although possible if you use mysqli::multi_query or using PDO.

Best practice

Warning ?
You see that big red warning box ? The mysql extension is in process of deprecation and will throw warnings as of PHP 5.5.0. There are even plans to drop it completely in PHP 5.6 or PHP 6.0source. Note that mysql_ isn't broken as Ángel González stated:

  The extension is not broken. The problem is the bad usage. It can be used safely, and good developers have been doing so for ages, by creating php wrappers. In magic quotes, the work has been the opposite. The developers had been detecting the feature in php and disabling it.

The new standard
The new standard is MySQLi or PDO. I won't compare the two extensions here but there are really a bunch of good features especially from PHP 5.3+ which will save you time and efforts. Note that by using MySQLi/PDO won't protect you per se from SQL injections. The best option would be to use prepared statements. The data is sent separately from the query thus making it impossible to inject values. This is well explained by Anthony Ferrara in this video.

Be careful
But wait "impossible" ? That sounds just too great :)
Say for example we have two groups: group1 & group2. There is a certain php file deleteUser.php getting an id from $_GET.The prepared statement looks like this: DELETE FROM users WHERE id = ?. When the query is made with $_GET['id'] the user with ID = $_GET['id'] will get deleted. Hey, but that means that users from group1 could delete users from group2 by using that ID which isn't intended. So we may edit the query in something like DELETE FROM users WHERE id = ? AND group = ? and sending the user's group name he's in along with the query.
Short: prepared statements won't protect you from logic flaws.

Multi query ?
You don't need mutli queries. If you want to do two things then do it separately, it will give you more control over your queries and make your code more readable.

On another note:
If you're dynamically making and droping tables you're most likely doing it wrong. You should design your database in such a way that this isn't needed. Of course there may be exceptions but they are mostly busted since you may then look for a NoSQL solution (other db engine).

TL;DR

Stop using mysql_ functions and step over to MySQLi or PDO
Use prepared statements, note that it will not protect you from attacks if you don't secure the logic behind it
Don't use multi queries
Make a good DB design
If you want to train your hacking skills, you may check Vulnerable OS's?


How can I generate a .gpg file for verifying Putty? I downloaded the Putty installer from ssh.com, which said

  To import the signature key into GPG, use:

  gpg --import putty-release-2015.asc

  To check the signature of a file, use:

  gpg --verify <signaturefile> <datafile>

  For example:

  gpg --verify putty-64bit-0.70-installer.msi.gpg
  putty-64bit-0.70-installer.msi

Running the first example command worked fine. I used gpg --list-keys to verify that I have the release key from Putty's website.

The second example command gets me

gpg: can't open `putty-64bit-0.70-installer.msi.gpg': No such file or directory

I looked at the signature verification manual from GnuPG, but unless I am supposed to find a detached signature, I don't see where that .gpg file is supposed to come from.

The signature file contains the signature made by the software author's OpenPGP key on the application and thus proves authorship (given you also validated the key belongs to whom it should belong to). There is not really any use in creating your own: the signature would prove you signed the application, but this does not help at making sure nobody tampered with the software you downloaded. If you'd be able to create a valid signature in the author's name on your own, the whole process of digital signing would be forfeit.

Instead, look for the original signature, which is provided right next to the software download.


How am I supposed to use a revocation certificate, and can there be multiple revocation certificates for the same private key? I just generated a revocation certificate for my key. Unfortunately I don't fully understand the concept. Here are my questions:

How exactly am I supposed to use it?
Suppose for example that my private key gets compromised.
What exactly I am gonna do with my revocation certificate?
For instance, send an e-mail to all my acquaintances saying "Look, private key compromised, here is the revocation certificate?" (Why not just "Look, private key compromised."?)
Should I publish the revocation certificate on my website, in case the private key gets compromised?

If I re-run the same command in GnuPG, will I get a different revocation certificate? Or does it strictly depend on the private key only, so that given the private key one and only one revocation certificate is possible?

You use the revocation certificate, which gets generated by GPG earlier, to prove your intention to revoke the certificate

What exactly I am gonna do with my revocation certificate?

For instance, send an e-mail to all my acquaintances saying "Look, private key compromised, here is the revocation certificate?" (Why not just "Look, private key compromised."?)

Scenario: you lost your key. If an attacker tells acquaintancies "Look, I lost the key" unsigned, how can the recipient attest the authenticity? You and the attacker can't sign messages. Certificate revocation prevents DoS in this case
Scenario: the key is compromised. Both you and the attacker can sign messages and send revocation certificates. Because of this, it makes no sense to send an email "Look, my key was compromised. Here is the new certificate" because both you and the attacker can both sign messages and revocations. As soon as you warn your acquaintances, you must renegotiate a certificate out of band.

If I re-run the same command in GnuPG, will I get a different revocation certificate?

I don't have this information but I can guess-answer. The two revocation certificates may or may not be binary equal (try it yourself) as soon as they store some variable information like timestamp.
But in general the revocation certificate must be bound to the public key, which is the only information the acquaintances can know, so in general it should be the same no matter.


ROP gadget for setuid(zero) - writing argument zero into the stack Having a program vulnerable to stack based buffer overflow with setuid bit set, and want to fill the buffer with ROP gadgets.
If setuid(0) is needed to spawn a shell with root privilege, then '0' would be written in the stack, so setuid() can take it as the unique argument. The 0 breaks the sequence we want to write in the stack so an  alternate way to write it is needed.
Reading about printf and format string, i'll fill the buffer with ROP gadgets this way:
        <higher address>
        ....
        printf's argument
        setuid's argument
        addr. of pop\ret
        addr. of setuid()
        addr. of printf's argument
        addr. of pop\ret
ESP-->  addr. of printf()

When it's time to return to the calling function, what is pointed from ESP is loaded into EIP, so the cpu execute the printf() with its argument and so on.
What i'm not understanding is how printf() plays in writing the 0 in the "setuid's argument" position.
I'm on a 32-bit linux system.

While the program itself may not have a format string vulnerability, you can still use the same technique to abuse printf's ability to write arbitrary data at relative offsets without even knowing the address to write to.
The manpage of printf is your friend here. On x86, arguments are taken from the stack, so if you called printf here with the argument %p %p %p %p, it would print out the next few values on the stack, showing the second half of your payload. The 3rd offset, I believe, should be where you are trying to write 0 for setuid's argument. This parameter could also be accessed directly using the notation %3$x.
The %n specifier tells printf to write the number of bytes already printed to whatever address is provided as an argument. So, if printf has not printed anything yet, and its argument is %3$n, it should write 0 to the 3rd stack offset, achieving your goal.
The only problem you may still have to solve is getting your printf argument into memory at a known address.
An unrelated method; if you have enough ROP gadgets, you may be able to find some combination that allows you to push a 0 onto the stack in the correct place.


How can I protect my phone voicemail from being hacked? With the News of The World Phone Hacking scandal spreading globally amidst allegations that as well as celebrities, victims of September 11 and other major events in the news have had their phone voicemails hacked into.

With this in mind, many people are wondering: How can I stop my phone being hacked?

This being security.SE, I'll have to be a bit more pragmatic, but any steps, controls or other hints that improve the security of mobile and home voicemail.

There is already a question on securing your Android phone

I have added another question on iPhone security while this one is focusing more on the voicemail side)

Only end-to-end encryption as pepe suggests can offer something significant - and still won't save you in cases like voice messages etc.

Also 'rooting/jailbreaking' the phone or not may be an important question if concerned about illegal client-side software installations. Rooting the phone can lead to opening it up to exploitation if not careful (it sometimes leaves the ssh daemon open with default password) - but then again you may be able to install security software only after rooting it. The recent iPhone/iPad exploit demonstrates this: it takes advantage of a fault in a font parsing routing in the iPhone software while opening a carefully constructed PDF file, and uses this fault to get root access. The thing is that after exploitation, you can apply a patch for the fault so that no one can exploit your device without your knowledge if you happen to open a malicious PDF. Without jailbreaking the device you can't install the patch (it's not official yet).

Phone operators (or secret agencies) have the authority and means to push and install software on your device without your knowledge. But it's not only them, look here and here for example. Pushing software and firmware updates can be done to any phone - no need for it to be 'simple' or 'not smartphone'.

Another interesting factoid: The chat logs between Bradley Manning and Adrian Lamo that Wired recently released contain multiple references to phone tapping by secret agencies, for example that it took NSA 50 people and 6 months to figure out how to tap the iPhone. The most interesting part is that wiretapping is something commonly done and they don't have to get a warrant or think about privacy rights while doing it because they do not present the wiretapping data as evidence in court to be challenged - they only use the data to obtain leads to other evidence.


Installed new Wildcard certificates on my server, but still appear as expired on browser I have bought new WILDCARD certificates (*.mydomain.com) for my servers.

I was able to install successfully on one server. So, I know the files are correct and I was able to verify their validity.

My servers are running Apache2 on Ubuntu 10 and 12-

I have stored away the old certificates and install the new ones in a new folder, then edited the corresponding configuration file to point to the new certificates.

Restarted apache:

$ apache2ctl restart

And browsed to the page that should be secured.

I am still getting that my certificates have expired. I have even rebooted the machine to make sure. So, I am guessing that either my certificates are cached on the servers side or the client side ...

As this is new to me, any help is appreciated.

Here the log I get after a reboot

[Mon Dec 09 15:05:39 2013] [info] Loading certificate & private key of SSL-aware server
[Mon Dec 09 15:05:39 2013] [debug] ssl_engine_pphrase.c(470): unencrypted RSA private key - pass phrase not required
[Mon Dec 09 15:05:39 2013] [info] Configuring server for SSL protocol
[Mon Dec 09 15:05:39 2013] [debug] ssl_engine_init.c(465): Creating new SSL context (protocols: SSLv3, TLSv1)
[Mon Dec 09 15:05:39 2013] [debug] ssl_engine_init.c(613): Configuring client authentication
[Mon Dec 09 15:05:39 2013] [debug] ssl_engine_init.c(1208): CA certificate: /C=US/O=Register.com/CN=Register.com CA SSL Services (OV)
[Mon Dec 09 15:05:39 2013] [debug] ssl_engine_init.c(1208): CA certificate: /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
[Mon Dec 09 15:05:39 2013] [debug] ssl_engine_init.c(1208): CA certificate: /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
[Mon Dec 09 15:05:39 2013] [debug] ssl_engine_init.c(676): Configuring permitted SSL ciphers [HIGH:MEDIUM:!ADH:!MD5]
[Mon Dec 09 15:05:39 2013] [debug] ssl_engine_init.c(420): Configuring TLS extension handling
[Mon Dec 09 15:05:39 2013] [debug] ssl_engine_init.c(807): Configuring RSA server certificate
[Mon Dec 09 15:05:39 2013] [debug] ssl_engine_init.c(846): Configuring RSA server private key
[Mon Dec 09 15:05:39 2013] [debug] proxy_util.c(1818): proxy: grabbed scoreboard slot 0 in child 7618 for worker http://localhost/
[Mon Dec 09 15:05:39 2013] [debug] proxy_util.c(1934): proxy: initialized single connection worker 0 in child 7618 for (localhost)

I found out that I had also node.js instance running on the server.

That node HTTPS server was also using the certificates but since I was only restarting Apache, the new certificates where not taken into account.

Only after a reboot I noticed that there was that node.js server and found where to configure it properly to use the new certificates.

There was no cache whatsoever to worry about.


How secure is using car number plates as a password? My car license plates tend to have 3 or 4 digits and 3 or 4 characters.

If I were to combine two (or more?) of them, throw in a plus sign or similar and uppercase one or two characters, how secure would that be?

Let's not worry about someone looking over my shoulder and recognize me typing a few characters of my current license plate (I will use 20 year old plates, which no one but me would know).

This would be easy for me to remember, but there should be no dictionary match.

Wow! For some reason there are several random license plate generators out there!

From this one, I took the first 3, which were

  NUB 8256
  EDD 8015
  EVO 5499

If I take only two of them, and throw in a plus sign, I get

nUb8256+edD8015

which looks reasonably secure to me and https://howsecureismypassword.net says that it would take 16 billion years to crack.

Obviously, I can't be sure about the accuracy of that site, or future advancement in computing, but how secure is this method?

Tools like you mentioned above will only check for few cases like dictionary words, inclusion of upper case, lower case characters, non-alphanumeric symbols and so on. But they probably fail at finding out the pattern.

In your case, you have a pattern, which, if gets out in public(which has, by the way), can be used to crack the password. The fact that the plus symbol always comes in between and the left and right parts are made up of licence plates makes it much easier to crack.

  how secure is this method?

It's not. You should probably switch to a password manager, which would ideally generate a password which is practically really hard to crack, if not impossible.

You seem to be ignoring what is known as shoulder surfing, where as it shouldn't be. Experienced "shoulder surfers" would definitely crack the pattern of your password.


Are there implementations of password hashing algorithms for major frameworks that utilizes specialized hardware like GPUs/FPGAs? It is common knowledge that password cracking attempts can greatly benefit from specialized hardware such as large clusters of GPUs or FPGAs.

Are there any implementations of the commonly recommended password hashing algorithms (PBKDF2/bcrypt) for common or popular programming languages and/or frameworks such as .NET that offloads the password hashing portion of the authentication process to specialized hardware such as GPUs or FPGAs?

If there isn't such an existing library, are there any good reasons why they do not exist?

The benefit of computing hash functions with an FPGA or GPU is that they are heavily parallel,  such parallelization is not required for most authentication systems.  Further more memory intense hash functions,  such as bcrypt and scrypt, remove parallelization advantage that FPGAs and GPUs have over CPUs.

It is possible to implement such a feature,  however it would be counter productive.  The point of using bcrypt, and other key stretching algorithms, is to remove the computational advantage provided by a heavily parallelized computational resource such as a  FPGA or GPU.

Related:
Why can't one impermanent bcrypt in Cuda?


Does the method of Internet connection affect the security of your the network? I was just visited by some door-to-door salesmen from a local ISP/TV/Phone provider.  During our conversation, I raised some concerns about the fact that I knew their help desk techs had back-door access to the home gateway devices.  This access allowed them to update the router's firmware whenever they wanted, and even change security settings on the device.  What had bothered me was that, during one particular call, they had done this despite my expressed objections.

Putting that aside, the salesperson diverted the discussion to the issue of their type of connection being more secure than other providers.  Their logic seemed to make some sense, but I wanted to bounce it off you guys to see what actual protection there may be.  The point broke down to one connection method being a shared medium among neighbors, versus their connection method which was dedicated to each home.

Are there any inherent security risks/benefits to the various forms of ISPs?  If so, what?

I'm looking to see answers covering:

Fiber
Cable
DSL
Is dial-up even around anymore?
Satellite
Mobile (3G/4G/etc.)

For attackers who are "far away", the medium is irrelevant: such attackers act at the logical level, sending IP packets which must go through the facilities of your ISP. What could protect you at that point is a competent ISP, which is unrelated to the medium used to move the packets between the ISP and your home (and that's an oxymoron, too).

Medium matters only for attackers who are physically close. A motivated attacker with physical access to the premises could "work around" the medium by attacking either end. With an ill-tempered hound and a shotgun, you can take care of the physical security of your home, but there is little you can do for the other end, which is under the responsibility of the ISP. Radio-based links may be a bit more at risk here, because the ISP end of it must have an aerial antenna, thus exposed to the elements at large, and attackers with climbing skills.

If we consider only attackers with low motivation and unwilling to act physically, and yet for which the physical medium has any importance, then the question becomes "how can I prevent my neighbours from spying on my connections and leeching my bandwidth ?". There, the medium can make quite a lot of difference, because of the availability of the required tools. For instance, I would rate 3G connections as "quite secure" (in that context) because 3G includes encryption, and in any case 3G protocol analysis apparatus is neither cheap or off-the-shelf at any Best Buy-like franchise. At the other end of the scale, one may find WiFi-based ISP: WiFi has a long history of botching encryption and security, and all laptops have an on-board WiFi component which is easily amenable to protocol analysis (e.g. changing your MAC is standard issue and supported by any decent OS out-of-the-box).

In the "neighbour is the attacker" scenario, point-to-point mediums are also somewhat better than broadcast mediums; I know of some Cable providers where the cable is a thinly disguised carrier for ethernet frames, which are broadcasted throughout the building, the ISP "box" acting as a filter. On the other hand, DSL is normally point-to-point.

Some ISP use cryptography; at least, some DSL providers implement (or used to implement -- I saw that in France about 10 uears ago) PPTP or L2TP with encryption and strong authentication. Done correctly, this provides a high level of protection against neighbours, which abstracts away the details of the physical medium. This brings us back to the question of ISP competence...

Most of the security issues you will have will be with the router provided by the ISP, which can have backdoors and security holes; and, in the second place, security holes in the ISP network itself. As for the medium, in your list, I would rate 3G networks with the highest level of security because the protocol includes by default some decent protection, so a medium-related issue would need the ISP to be creatively incompetent; whereas for Cable, DSL or Fiber, basic crassness is sufficient to be vulnerable.


How common is steganography in real world applications? Steganography, the art of hiding information in "plain sight", is often taught in universities, because it seems immediately graspable to students. An image format where only 7 bits per byte are used can be (ab)used to hide 3 bits of information per pixel.

Unlike cryptography, steganography aims to protect the confidentiality of its information by hiding the fact that this communication channel exists.

How common is this approach in "real-world" applications? Are there documented cases of where steganography was used for something other than demonstration purposes?

I'm primarily interested in relatively "modern" applications, at least in applications since modern cryptography has become feasible enough for mass use.

Given your comment I will skip the historical info but if you want you can read it in this paper.

The answer to your end question is yes, it's being practically used.
The following malware programs and cyberespionage tools are known to have used it:

KinS
Microcin
NetTraveler
Enfal (Zero.T loader);
Shamoon
Triton (Fibbit)
Zberp
ZeusVM

There are some advantages for its use in the cases of malware:

data (and the actual data transfer) can be better concealed
makes Anti-malware tools useless against such technique
bypasses Deep packet inspection (DPI)
can bypass Anti-Advanced Persistent Threat (AAPT) measures
steganography detection programs are today at a state of proof-of-concept having no practical reliability whatsoever

So basically, for deploying data to be used later, steganography is an excellent way to do it and in the specific case of malware and data retrieving advanced systems like KATA (Kaspersky Lab’s Anti-Targeted Attack) will only be able to help when something already bad starts to happen.

From a more peaceful perspective, I could just use images for password storage and no-one would never know and I did implement such a solution in practice. Imagine a standard password. Each character of it has a hex value. A bitmap's pixel values also have a hex value. With a very easy to construct program, you can store your password inside a bitmap by altering specific pixels with close values to your password's hex with the actual password character value. If the picture is unique (aka not from the internet so there's a comparison possibility) there is no way whatsoever to determine if a pixed has the original color code or it's something altered.


How to remove IGAL ransomware The IGAL ransomware is a malicious program that encrypts the personal documents found on the victim’s computer with the “.igal” extension, then displays a message which offers to decrypt the data if payment is made. As predecessors, I am looking for information on how to remove this malicious program. Is there any program to remove this program or is it actually impossible to recover files without a unique key?

You don't remove ransomware, because when you know a ransomware is on your system, it's already too late. You either have good backups in place, or you keep from getting infected. What you can do is to recover from the damage.
If you can recover the files without paying, it depends on how the ransomware was built. Earlier versions had issues with the crypto setup and sometimes you could recover the files without paying, but those cases are getting rarer every day.
You can wait to see if someone breaks its encryption, or pay for the key. There's no other way.


With Google's new Privacy Policies going into effect soon, how can I better protect myself using their services? From what I can tell, the gist of the new Privacy Policy from Google is that they're making a blanket policy to allow using your data between all their services, however they see fit. So now one policy will cover all 60+ services they offer.

Learn more here: Google Privacy & Terms.

At first glance this makes me nervous as my info is now aggregated/centralized to many services - which for all I know they've been doing this for years - which provides many points of weakness.

Is this really a risk to worry about? Does this really provide more avenues for hackers to access google data, or is it nothing more to worry about before since all services used are encrypted? (at least I believe they are....)

The "privacy policy" of Google, and hackers, are mostly orthogonal issues.

The new privacy policy is about making clear to you, in a legal way, that Google may aggregate all your data, regardless of the "service" under which you made such data available to Google.

The "hacker risk" that you allude to is more about how a malicious individual, obtaining an illicit access to some of the machines within the Google network, could escalate that access into access to more machines within the Google network.

The only link between these two themes is that, in order to aggregate data from several services, the machines which host these services must be somehow linked together and let the data flow. However, it is highly probable that all the machines at Google's are already linked together with high data flows, if only to mutualize infrastructures, maintenance and backup tasks, and your data already flows quite freely. The new privacy policy is not about instituting new data flow processes; the data is already gathered and moved around. The new policy is about making it legal for Google to have a look at the gathered data.

Therefore, the new policy is unlikely to increase, or decrease, or alter in any significant way, the resilience of Google's systems to external malicious hackers. What the policy changes is that it allows Google itself to do some data mining and matching that would otherwise be considered as "bad".

(Presumably, Google is not evil -- if Google is evil, we are all doomed anyway.)


Is this a safe way to verify public keys? I want to verify a public key like this:

Alice generates a public/private key pair for encryption
Alice generates a public/private key pair for signing
Alice signs a random 4-letter word + the public encryption key using her private signing key
Alice sends her public keys (both) and the signature to Bob
Alice sends the 4-letter word to Bob using a secure and trusted way
Bob verifies the public encryption key of Alice by verifying that the signature is created with the 4-letter word in the way described above.

This is what I am not sure about:

Is a 4 letter word enough?
Does verifying the signature verify that the public key is the original key and has not been altered by a "man in the middle", when the original message is the secret?

Background: I want to archive save exchange of public keys between too parties. But there is no trusted third party authority I could rely on.

But instead the two parties will meet in person at the beginning. At that moment they trust each other completely. One party can give the other a secret (for example on a sheet of paper).

Of course in  theory the other party could give something back. But for reasons of user-friendliness I want to avoid this.

Of course the fingerprint of the public key could be the secret. But again, to make it user friendly, I want to make the secret as short as possible.

1. Is a 4 letter word enough?

It doesnt matter how long the word is as long as it can be considered unique and is kept secret. An attacker signing his public key with a lot of random sequences of 4 letters where one of them contains the correct sequence is unlikely to suceed as the amount of random combinations make the attack rather obvious.

2. Does verifying the signature verify that the public key is the original key and has not been altered by a "man in the middle", when the original message is the secret?

If the signature is valid, you definitly know that the owner of the (signature pairs) private key who also knows the secret 4 letter sequence gives you a public key, nothing else. It doesnt check if the key inside is a valid certificate, if the 4 letter sequence is correct or that this is the correct public key (the owner of the signing key pair can sign whatever he wants).

Now lets imagine you have a Man-in-the-Middle (MITM) at step 4, when Alice transfers the public keys and the signed 4 letter word to Bob. As there is no CA and we assume that Bob can not distinguish the certificate of Alice from the certificate of the MITM, the MITM could simply replace the public keys with his own, read the 4 letter word and sign the same word with his own key too. A signed word is easily accessible, so at the moment you sent it the MITM can simply read it and use it to replace all future data and be authenticated by Bob. Therefore, this is not a safe way to verify public keys.

Possible Solutions

Exchange a hash (sha1 f.e.) of the fingerprint at step 5. It can still be considered safe enough if Bob only remembers the beginning and ending couple letters of the hash as it would be impossible for a MITM to create a certificate whose fingerprint's hash starts and ends exactly with the same couple letters.
Use symmetrical encryption. Put your public certificate in a password protected (zip f.e.) archive and exchange this password.

By the way, you dont need two key pairs, you can sign & encrypt with the same keys.


If HTTPS only runs on a single port, why is SYN flooding an issue? I've read online that SYN flooding is when "the attacker sends repeated SYN packets to every port on the targeted server." However, HTTPS only runs on port 443. Therefore, why is it productive for an attacker to target "every port" if only port 443 is responsible for web traffic? Why does a web server care what happens on ports <443 and >443?
As a related question, to mitigate SYN flood attacks, why doesn't the server just stop listening at every port except 443? That way, the server can continue on with its business and not have to deal with incoming SYN packets at other ports?

Sending to every port is overkill; to quote the same article,

[The server] responds to each attempt with a SYN-ACK packet from each open port.

So it is only open ports that matter, because if they receive a SYN they will wait for an ACK response to their SYN-ACK.  It is the resources consumed by such a "half-open" connection which get exhausted.  And in fact, with enough SYN packets, it is possible to SYN flood a server even if the only open port is the web port.  So limiting traffic to that one port is not enough protection if the attacker can pump enough SYN packets in.


Why default settings are generally weaker than optimal ones? In nearly all software (that I've used so far) that allows to set the encryption settings, default settings are kind of weak. There is always something that you should tweak to achieve better protection. It applies to regularly updated software as well. Why is it so? If a main task of a software is to protect your data via encryption, why does it allow to set potentially insecure options?

One reason is that older algorithms are likely to have wider support. Such defaults probably ensure that the software runs on a wide variety of platforms out of the box. The software itself might also be old.

It may be assumed by the developers that you will configure the software to meet your expectations after installation. It may be arguable that this is not an ideal assumption to make.

However, if the alternative is that the user must configure the software just to install it at all, then non-technical users may balk or may not be proficient enough to understand the installation/configuration process. Which  means that the software won't be installed or used properly, which is worse then being stuck with Triple-DES as the default cipher.


Police forcing me to install Jingwang spyware app, how to minimize impact? Chinese police are forcing whole cities to install an Android spyware app Jingwang Weishi. They are stopping people in the street and detaining those who refuse to install it.

Knowing that I may be forced to install it sooner or later, what are my options to prepare against it?

Ideally:

Make it appear like the app is installed and working as intended,
without having it actually spy on me.

The app is downloadable and documented. It basically sends the IMEI and other phone metadata, as well as file hashes, to a server. It also monitors messages sent via otherwise secure apps. I don't know whether it includes sophisticated anti-tempering features or not.

I can't afford two phones nor two contracts, so using a second phone is not a viable option for me.

This may not be the answer you will be happy with but how about abstaining from having any undesirable data inside your phone in the first place and instead using the right tool for the job?

According to Wikipedia:

  The app records information about the device it is installed on, including its [...] IMEI, the phone's model and manufacturer, and the phone number. The app searches the phone for images, videos, audio recordings, and files [...]

So, instead of trying to tamper with this spyware in any way (which can get you in a much bigger trouble), simply don't do anything suspicious on this phone and let this app do its job. Prepare against it by not having any photos, videos, audios, file, etc., and instead use the right tool for the job. Use some other secure software/hardware to connect to internet, use encrypted email provider and do all of your communication through the computer where you can do communication safely, and store all of your files somehow in a safe place (encrypted, somewhere on computer or USB, etc). Pretend to be an obedient citizen and use the right tool for the job to do whatever it is you don't want your government to find out.

Some people may wonder why bother having a phone in the first place (and FYI, I asked the same question under OP's question, for clarification). My answer is:

to make phone calls (and have conversations which are not going to be considered by Chinese government suspicious, in case they are tracking that too)
to use it as a "red herring" - if police asks you to give them your phone you won't have to lie to them that you have no phone, or worry that they will find out that you tampered with app, or get in trouble if you don't have app, etc. You'll just confidently give them phone, with no "illegal" information on it, they will check it, and walk away. You may, actually, even have some "red herring" files: pictures of nature, shopping list (milk, eggs, etc.), etc., just so that they wouldn't suspect that you deliberately not using your phone for such purposes, and harass you farther.

I mean, not long ago mobile phones didn't even have the ability to store pictures, videos, files, etc.

Are you willing to put your life in danger simply because you want to have some files on your phone?

Tough times require tough decisions.


What kind of attacks do Javascript WebWorkers protect against? What kind of attack are prevented by running code submitted by the user in a Javascript Web Worker? Do they prevent attacks like XSS, or is it better to use some other sandboxing method to protect against most vulnerabilities?

It looks like WebWorkers are not a security feature, but simply a way to run background threads on the client side of the web application. This means they don't protect you from any existing attacks but they may instead introduce new attack vectors :(

Of interest in this regard might be the communication between the workers and the main thread: they are reusing the postMessage interface which was originally used to communicate between different frames. By using the same interface it also adds the same security issues. This means you should check for the origin of a received message in your message event handler. The example code you will find for web workers usually does not do this.


OSX HomeBrew Security Risks I've been trying to harden my OSX 10.11 computer and one of the guides suggested installing Homebrew to get updates to things such as OpenSSL. While updates are great, it seems like Apple should be relatively on top of issues (a recent web test showed TLS 1.2 installed...), along with having a comprehensively tested system OS.

Would Homebrew +package updates have an additive effect with Apple security updates? Does Homebrew have known security issues in and of itself? Or would installing a package manager and associated updates change the system configuration such that, in the hands of a relatively inexperienced admin, it will ultimately be in a more vulnerable state?

Would Homebrew +package updates have an additive effect with Apple security updates?

It should improve security if you leverage it to regularly update packages that Apple is either shipping out of date, or not maintaining and patching. Example

  Does Homebrew have known security issues in and of itself?

Without a full security review this answer is unknown. Worth digging around reported issues for other security related issues.

  ... Would installing a package manager and associated updates change the system configuration such that, in the hands of a relatively inexperienced admin, it will ultimately be in a more vulnerable state?

This question leaves a lot to speculation. I believe the homebrew documentation and its community is large enough that this should not be an issue. Deeper dive into considering ways to secure OSX.


How to check for malware before downloading a torrent file? I wanted to know if there is a way to check if a torrent file has malware or not, before actually downloading it via uTorrent f.e.
I only know VirusTotal site. Is this one reliable? Because each time I past a link in it, it says that the link/file is safe. So I don't know if every single link/file I paste on virustotal is clear and safe or just the web doesn't detect malware well.
Best option for me would be to have a way to check it on the web without downloading 3rd party apps.

You should check the reputation of the site or the comments of the file. As someone told you in comments, unless someone is using a day 0 attack or and unpatched vulnerability you will be safe. You can't do anything more before you download the torrent.
If you wanna check if the torrent has any kind of malware after the download, you should have a sandbox tool and a VM(Virtual Machine) or a dedicated computer for check the files you have downloaded. You can use an antivirus, antimalware bytes, roguekiller... After that, you can upload the files to virustotal and see if one the antivirus detect something in your files.


Encryption of metadata files with the help of password based encryption I have to use password-based encryption for dealing with metadata files in my application.

While reading, I came across three options: bcrypt, scrypt, and PBKDF2. I read something about them, but I found nothing convincing and satisfactory to help decide which one is best to use.

I would like to have an comparative analysis for these three technologies with respect to security

Just to be clear, these algorithms are password hashing algorithms, that could be used for creating an encryption key. These are not encryption routines by themselves. If you are asking about encryption routines, (such as AES,) please edit your question.

If your question is about key derivation (so you can create a key to feed your encryption routine):

I asked a similar, if not duplicate question myself.

PBKDF2 is specifically designed for key derivation.
bcrypt can be used for this as well, though it was not necessarily designed for the key derivation (slight minus), but hashing (still works). It is newer (minus), but still sufficiently vetted (mostly removes the minus). It is less convenient to use GPUs on it (plus), due to the extra memory overhead. (if memory serves me right, I won't be corrected on this)
scrypt is newer, and considered promising, though not as well vetted as the other two. (a minus) I expect that this, like bcrypt, is designed for password hashing, but not necessarily for key derivation. If you use this, you may consider adding a more proven routine to the formula, as this is not a proven routine on its own.

I would use PBKDF2, and bcrypt both, and xor the two results together, because I like that PBKDF2 was designed for key derivation, and that bcrypt is more resistant to GPUs.But I may be over-designing.

At any rate, make sure your routine takes a long time. If you do not adjust the hashes properly, and it completes too quickly, than an offline brute-force may become feasable. I recommend 50-500ms. Keep in mind that newer hardware will speed this up, and that hackers may speed it up even more if they invest, or maybe just rent a cloud/cluster. Both of these mean you should adjust the hashes to repeat as much as possible, stopping just before you have a "slow problem". Because it will do nothing except speed up over time.


Penetration testing from a phone Suppose that I use a smartphone with an external WiFi adapter to cover up my real MAC address and on top of that I use a no-log VPN. In what way could I still be identified? I have heard a lot of talk against smartphones as hacking devices as they contain a lot of personal information, but I cannot see the validity of this argument as none of this personal information is related to the packages being sent when penetration testing another device.

I only see two things identifying oneself: MAC address and IP address.

Using an external adapter, the MAC address of the phone is not used. Suppose that the wifi adapter is bought with cash in some local store, there would be no way of identifying someone by knowing the MAC address of the external WiFi adapter.

VPN to fake the location and IP address.

Why would it be more secure to pentest or "hack" from a computer that contains no personal information about me compared to my smartphone? If the argument is because the entity that I am hacking could hack me and break into my system and reveal all my information, well they can't. Understanding the Android system shows that everything is sandboxed, every app is within its own environment and cannot see the rest of the system. Hacking into an Android device would just hack into a useless environment that is completely locked down. Even commands like "iwlist" are not allowed. I see smartphones as more secure devices to hack from than computers.

Can anyone expand my knowledge or prove that I am completely wrong?

By default, smartphones have a lot of services that phone home with diagnostic information that could identify you.

If you root the phone and remove all this, then the phone is basically a computer. Still I would prefer to start from a known baseline (e.g. simple Linux distro) and only add what I need, rather than risk missing a service that identifies me.

For pen testing you don't normally need to be anonymous as you're working with permission. But I've still answered your question as occasionally pen testers have good reason to be anonymous.


How to exploit this buffer overflow. Where is the return address? I'm practicing doing buffer overflows and, weirdly, I can do some but not others and it is not clear to me why. Here is the example code:

Code that I need help with::

#include <stdio.h>
int main(int argc, char * argv[]) {
    char buf[256];
    if(argc == 1) {
        printf("Usage: %s input\n", argv[0]);
        exit(0);
    }
    strcpy(buf,argv[1]);
    printf("%s", buf);
}

I compile this code with gcc -z exestack -fno-no-stack-protector

Questions:

I understand that the general technique is to write to a buffer such that I overwrite where the next instruction register looks in memory. So my question is, where do I insert a breakpoint in this code to figure out where to overwrite? If I do disas main I get:

0x080497b1 <+60>:   add    $0x10,%esp

0x080497b4 <+63>:   sub    $0xc,%esp

0x080497b7 <+66>:   push   $0x0

0x080497b9 <+68>:   call   0x804fd50

0x080497be <+73>:   mov    0x4(%eax),%eax

0x080497c1 <+76>:   add    $0x4,%eax

0x080497c4 <+79>:   mov    (%eax),%eax

0x080497c6 <+81>:   sub    $0x8,%esp

0x080497c9 <+84>:   push   %eax

0x080497ca <+85>:   lea    -0x108(%ebp),%eax

0x080497d0 <+91>:   push   %eax

0x080497d1 <+92>:   call   0x8049028

0x080497d6 <+97>:   add    $0x10,%esp

0x080497d9 <+100>:  sub    $0x8,%esp
0x080497dc <+103>:  lea    -0x108(%ebp),%eax

If I add a breakpoint at *main+97, and then run AAAAAA I get the following:

Breakpoint 1, 0x080497d6 in main ()
(gdb) info registers
eax            0xbffff1f0   -1073745424
ecx            0xbffff575   -1073744523
edx            0xbffff1f0   -1073745424
ebx            0x80da000    135110656
esp            0xbffff1e0   0xbffff1e0
ebp            0xbffff2f8   0xbffff2f8
esi            0x80da000    135110656
edi            0x80481e8    134513128
eip            0x80497d6    0x80497d6 <main+97>
eflags         0x246    [ PF ZF IF ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51

Am I putting the breakpoint in the right place to help with this overflow? Right after the call to strcpy? Also, I see that ebp is at 0xbffff2f8. Does this mean that I want to overwrite the address right next to this at 0xbffff2fc to point back inside the buffer and I will be done? Because that does not appear to work: my buffer is a NOP sled and shell code.

Thanks for any help!

Correction.. I’ll look again but in order to overwrite EIP you’d need to input a buffer that is buf +whateverIsAboveItOnStack + EBP (4bytes) + whateverYouWantEIPtoBe . Run the program in gdb and type disass strcpy() the you’ll be able to see where the overflow happens and where your buffers are located. Hope this helps.

    (gdb) run $(python -c 'print "a" * 270')
Starting program: /home/bob/C/Disassembler_Fun/SE_Vuln/se_vuln $(python -c 'print "a" * 270')

Program received signal SIGSEGV, Segmentation fault.
0x0040068b in main (argc=<error reading variable: Cannot access memory at address 0x61616161>,
    argv=<error reading variable: Cannot access memory at address 0x61616165>) at se_vuln.c:10
10  }
(gdb) i r
eax            0x0  0
ecx            0x61616161   1633771873
edx            0xb7fbc870   -1208235920
ebx            0x61616161   1633771873
esp            0x6161615d   0x6161615d
ebp            0x61616161   0x61616161
esi            0x2  2
edi            0xb7fbb000   -1208242176
eip            0x40068b 0x40068b <main+139>
eflags         0x10286  [ PF SF IF RF ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51

If I overflow a buffer in a program with a vulnerable function that returns execution somewhere (main()) I can overwrite EIP

    #include <string.h>

void vuln(char *arg) {
    char buffer[10];
    strcpy(buffer, arg);
}

int main( int argc, char** argv ) {
    vuln(argv[1]);
    return 0;
}

    (gdb) run $(python -c "print ('a' * 22) + ('b' * 4)")
Starting program: /home/bob/C/Disassembler_Fun/overflow $(python -c "print ('a' * 22) + ('b' * 4)")

Program received signal SIGSEGV, Segmentation fault.
0x62626262 in ?? ()
(gdb) i r
eax            0xbffff286   -1073745274
ecx            0xbffff520   -1073744608
edx            0xbffff296   -1073745258
ebx            0x61616161   1633771873
esp            0xbffff2a0   0xbffff2a0
ebp            0x61616161   0x61616161
esi            0x2  2
edi            0xb7fbb000   -1208242176
eip            0x62626262   0x62626262
eflags         0x10282  [ SF IF RF ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51
(gdb)

Note the B's (0x42 is the hex for b) overwriting EIP. I guess this is the kind of overflow in your example can be used for a DOS attack but not necessarily code execution. I'd suggest enlarging the buffer in my example if you want to use it for tests involving storing a nop sled and shellcode in the buffer. Good luck have fun! Hope this helped.


Using AES encryption to generate MAC (and provide authentication/integrity) Ignoring that there are far better and more standard approaches to providing authentication and integrity guarantees, what (if any) weaknesses would a system as outlined below that relies on AES (AES/CBC/PKCS7Padding) encryption to produce a MAC suffer from?

plaintext = 12345678|2018-09-18T00:43:27+00:00 (uniqueID + timestamp)

MAC = aes256(sha256(plaintext))

Could you reliably decrypt the MAC, and then compare the output to the hash of the plaintext to prove integrity/authentication. Assuming that the MAC was generated by a trusted source with a shared secret key.

Also assume that an attacker would have access to lots of plaintext and MAC pairs.

Thanks

A signature  is created with a secret private key and verified with a public key. What you're talking about is a MAC, which is created and verified with the same key.

If you want to create a MAC with AES, then there's already a standard algorithm for that. It's called CBC-MAC, and it basically involves encrypting the plaintext using CBC mode and using the last block as the MAC (but be wary of pitfalls).

If you want to create a MAC using a hash like SHA-256, you're much better off using HMAC, as it's a standard algorithm with provable security properties (assuming certain things about the hash, but even MD5 is still very secure when used with HMAC).

aes(sha256(plaintext)) might be ok, but don't roll your own! If you really want to show something wrong with it, you could try pointing out that it's non-standard and relies on the security of both AES and SHA-256, whereas HMAC-SHA256 is standard and relies only on the security of SHA-256.


Does fingerprint scanning on Microsoft Authenticator increase security? tl;dr: I have switched phone and operating system: Android 8.0 --> Android 10.0. Phone restored from backup, so all the remaining is the same except for Microsoft Authenticator that now requires fingerprint scan. Does this truly increase security? Or is this only an irritating addition?

I have crashed my phone, but changed it to nearly identical. I have the same:

family: Motorola Moto Z2 Play → Motorola One,
hardware: both phones equipped with fingerprint scanner,
software and settings: new phone "recovered" from Google cloud backup.

The only change is system version: Android 8.0 → Android 10.0.
When I am accessing my Office 365 apps, I have to go through 2FA: Microsoft Account login + Microsoft Authenticator approval.
Under Android 8.0 I had to:

slide down notification area to reveal "Approve" shortcut button,
tap that button.

And I was authenticated and had access to my Office 365 apps.
Under Android 10.0 I now have to:

tap that notification (because sliding down does not reveal any shortcut buttons; notification type change?),
tap "Approve" button in presented popup window,
touch my fingerprint scanner's sensor.

Why this change? Does adding additional step of using fingerprint scanning comes from:

Android 10.0,
Microsoft Authenticator version available for Android 10.0,
my company policy change after I have registered Android 10.0's phone
or something else?

Does this really increase security in anyway? Should I consider my authentication access under Android 8.0 less secure, if I wasn't required to touch fingerprint scanner's sensor when authenticating there?
Or maybe the entire question is based on a false assumption. That was a company policy change that changed in exact day when I crashed my phone. And I would be forced to use fingerprint scanner under Android 8.0 as well from that moment on, provided that I would not crash my phone?

It does increase security of your Microsoft Authenticator account. In android, apps can use TEE (Trusted Execution Environment) to encrypt authentication token and secrets. When a user wants to login, app requests for biometric or PIN authentication backed by TEE. If authentication succeeds, TEE decrypts authentication token for account login and other data that app wants it to be tamper-resistant and secret.
In most cases, TEE actually decrypts the key that encrypts app's sensitive data. In this way, apps get little more control on when and what they want to decrypt.
Microsoft Authenticator might be using biometric authentication for account login and account holder verification. Verifying the account holder is common in banking apps and it is as much useful for password managers and TOTP generators. Another purpose app based authentication serves is physical theft when the device is unlocked. There's no workaround to infiltrate the app if the authentication is backed by TEE. Reinstalling the app or clearing app data flushes app's associated key(s) in TEE as well.
As for android version, there's no justifying reason to enforce biometric in android 10 but not in android 8. Apps are backward compatible with previous android versions and the minimum android version to support is set at build time. But apps can show and hide some features based on android version. From Android 8+ onwards, biometric authentication is supported and backed by TEE. However, there have been improvements in hardware backed keystore and biometric authentication in each successive android version. It could be that the developers didn't test biometric authentication for android 8 or it wasn't enabled by default in that version.


How can one centrally manage / audit AWS resource-based policies An administrator of an AWS account wants their users to be able to create their own S3 buckets, SQS queues, and KMS keys and attach resource-based IAM policies to their resources. How can said administrator find resources that have resource-based IAM policies in bulk and review these to ensure they are in compliance with a set of standards?

Given that these policies are in line, the only thing I can think of is to use Amazon's list of aws services that support resource based policies, find all resources of each of these services, and then get the policy associated with each of the resources.

This approach does not allow effective planning for the potential of AWS enabling users to attach resource-based policies to future Amazon services.

Is there a best practice or a smarter approach here?

You should be able to use AWS Config for this to ensure that only certain policies are allowed.  Within Storage, you have the following options:

ebs-snapshot-public-restorable-check
efs-encrypted-check
elb-deletion-protection-enabled
s3-bucket-blacklisted-actions-prohibited
s3-bucket-logging-enabled
s3-bucket-policy-grantee-check
s3-bucket-policy-not-more-permissive
s3-bucket-public-read-prohibited
s3-bucket-public-write-prohibited
s3-bucket-replication-enabled
s3-bucket-server-side-encryption-enabled
s3-bucket-ssl-requests-only
s3-bucket-versioning-enabled

For your usage case, I think you can use s3-bucket-blacklisted-actions-prohibited and block for example all s3:GetBucket* policies.

You can also use these rules in CloudFormation templates.


Password Cracking Mandarin Words English Character Set I'll be looking to perform a domain password audit in which the user will be using english characters but may be 40% Mandarin speakers so I anticipate a large number of names, phrases, or words that are written to be mandarin (but written using english character set).

I'd like to perform a hybrid attack and thus I'm hoping to expand my dictionary list to include non-english phrases/words/names but typed in the english character set.

Does anyone know of a resource that fits this description or has access to such a dictionary/word list?  I've done some googling but couldn't find much.

Appreciate any input.

I don't speak Chinese but I believe the operational word to use for your Google-searches is "pinyin". This is the official method of encoding Chinese text into Latin characters (that's not the only one, though). So you want "Mandarin word lists in pinyin".

With such terms, I find this downloadable dictionary which looks promising. In the .u8 file, one will find lines like this one:

 北極熊 北极熊 [bei3 ji2 xiong2] /polar bear/

with the pinyin transcription between square brackets [ and ]. You should be able to build a wordlist out of this file.


Is HTTPS required when there's no sensitive data in the site I'm currently building a B2B e-commerce site for a client using WordPress. We sell industrial machinery ranging in the upper $100k-$400k price range. My client would like to have their financing form online where customers/businesses enter bank account information, as well as social security numbers. He wants this form to be emailed to our financing group to process. Instead of emailing this form, could I keep the data on my SSL server and encrypt it some way then provide a login link for our financing group to use, enter a key, then display the sensitive information? We are trying to eliminate the need to fax or mail an application.

We have 2 servers, an in-house MS SQL 2008 server and a MySQL/Nginx server WordPress is installed on.

After reading through many posts, what my client wants to do is a huge risk for users and our company. I'm not a security specialist, just looking for some feedback on what I should/could do.

It sounds like you have plenty of sensitive information on your website!

Even if your site contains no sensitive information, though, implementing HTTPS is a sound decision. Insecure HTTP connections are vulnerable to a man-in-the-middle (MITM) attack, allowing an attacker to impersonate your site with ease. Clients have no way to be sure they're actually connected to your server, rather than someone else's pretending to be yours.

HTTPS provides authentication by allowing clients to verify your server's identity, as well as confidentiality by preventing third parties from snooping on your traffic.


Is rsyncd secure? (except for the lack of transport encryption) I have been using an rsyncd server for backups for what feels like a decade.
I saw that rsyncd has no transport encryption (not even for username and password).
I wonder what other security issues this software has?
Here is my config (/etc/rsyncd.conf)
port = 873
[backup]
path = /disk/backup
uid = nobody
gid = users
list = yes
read only = no
write only = no
use chroot = yes
auth users = sefwsf
secrets file = /var/lib/backup/rsyncd-save.secrets
lock file = /run/lock/rsyncd-save

on my Desktop I use this command:
rsync --stats -hart --password-file=/tmp/pw.txt ~/stuff $bakuser@192.168.24.3::backup --delete

It looks like you are backing up to a host on your private network (192.168.x.x).  Without any encryption being used with the rsync command, whoever controls the network may be able to 'listen in' on the transfer.  Or, they may even be able to impersonate the host that you are backing up to, so that you send all your files to the malicious host.  Even someone who does not control the network may be able to impersonate the host that you are backing up to, by mounting an ARP poisoning attack.
If you control the private network, then perhaps these types of attacks may be less likely.  But, these threats should be taken seriously if you are backing up over the public internet, where DNS poisoning attacks, MITM attacks, and the like, are quite real.
This why rsync is often run over some type of encrypted tunnel.  Perhaps the most common way to do this is to use an ssh tunnel.  This can be done easily using the -e option, like so:
rsync -e ssh

I generally use a command similar to the following:
rsync -az -e ssh /path/to/source/directory/on/local/host/ user@remotehost.tld:/path/to/destincation/directory/on/remote/host/

This will run rsync over an ssh tunnel to the remote host.  On the remote host, you just need to have an ssh server running.  Authentication can be handled using key-based ssh authentication to avoid having to hard-code a password.
In addition to the benefit of the transfer taking place over the encrypted ssh tunnel - you also benefit from ssh key-pinning in ssh.  If someone tries to MITM the connection or spoof the host (e.g. by way of a DNS poisoning attack), ssh will detect the attack because it will not recognize the public key of the malicious host.


I want to encrypt certain entries in a database. Is this a good plan? I'm working on a web app and want to offer the users the option to "encrypt" their account. This wouldn't encrypt everything related to them in the database. Just certain critical fields.

I've already read D.W.s great response on the issue (https://security.stackexchange.com/a/16961/114330), and in spite of all that, I want to go through with it, because of some key differences:

First and foremost: None of the data I'm encrypting is critically important. This is a toy app, mostly for me to learn from and maybe put on a resume. There aren't any real users.

Secondly, I'm using existing frameworks and technologies. It's a Django app, so I've already got a bunch of protections and some sane defaults like csrf protection. I'm aware that's not magical pixie dust that's going to make my application secure, but "...I'm still learning, and doing the best I can."

With that out of the way, here's how I want to implement it:

The user registers an account. During the registration, they are given the option for account encryption, and a separate password to use for the encrypted fields.
Encrypted accounts have a bool encrypted, set to true. That is the only difference in accounts on the backend.
When the user logs in, if encrypted=True, a prompt shows for them to type in their password, which is stored in client-side memory, and uses browser-side JS crypto (I know, I know...) to encrypt/decrypt the entries.

I want to make sure that nobody but the user can read their own entries, and this seems like a straightforward way of achieving that goal. But, as this is security, there's probably a million ways to do this wrong, and no perfect way of doing this right, so I'm very interested in the opinions of someone more knowledgeable than me, and would be really grateful if someone could point out potential vulnerabilities or areas where things can go wrong.

Given that you say this is not a real application, I'll only comment on a couple of points here. The first is an implementation detail that you might have already considered, the second is more of a theoretical "is this worth while?" question.

1. Password changes.

It is generally considered good practice to require users to change their password every so often. If this password has been directly used to derive the key used to protect their data, then you're going to have a world of hurt ahead of you: you'll have to decrypt their stored data with the old key and then encrypt it with the new key. Yuck. Wasted machine cycles and a potential honey-pot for an attacker, since you have to go back to the plaintext to do this.

A better scheme would be to allocate the user a random key (their Data Encrypting Key or DEK) when they sign up, and encrypt that key with a key derived from their password (their Key Encrypting Key, or KEK). The DEK is used to encrypt the actual data, the KEK is used to protect the DEK, and is never stored. Then, when they change their password, they are just changing the KEK: the DEK does not change, and so the stored data does not need to be updated, other than the encrypted value of the DEK, which is now encrypted with the new KEK.

2. Is this a good idea?

Yes. Absolutely. Encrypting the actual data in a database protects the data against some threat vectors that less granular approaches don't cover. For example, neither an encrypted file system for storing the database tables nor database table encryption protects against a rogue database administrator with the ability to issue a select * from customers; query. If the data itself is protected and the keys are secure (an important consideration), all an attacker can get is the encrypted data.

That said, there are some issues to consider. For example, if you encrypt customers' SSNs in your database, will that impact your call center employees who routinely ask customers for their SSN in order to authenticate them? Plus, what happens when data from your system has to be exported in order to be sent to a business partner, who doesn't have access to your keys?

None of these issues are reasons not to implement security in your applications, but you should be aware that this is not a trivial undertaking.


Hijack attacked SSL/TLS-connections? I think we all heard the news that China used unencrypted HTTP-connections to drive DDoS attacks on targeted websites.

Now within the last few months we've learned about three new attacks (FREAK/Logjam/POODLE) that allow us to recover the master-secret of SSL/TLS connections.

So the following question came to my mind:

Assuming you've (successfully) attacked a SSL/TLS connection using either POODLE, FREAK or Logjam, can you use the gathered information to redirect the request to another site, causing a DDoS attack?

Yes, if you run a full Man-in-the-Middle attack and succeed at breaking through the SSL layer through some method (not POODLE, it does not do that, but FREAK and Logjam, when applicable, are a possibility), then, by definition, you control everything that the client sends and receives. So you could send redirect HTTP requests to make it connect to some other server.

However, still by definition, you can do the MitM because you arranged for all the incoming and outgoing traffic of that client to go through your systems. Therefore, any attempt at turning the client into a DoS agent will make it send these requests to you. So you are really DoS-ing yourself. Thus, this is pointless.

A better model would be to use this hijacked connection to try to induce the victim into downloading some malware that will give full control of his machine to you, and allow you to come back later (when you no longer intercept all I/O traffic) to pursue some nefarious deeds such as sending spam or, indeed, run DDoS attacks (assuming that you succeeded at infecting a lot of people's machines).