which diffie-hellman group is needed for secure ike/ipsec

Let's define a few things clearly...

When you use an asymmetric algorithm like DH, it has a "strength" that relates to the difficulty of breaking through it with the best known attacks. The best known attacks on DH try to solve discrete logarithm with an index calculus variant that has a lot of common elements with the General Number Field Sieve, an integer factorization algorithm. They have the same asymptotic complexity, which is why it is often said that RSA-1024 and DH-1024 have "the same strength".

In practice, though, DH tends to be somewhat stronger than RSA of the same size. The last phase of GNFS involves doing linear algebra in a really big matrix; for RSA, the matrix elements are bits, while for DH the elements will be numbers with roughly the same size of the modulus -- so the matrix for DH-1024 will be about a thousand times larger than the matrix for RSA-1024. For large keys, this linear algebra is the bottleneck, precisely due to the sheer size of the matrix. Therefore, it is expected that DH-1024 is "more resistant" in some way than RSA-1024. We may note that the current record for RSA modulus factorization is 768 bits, while the discrete logarithm record is at 596 bits.

For 1024-bit factorization, we know that the problem exceeds the capacity of existing computers. We have some theoretical design concepts for a special-purpose machine that could factor a 1024-bit integer; it would take years to do a single computation, and building the machine would cost a substantial number of millions of dollars (but not billions -- at least "on the paper"). For DH-1024, I am not aware of a similar design or cost estimate.

Note that none of this is about the length of the key that you generate. What cryptographers like to work with are equivalent symmetric strengths. They want to say that the strength of an algorithm/key is, say, "100 bits", by which they mean: "the effort to break it would be equivalent to the effort involved in breaking through exhaustive search the 100-bit key for an ideal symmetric encryption algorithm". However, this is very reductive. Brute-forcing a symmetric key is about trying out all possible keys, which can be done in parallel and requires negligible RAM contents, only CPU. Brute-forcing scales up well, with negligible structural overhead. This does not hold at all for GNFS; in particular, the main difficulty in GNFS for large RSA or DH keys is that the final step with the matrix is very hard to compute in parallel and requires tons of very fast RAM.

This has not prevented various people and bodies to make estimates. You can browse these estimates there. To sum up, depending on who you are talking to, DH-1024 will be deemed to have about "80-bit strength", while DH-2048 rates closer to 112-bit strength.

Now 80-bit strength is still considerable. The biggest key-crunching effort reported so far is 64-bit. 80-bit is 65536 times harder. Specialized circuitry can probably lower costs a lot. But we are still talking millions of dollars, and not just a few millions; closer to a billion, really. So maybe this is sufficient for the value of the secrets that you want to hide in your embedded systems.

I note that "20 seconds" is a lot. Some years ago, I implemented a basic DH-2048 on a 33 MHz ARM7TDMI, i.e. not the fastest embedded system ever; and it could do a complete DH in less than 7 seconds. My code was pure C, and C is known to be suboptimal at leveraging the CPU abilities at multiplications for big-integer arithmetics. My guess is that going assembly would have allowed DH-2048 to run within 4 seconds or so, on the same platform.

One thing to take into account is the size of the exponent. When doing DH, you are computing modulo a big prime p, and raising two values to exponent x (the DH private key on your side). For 80-bit security, you need p to be a 1024-bit integer (at least) and you also need x to be chosen randomly of length 160 bits (because attacks are either GNFS over p, or a "generic DL" with cost sqrt(x)). For a 2048-bit prime, you get 112-bit security on the GNFS side, so you need the DH private key to be 224-bit. A bigger DH private key won't bring extra security, but it will make computations longer. Possibly, your current implementation uses an oversized DH private key (e.g. a 512-bit exponent), which may explain your issues.

For better performance, you might want to switch to elliptic curves (ECDH). Depending on what is supported on the other side, of course. ECDH provides the same level of security as DH with more arithmetic operations but with much smaller values, leading to a substantial performance boost (typically 5 to 20 times faster). A 224-bit curve provides "112-bit strength", i.e. similar to 2048-bit DH.


Session cookie secure flag: best practice

I recommend its better to use both of them together as it doesn't cause any harm. Also, it ensures philosophy of Defense in Depth.

These days people are deploying on cloud and migrations are more often done. So,I think we cannot be sure that the configuration 2 you mentioned for httpd is in place all the time.

You should consider that enabling <secure>true</secure>  in application is mandatory. Explanation given below.

Explanation:

Scenario 1(Assuming secure flag setting missed by TLS proxy/httpd)

I tested a scenario where I have only enabled  <secure>true</secure> in the application itself and not configured secure flag via TLS proxy(httpd).

Now the Response Header  has a cookie with secure flag, I observed that Firefox and Chrome process and save the cookie with secure flag.

Set-Cookie: acct=tafats; domain=localhost; Secure;expires=Thu, 16-Mar-2017 15:19:48 GMT; path=/; HttpOnly

From a Security point of view this is what is to be expected from browsers.

This protects you from session-hijacking attempts via packet sniffing.

In this case,If the attacker makes the user to click on http://example.com, the cookie is not sent because it has a secure flag.

Here, the <secure>true</secure> came to rescue.

Scenario 2(Assuming secure flag setting missed in the application but configured in TLS proxy/httpd)

Its good enough , as long as you have this secure flag set via TLS proxy. But the catch here is, you need to ensure that this TLS proxy setting is configured for all deployments you do all the time.

  To conclude, I recommend its better to use both of them together and
  ensure the philosophy of Defense in Depth.


Literature about IT security from a hardware standpoint

Andrew "Bunnie" Huang hacked the XBox by attaching monitoring equipment to the memory bus and reverse engineering security protocols by monitoring the data on the bus. He wrote a paper and a book about it.

Huang, Andrew "Keeping Secrets in Hardware: the Microsoft XBox Case Study."(http://web.mit.edu/bunnie/www/proj/anatak/AIM-2002-008.pdf) AI Memo 2002-008

Huang, Andrew "Bunnie" Hacking the Xbox : an introduction to reverse engineering (Unlimited ed. ed.). San Francisco: No Starch Press. (2003) ISBN 9781593270292

For a discussion of Intel and AMD CPU security functions McCune et al How Low Can You Go? Recommendations for Hardware-Supported Minimal TCB Code Execution" (2008) is essential reading.

No discussion of hardware security would be complete without discussing FPGAs. Huffmire et al "Moats and drawbridges: An isolation primitive for reconfigurable hardware based systems" (2007) is a great overview of the use of FPGAs in secure systems.

The challenge of building solid hardware security is illustrated in Kocher et al "Differential Power Analysis" (1999). In it they describe a brillant side-channel attack based on power consumption.

On the theory side Lie et al "Specifying and Verifying Hardware for Tamper-Resistant Software" (2003) is a good discussion of adding execute only control to memory to enforce access control.


Why does Chrome not allow the modification of these headers by extensions?

I agree with the OP that, blocking access to only these headers does not make sense while allowing much broader data in terms of security. A malicious plug-in can do so many damage without them.
From the reading of the API documentation, it sounds like the reason for not allowing access to these headers is not necessarily because of a security concern but more because how current Chrome engine works. It sounds like Chrome's request processing pipeline continues even after the API modifications are done. One aspect of it how Chrome manages network requests and caching. Since those downstream components in the request pipeline can make different decisions and change these headers, I'm guessing that's why it's not even letting you read them b/c it cannot guarantee that they will stay the same.
This is based on how they explained it in the chrome.WebRequest documentation

(*) Note that the web request API presents an abstraction of the
network stack to the extension. Internally, one URL request can be
split into several HTTP requests (for example to fetch individual byte
ranges from a large file) or can be handled by the network stack
without communicating with the network. For this reason, the API does
not provide the final HTTP headers that are sent to the network. For
example, all headers that are related to caching are invisible to the
extension.
The following headers are currently not provided to the
onBeforeSendHeaders event. This list is not guaranteed to be complete
nor stable.
... the header list the OP is questioning ....

If you read further down in the page, it explains the cache issue little more. It sounds to me that Chrome doesn't prefer to expose some parts of the request pipeline (specifically things that affects network communication decisions, including caching) probably for some good technical reasons (maybe it requires a major design change).
Since these hidden part of the pipelines may make different decisions after your plugin modifications are done, Chrome does not let you read them because the downstream pipeline components may still change them. See how it talks about "in-memory cache" being invisible to the API. It sounds like a design challenge on Chrome's part (or a preference not to let a plugin affects its network performance). So I would conclude it's not necessarily because of security.

Caching: Chrome employs two caches — an on-disk cache and a very fast
in-memory cache. The lifetime of an in-memory cache is attached to the
lifetime of a render process, which roughly corresponds to a tab.
Requests that are answered from the in-memory cache are invisible to
the web request API. If a request handler changes its behavior (for
example, the behavior according to which requests are blocked), a
simple page refresh might not respect this changed behavior. To make
sure the behavior change goes through, call handlerBehaviorChanged()
to flush the in-memory cache. But don't do it often; flushing the
cache is a very expensive operation. You don't need to call
handlerBehaviorChanged() after registering or unregistering an event
listener.


Short answer: probably.

Longer answer:

Probably, but these aren't the guys making the money or pushing the limits of the field. Malware has become an extremely commercial business, partly because so many activities in our lives are now controlled by or performed on computers. Social networking and online business have made the internet a haven of personal information and criminal potential. It's known that more successful malware campaigns can raise millions per year for an operator, and the cleanup operations and cost to consumers in the US alone exceeds $2.3bn per year.

Just a few things malware usually involves:

Capturing financial information (e.g. credit card numbers) for fraud or sale.
Capturing personal information (name, address, etc.) for sale.
Sending spam messages via email or social media.
Hosting phishing sites.
Spam popups.
DDoS attacks.
Clickjacking / Cost-per-click advertising fraud.
Scareware ("your computer is INFECTED! click here to remove for $20")

All of the above can either be used to make money, or prevent competitors from making money. The trick, in every case, is to keep the malware on the system undetected as long as possible. Once a user notices something is wrong, they'll take steps to find and remove the infection. As such, the malware writers try to be as sneaky and silent as possible.

Corporate and government sponsored malware is also on the rise. The Stuxnet worm (and Flame) are thought to have been written, or heavily funded by, a government agency. There's a good chance that there are a team of malware writers working for your government. They get paid to produce malware that hinders their economic and political opponents.

So, the conclusion is that even if these groups do still exist, which I'm sure they probably do in some small form or another, they're not doing anything particularly interesting. The real work is being done buy the guys that get paid to do it, either by themselves, or by governments and unscrupulous companies.


How to download PHI PDF from a secure website to a secure, encrypted folder on Windows 7?

Idea 1. Install full-disk encryption on all client machines.  This way, the PDF will be downloaded to the machine, but it won't live in cleartext on the hard disk.  You will have to investigate whether this works well with people's work habits and whether it meets HIPAA compliance requirements.

Idea 2. Don't send a PDF file to the client.  Instead, render the document on the server side.  For an illustrative example, look at Google Docs, which renders a PDF file on the server side, converts it to HTML, and sends your browser some HTML, which then is displayed by the browser.  This way, there is no PDF file stored on your hard disk.  Obviously, you're not going to use Google Docs to render sensitive medical PDFs, but you might be able to build some simple web application or server tools to render the PDF on the server side.  For instance, you might be able to use ghostscript to convert the PDF file to a series of PNG images, then have the web page include the dynamically generated PNG images (not the PDF file itself).

One last reminder. Remember that if you don't want the contents of web pages to be stored on the user's hard disk, the web server will need to send special HTTP directives to instruct the browser not to cache the documents.  Otherwise, by default HTML pages will be stored in files on the hard disk in the browser's disk cache, so even non-PDF pages could end up stored on the client machine's hard disk if you are not careful.


Using old router as wi-fi extender/extra security on shared network?

I have this problem.

I solved it by using a WiFi media bridge to connect to the existing WiFi, connected that to a firewall, then could connect another device behind the firewall (another AP with a different password if necessary).

It protects things like my file stored on my NAS and prevents users from directly connecting to my devices.. however as the Internet activity still goes over the main WiFi link you have to assume that could be read by others.

Of course it depends what you're trying to protect and what your risks are, for me it was the data that was on my devices, not my Internet activity.


I personally would not attach any security to periodically re-installing my operating system, as it would also leave a window of out of date software when you just re-installed your operating system.

There are other ways to limit the chance of infection:

correct mindset (don't just click everywhere)
up to date operating system and software
anti-virus and firewall
Host based intrusion detection system (not widely deployed though, but can be a plus)

And in the event you do get infected, then you need to make sure you can roll back to the latest uninfected backup and patch the hole which made infection possible in the first place.

  Would periodic OS re-installation be useful in a company environment?

No not a chance, you don't want to start from scratch. What you can do is have have a clean image containing all your software and which is up to date. This is common practice in companies and is called a golden image or golden build.


What security practices should I keep in mind during development?

From the top of my head :

the API server's security, which means you may need to hire a competent sysadmin to take care of it if you aren't experienced with system administration. Whatever security you implement on top of that (API authentication, etc) becomes moot if your server itself is compromised. Keep in mind that every software installed on it is a liability and only install what you'll actually need, for example do not leave a PhpMyAdmin instance installed just in case you need it.
separate the server that hosts the API from the one that hosts your public-facing website, ideally your public website can be compromised without any risks for the app's data since it resides on a separate machine.
run away from shared hosting. It may be tempting to sign up for a shared hosting plan (they're so cheap and don't seem to require any maintenance) but their security is disastrous (even more if they're using this cPanel mess as the hosting server is most likely already compromised) and a code execution exploit on someone else's site can be leveraged to use a kernel exploit, get root access and compromise your API and data.
harden your web stack to not execute arbitrary PHP files - if you're using a framework (you should), the only file that should be executed is the framework's entry point (usually index.php), that way even if a rogue PHP file somehow finds its way onto your server, it won't be executed and you will still be somewhat safe (make sure to check how the file got there in the first place and whether any other code execution occurred). Read my somewhat-related answer from my old account.
of course make sure to handle user input correctly, hash passwords correctly and check out OWASP.
every piece of personal data you collect is a liability in case your server gets compromised (it's only a matter of when) - do you really need user's phone numbers ? (sending them SMS spam isn't a correct answer, and neither is 2FA authentication as it can be done completely offline using TOTP/HOTP without requiring phone numbers)
harden the server's TLS configuration - allow only the strongest ciphers supported by your target market, for example if you target iOS7 devices then allow only the strongest ciphers supported from iOS7 and upwards. If targeting iOS8 do the same but only allow the ones supported by iOS8, disregard any weaker ciphers as you don't care if older devices won't support them. Enforce forward secrecy if the ciphers you chose allow it. Use your own CA to sign your API server certificates and embed that CA cert into your app to prevent any other CA from posing as your server (remember DigiNotar?).
add some rate-limiting and strong captchas for repeated actions to thwart bruteforce and spammers.
avoid embedding third-party analytics code into your app - not only is that disrespectful to the user (the fact of opening your app shouldn't ping some third-party's analytics server, no matter how secure it is) but that can also hinder security as they may have vulnerabilities or lower security requirements (allowing weaker TLS ciphers, etc).


How would I go about rebuilding the IAT of a packed executable?

Ok, I said I would go for an answer and here it is, as promised.

Firstly, I wanted to build an actual target to play with. There's nothing like a working, touchable example, and this is very much a manual process. So, without further ado, I compiled this in MSVC with /MT:

#define WINVER 0x501
#define _WIN32_WINNT   0x0501
#define _WIN32_WINDOWS 0x0501
#define _WIN32_IE      0x0501
#define UNICODE

#include <wchar.h>
#include <windows.h>

int APIENTRY wWinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPTSTR    lpCmdLine,
                     int       nCmdShow)
{
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);

    MessageBox(NULL, L"Hello, world.", L"A messagebox", MB_OK | MB_ICONEXCLAMATION);
    return 0;
}

We'd fully expect this beasty to import user32.dll!MessageBoxW and sure enough it actually does.

To find this inside the executable itself, let's use WinDbg. I use WinDbg for two reasons: firstly, I can't afford IDA, and secondly, it's the same debugger you'd use for a kernel driver (even with IDA - which uses its engine) so it's good, if a little unintuitive.

I compiled my executable to UnpackSimple.exe for the x86 architecture, as UPX doesn't support Win64. Now, the first thing you'll notice when you run this under WinDbg is this line:

ModLoad: 01360000 01370000   UnpackSimple.exe

Right there, we see the address range to which UnpackSimple.exe has been mapped. This is important, because all addresses in its header are relative to 01360000.

So now, to find the header information, we can simply request it:

!dh UnpackSimple.exe
OPTIONAL HEADER VALUES

    10B magic #
   11.00 linker version
    5E00 size of code
    6C00 size of initialized data
       0 size of uninitialized data
    1193 address of entry point
    1000 base of code
         ----- new -----
01360000 image base            <--- this is the image base address.
    1000 section alignment
     200 file alignment
       2 subsystem (Windows GUI)
    6.00 operating system version
    0.00 image version

    ... blah blah blah ....

   0 [       0] address [size] of Export Directory
8D54 [      3C] address [size] of Import Directory
D000 [     1E0] address [size] of Resource Directory
   0 [       0] address [size] of Exception Directory
   0 [       0] address [size] of Security Directory
E000 [     6D0] address [size] of Base Relocation Directory
7150 [      38] address [size] of Debug Directory
   0 [       0] address [size] of Description Directory
   0 [       0] address [size] of Special Directory
   0 [       0] address [size] of Thread Storage Directory
89D8 [      40] address [size] of Load Configuration Directory
   0 [       0] address [size] of Bound Import Directory
7000 [     108] address [size] of Import Address Table Directory
   0 [       0] address [size] of Delay Import Directory
   0 [       0] address [size] of COR20 Header Directory
   0 [       0] address [size] of Reserved Directory

Oh look, one IAT! It lives at 01360000+7000 and we can persuade WinDbg to provide us that information in a fairly straightforward manner. The dps command we are about to use is short for dump pointers, dereferencing with symbols, it takes an argument address and a space per entry address.

dps 01360000+7000 L108/4
01367000  75b3d7ea kernel32!TerminateProcessStub
01367004  75b23f3c kernel32!CreateFileWImplementation
01367008  75b2520b kernel32!GetCommandLineWStub
... <snip> ...
013670f4  75b47ab2 kernel32!WriteConsoleW
013670f8  75b21410 kernel32!CloseHandleImplementation
013670fc  00000000
01367100  76bafd3f USER32!MessageBoxW
01367104  00000000

You can see some important features of the IAT here. First up is the address on the left hand side - IAT entry address. The address on the left is the in-memory address for the DLL. Finally, note there are some zero entries. Each DLL import ends with a zero entry, telling the loader that there are no more entries to load.

Now, we shall look at the disassembly of the main function. To do this, type these two commands

bp UnpackSimple!wWinMain
g

You'll then break on entry to the wWinMain above. Now, if you look closely:

UnpackSimple!wWinMain:
    01361000 6a30            push    30h
    01361002 68a0893601      push    offset UnpackSimple!`string' (013689a0)
    01361007 68bc893601      push    offset UnpackSimple!`string' (013689bc)
    0136100c 6a00            push    0
    0136100e ff1500713601    call    dword ptr [UnpackSimple!_imp__MessageBoxW (01367100)]
    01361014 33c0            xor     eax,eax
    01361016 c21000          ret     10h

Unsurprisingly, there's our function, _imp__MessageBoxW, referencing a nice IAT entry :)

So now the question is how on earth do we go backwards? Well, to first build something that just doesn't work, we need to get hold of a packed executable.

To that end, I ran upx.exe -o UnpackSimplePacked.exe UnpackSimple.exe to produce a nice packed binary. Load this binary up in WinDbg and the first thing you'll notice is that:

!dh UnpackSimplePacked.exe

Does absolutely nothing. However, we can note that:

ModLoad: 01220000 01233000   image01220000

has been seen - so the image we need is there, in memory. It just doesn't exist as an on disk image. At this stage, I am guessing that upx actually loads DLLs directly itself, rather than using the NT Loader. We can prove this two ways: firstly, if you type sxe ld into WinDbg, it'll break on all module loads. No breaks occur for user32.dll, nor is it loaded already.

Secondly, as you wanted to see:

    0 [       0] address [size] of Import Address Table Directory

It's completely empty.

However, if we check the loaded modules list:

lm
start    end        module name
00210000 00223000   image00210000   (deferred)
74c20000 74c2c000   CRYPTBASE   (deferred)
74c30000 74c90000   SspiCli    (deferred)
74d80000 74e20000   ADVAPI32   (deferred)
74eb0000 74f4d000   USP10      (deferred)
74f50000 74f5a000   LPK        (deferred)
75030000 750dc000   msvcrt     (deferred)
755a0000 755b9000   sechost    (deferred)
75720000 757b0000   GDI32      (deferred)
757e0000 758d0000   RPCRT4     (deferred)
75b10000 75c20000   kernel32   (deferred)
76ab0000 76af7000   KERNELBASE   (deferred)
76b40000 76c40000   USER32     (deferred)
77550000 776d0000   ntdll      (pdb symbols)

As you can see, USER32 has space allocated ready to go.

Now here's some trickery. I opened up another WinDbg Window with my UnpackSimple.exe version and found the address of user32!MessageBoxW. Having got this, I found it to be 76bafd3f from a base offset of 76b40000 giving me an offset of 6FD3F. In my packed version, I set a breakpoint on bp 76b40000+6FD3F and sure enough, there was a stack trace!

k
003cfd0c 013a1014 USER32!MessageBoxW
WARNING: Stack unwind information not available. Following frames may be wrong.
003cfd6c 75b233aa image013a0000+0x1014
003cfd78 77589ef2 kernel32!BaseThreadInitThunk+0xe
003cfdb8 77589ec5 ntdll!__RtlUserThreadStart+0x70
003cfdd0 00000000 ntdll!_RtlUserThreadStart+0x1b

The dissassembly at the location in image0... looks like this:

013a100e ff1500713a01    call    dword ptr [image013a0000+0x7100 (013a7100)]
013a1014 33c0            xor     eax,eax
013a1016 c21000          ret     10h

Now we're getting somewhere! At that address you'll find some interesting data:

db 013a7100
013a7100  3f fd ba 76 00 00 00

Funnily enough, there's our address! 76bafd3f in good old little endian. Let's step back a bit:

db 013a7098
013a7098  a0 22 57 77 60 22 57 77-c9 14 b2 75 ff 10 b2 75  ."Ww`"Ww...u...u
013a70a8  7b 44 b2 75 9c 17 b2 75-91 d1 b4 75 71 51 b2 75  {D.u...u...uqQ.u
013a70b8  45 49 b2 75 c4 d1 b4 75-13 49 b2 75 b3 d1 b4 75  EI.u...u.I.u...u
013a70c8  46 e0 57 77 f1 24 59 77-0d 17 b2 75 46 19 b2 75  F.Ww.$Yw...uF..u
013a70d8  2a 30 58 77 61 48 ba 75-83 46 b2 75 07 7c bc 75  *0XwaH.u.F.u.|.u
013a70e8  28 13 b2 75 bf 45 ba 75-ef c7 b3 75 b2 7a b4 75  (..u.E.u...u.z.u
013a70f8  10 14 b2 75 00 00 00 00-3f fd ba 76 00 00 00 00  ...u....?..v....

I see pointers!

This is the IAT we found previously, or at least an array of IMAGE_IMPORT_DESCRIPTOR thunks.

So having got this far, what remains? Well, we'd need to search through the dumped memory to try to find functions which match known Windows DLLs. From there, we can begin to reconstruct a full IAT for our new PE file. I suspect the process ImpRec goes through, as described in Viv's answer is to attempt to find these entries as I have done manually. I've chosen to use breakpoints, but there are a number of ways this could be automated differently, I imagine. I've never written an automated tool to go through the process by hand...! That said, at a guess hoovering up call ptr instructions, looking at their entries outside of a mapped region then attempting to find those against known DLL offsets would do the trick.

Two notes:

I've written this answer as a "here's how I'd attack it manually" type answer, with relevant background, not a "use this tool".
Watch out for ASLR. Those module addresses will keep shifting around, so keep an eye for changing module bases!


What I need checking when analysing an invasion?

The secret to discovering how you were hacked usually lies in preparation before the attack rather than after, configuring all systems to send logs to a central log server for example. This is because many types of malware packages delete logs to cover their tracks and make recovery difficult; if systems forward their logs to a central server it helps preserve the record. If there's no central logging it's possible there's nothing for you to find, but here's how I'd attack the problem anyhow.

The ultimate goal should be to establish a timeline, of which systems were hacked, how they were hacked, how the infection spread, and how long it was until the attack was detected and the systems taken off-line. All the information you gather should go into this timeline. Once the timeline is complete you can then use the timeline to reconstruct the sequence of events and the likely impact.

If your office is on an ADSL line then it's unlikely you have any externally-facing servers, most likely all connections originate from the inside of the network. This means it is unlikely that anyone penetrated your network from the outside, most likely somebody was infected by opening a malware file sent in an email (most likely a PDF), or being tricked into browsing to a hacked site. It is also possible that somebody brought the malware in on a USB stick or other type of removable media. ADSL routers are generally poor at logging (if they are even configured to do it), so I would first focus on the anti-virus and windows logs and use any available router logs to supplement.

If you have a central AD server, AV server, and the like then the job will be easier. If not you're going to have to look at individual machines affected. You didn't state how many systems have been hacked, so this may be easy or hard to do depending on the scale of the problem. I'd start with AV logs, expecting that the AV detected the malware but failed to protect the systems. If you don't find anything there look at the system logs. Keep an eye out for java or adobe reader starting, and unexpected crashes/reboots. Events like that point to successful infections.

Once you have determined which systems were affected and then you can then look at your ADSL router logs (providing you have any), and see what the infected systems did before and after infection. The before will help determine how the system was infected (by downloading an email, going to a specific website), and the after may shed light on what the malware was (ie what command and control systems the malware connected to) and what it did. It's unlikely you will be able to determine exactly what information was lost, but at least by knowing that the malware was, how long the systems were infected, and how much information was transferred you can have an idea of the impact.


startssl cert e-mail to receive verification code

Do I have to be the explicit owner of a domain to a get a publicly recognized certificate ?

Of course. It would be very bad if somebody could get a publicly trusted certificate for a domain owned by somebody else since this certificate could then be used in a man in the middle attack. The whole point of the server certificate is that it identifies the real server for the domain and not some man in the middle claiming to be the domain.


Private Key Storage in a Java Desktop Application

let's start with this one :

Do I need to encrypt theses keys?

1:
if you have communication machine to machine or application to application you can use encryption combine with  HMAC and initialization vector ( iv ) in this way you can make your keys safe from MITM and similar attack .

2:
but if you need to authentication to a server side  with a  none-encrypted key  in this way you can't protected them.

3: protection your application from revers engineering -> you can't sorry , but i can give you  a list of technique to  make it very very hard to reverse it  :

· Anti API Spyer

· Anti Breakpoints

· Anti CrackTools

· Anti DumperPro

· Code Encrypt

· Code Replace

· Debugger Guard

· Dynamic Encryption

· GarbageCode

· int DebugShield

· Memory Guard

· Mutator Engine

· Polymorphic Layers

· Secure API Wrapper

· Secure Entry Point

· Compression

· Metamorph

· Thread Engine monitor

you can search google for more details  about this technique.

Where is the best place to store it?

if you use the method above  to protect your application from reverse it's better to put them in private field in a class.

other wise in Linux put them in file as you know every thing in linux or UNIX is file with 600 as permission .

in windows put them in registry.

--> you can use steganography(watermarking) technique


Is there any way to verify that an organization operating an open-source SaaS is using an untampered-with version of the software?

Short answer - almost no way at all to tell. The question is equivalent to black box probing. You can put certain inputs to the box and get certain results - what exactly is the box doing between input and output? Can't tell. What other processes or devices have access to the same storage devices? Can't tell.

The "almost" is because there may be sideband attacks that let you determine some aspects of the platform. For example, sideband attacks in JavaScript allow sandboxed browser code to determine activities outside the browser (recent attack),   and perhaps carefully crafted code will reveal if the platform is responding at the speed and consistency and timing it should. But its unlikely to work well, not least because the server may be virtualized and timings may vary too rapidly for such an approach for that reason, also because too many code modifications and hardware setups have potential to not create user-detectable/remote-detectable variations to any measurable indicator.


Will an SSL certificate prevent cPanel hacks?

If the problem is that somebody intercepts your password by sniffing the unencrypted network traffic then using SSL will help. This means not just installing a SSL certificate but actually using https:// instead of http:// to access the site.

If the problem is instead a security issue of cPanel or that the attacker grabs your login credentials on your own machine (malware, malicious browser plugin or similar) then SSL will not help since it only protects the transport of the data between browser and server.


The session is just a random generated token which is impractical to guess.

There are many scenarios in which stealing sessions are possible such as Cross Site Scripting (XSS) or by sniffing the traffic if the attacker has access to a networkin node between client and server.

To solve the XSS issue you need to not have validation issues. This means proper checking of user input and proper encoding if shown back to the user (output validation).

You MUST use SSL if you want to mitigate attackers sniffing your client's session tokens.

Checking IP is another layer of defence but might give issues when clients are roaming.

If the attacker can steal the session he can steal the user agent as well.


How to step through malicious JavaScript?

Don't step through it, instead use an interactive proxy (I'm partial to Fiddler, there are many others...).
When the javascript is downloaded, it will first pass thru your proxy tool - you can grab it, save it out, and then block it from going on down to your browser.

Since you know it's malicious, you'd be better reviewing the source rather than executing it, especially in the context of your account.

If that's not good enough, and you want to execute it, create a new account and login with that, from a throwaway VM.
No reason to try and sanitize potentially obfuscated and evasive malware... Just isolate it.


Vulnerability scanners reporting Google Chrome vulns even when it is not Installed

Check which files are reported as vulnerable. There are a lot of programs that embed significant chunks of Chrome - not the actual browser window (the "chrome") but the rendering engine, JS, engine, the sandboxing framework, possibly the Google account stuff (in other words, the parts that are actually likely to have vulnerabilities), and it is possible that the scanner is noticing these things. For example, CEF (Chromium Embedded Framework) is pretty common in a lot of software that wants to make a desktop version of what was originally written as a web app, but CEF components need to be kept up to date as bugs are found and patched in the Chromium code from which they come.

Of course, most apps that embed Chrom(e|ium) components are only using them to render a very limited selection of content, so the risk is generally a lot lower (harder for an attacker to slip malicious script into a dedicated app that only loads scripts from its one server than into a web browser that loads scripts from literally anywhere).


It depends on the chaining mode. AES is a block cipher, it is applied on blocks of 16 bytes (exactly). The chaining mode defines how input data becomes several such blocks, and how output blocks are then put together. Most chaining modes need to work with some sort of "start value", which is not secret but should change for every message: that is the IV.

Reusing the same IV is deadly if you use the CTR chaining mode. In CTR mode, AES is used on a sequence of successive counter values (beginning with the IV), and the resulting sequence of encrypted blocks is combined (by bitwise XOR) with the data to encrypt (or decrypt). If you use the same IV then you get the same sequence, which is the infamous "two-time pad". Basically, by XORing two encrypted string together, you get the XOR of the two cleartext data. This opens to an awful lot of attacks, and basically the whole thing is broken.

Things are less dire if you use CBC. In CBC, the data itself is broken into 16-byte blocks. When a block is to be encrypted, it is first XORed with the previous encrypted block. The IV has the role of the "-1" block (the previous encrypted block for the first block). The main consequence of reusing the IV is that if two messages begin with the same sequence of bytes then the encrypted messages will also be identical for a few blocks. This leaks data and opens the possibility of some attacks.

To sum up, do not do that. Using the same IV with the same key ever and ever defeats the whole purpose of the IV, the reason why a chaining mode with IV was used in the first place.


Is it possible to list folder from my web server if i have an empty index.html in the root folder?

You can disable directory listing in Mongoose using the following:

./mongoose -d no      [ Runtime ]
d    no               [ Config File ]

But why not password protect the directory with a .htaccess file?

./mongoose -A ./.htpasswd localhost admin pass

You'd still be susceptible to a MITM attack, so use this with SSL. While this may be a simple, lightweight web server, something like a full blown Apache will be much more hardened against exploits.


Why is php-fpm trying to connect somewhere on port 443?

After doing a tcpdump packet capture, I am highly confident that this was two things.  Both things were attempting to contact wordpress.org.  A DNS request would go out for api.wordpress.org immediately before the HTTP request would fire.

Listing themes/plugins from wordpress.org
Checking for updates from wordpress.org

I believe now the reason this wasn't triggering denials before is because it was under /var/www/wordpress which has slightly different default policies.  The new machine went into /usr/share/wordpress which seems to have made a difference.
I have left the socket requests blocked and the only harm I have suffered is I can't view available themes/plugins directly from the wp-admin panel.  A worthwhile trade off in my opinion for the security.


Is SSL key generation client-side, server-side, or both?

In SSL protocol handshake both sides generate the same encryption key which is then used for the session. It is done following this procedure, in general:

Client & server generate each a random value and send to each other
Server sends the public key to the client
The client generates a value called "pre-master secret" using both random values, and encrypts it using server's key, then sends it to the server
Now both client and server have each other's random values and "pre-master secret", so basing on this information they can both generate the same session key and start using it in encrypting the following messages.

See detailed protocol description for more in-depth explanation.


That's not exactly true. The attack can be performed against WPA not WPA2. To be more concrete against TKIP. But the attack can be only done under very special circumstances and is not conclusive. I found an amazing source about this. Is in spanish so I tried to translate it doing my best.

TKIP system is using RC4 protocol, the same as WEP with two variations:

The first is that the encryption keys are derived from the snonce and anonce values, then they are different from the authentication keys. The second is that encryption of a packet is not performed with only one key plus the initialization vector but an extended initialization vector, ie the IV plus a value known as TSC (TKIP Sequence Counter) is used. This 48-bit value changes at the same time as the IV is changing so that an IV+TSC is not reused in a channel for a lot of time (years probably).

If you are able to know the key used to cypher a packet, this can't be used again if you don't increment TSC. If the TSC is incremented then the key used to cypher the packet is invalidated. To be able to use again the key used to cypher a packet is needed that the Access Point support 802.11e QoS (Quality of Service) and WMM (Wifi Multimedia) or WME (Wireless Multimedia Extensions). These extensions can divide the bandwidth in eight channels with different priority on each one.

So based on this, if you find the key used to cypher a packet on a specific channel, with an IV and a concrete TSC, it will be used again to send a packet on other different channel. You can inject until seven valid packets while doing it before the key renegotiation period expires.

I also found this other post talking about this: Is WPA-PSK AES safer than WPA-PSK TKIP-AES?


What is "NAND mirroring", the alleged technique that the FBI will use to crack the San Bernardino shooter's iPhone?

Basically NAND mirroring means that they're opening the phone up, de-soldering the memory chip, copying it off (the "mirroring" bit) and then they either solder it back into the phone, or more likely into a socket in phone that's been deconstructed into a test harness.   This way they can try to brute force the PIN to their hearts delight, and if they run into any difficulties (too many invalid tries wipe the memory, or cause unreasonably long delays before allowing additional tries) and they just re-flash the chip with the original copy of the data that doesn't know any of this has happened, and try again.  Rinse and repeat until the correct PIN is found, and the phone unlocks.

As to not destroying the phone, it's safe to presume that they've bought a batch of test phones, and practiced the technique to the point where they're fully confident there are no gotchas, and it will safely succeed.


Why brute-force the password instead of the key directly?

Brute-forcing the key vs brute-forcing the password

Brute-force the key

To brute-force the key directly I need to keep guessing keys and attempting to decrypt the encrypted file with it until eventually the file decrypts properly. Without any extra information, I need to try the 2128 possibly key values at random.

On average I will need to do 2128 / 2 = 2127 guesses. By the way, this is a massive number! Physics reduction: one ARM assembly instruction (ADD, SUB, XOR, ...) consumes about 300 pJ ~= 3.0x10-10 Joules per instruction on a low-power embedded device. The sun contains roughly 1.2x1044 Joules of nuclear fuel. Assuming we could guess a key and try decrypting the file in a single ARM instruction (which is bananas, you're looking at millions of instructions for a reasonably-sized file), then doing this brute-force attack would require consuming 2x1015 stars! Yeah, 2127 is a massive number. Good luck with that brute-force attack. Hope you have a good electricity rate.

Brute-farce the password

The length of the password is only relevant insofar that a 16-char password has more possible combinations to guess over than an 8-char password. While your 16 character password may require 128 bits of disk space, it is certainly not 128 bits of security. For starters, there are only 95 printable ASCII characters, so for a password that only uses keyboard chars (no accents, emojis, etc), at best you're looking at 9516 ~= 2105 possible 16-char passwords to guess. On top of that, we know that 30% of accounts on the internet have a password from the top 10,000 passwords [source], so the length is actually irrelevant if you're one of those 10,000.

Putting it together

Brute-forcing the password, if this is some random internet user (ie they are inventing their passwords the way the average internet user does), then you have a 30% chance of cracking it in the first 10,000 guesses. If I'm brute-forcing the key directly (without using any extra knowledge), then I have a 0.0000000000000000000000000000000003% (3x10-35) chance of cracking it in the first 10,000 guesses.

Basically, passwords are weaker than keys because human brains are stupid and predictable. If your password came from a random generator, then this is a completely different story because it's really more of a key than a password.


Is layered encryption more secure than long passwords?

Option 1 is more secure. In option 2, we can guess each word seperately. When we guess "amazing", we get confirmation that this word is correct and we can continue to the second word. In option 1, we have to guess all four words at the same time.

You may think that one GPG offers some security, and four GPGs offer four times that security, but it doesn't work like that. GPG offers near total security, and applying it more times does not improve security.

There are uses for applying encryption multiple times, for example when both signing and encrypting, or when encrypting for multiple parties. However, encrypting things several times does not in general makes them several times more secure.


You should check with your vendor. Many Vulnerability scanners just detect a version and then assume the vulnerabilities based on that version of the software. This doesn't allow for back patching and can be an annoyance to Systems teams as far as false positives. Something like this could be happening.

Also, you seem to mention it, but you have disabled TLS 1.0 right? Attackers will try to downgrade connections and see if the server allows out of date ones, which they often do as a default, like AWS's load balancer for example (at last check).

I would never ignore a finding, if possible. Escalate to the vendor.


What's the impact of a simple certificate serial number?

The primary risk to your organization is that of someone else who gets tasked with creating an intermediate certificate, and googling for and following the exact same internet guides you found, thus producing another certificate with the exact same serial number.  This could eventually cause problems with a certificate management database, where the certificate serial numbers might be an indexed field that must be kept unique.

Security-wise, the certificate (and your organization's PKI security) is protected 100% by your root CA's signature.  The value of the serial number has nothing to do with the protection offered by the encryption.  An attacker will not be able to tamper with it or offer a substitute just because it has a low or known serial number.

There used to be an issue with MD5 having poor collision protection where a predictable serial number generator could be abused to forge an attribute of a signed certificate, but even that would not impact your organization here because you've said the serial numbers you issue now are not generated sequentially up from 1000.


Should I wait for Apple to fix the recent WPA2 KRACK exploit before downloading new apps over Wi-Fi?

You should be fine to download new apps from the App Store.

Let me start by saying that there are no known instances of KRACK being used in any exploit outside of research environments so far. Even if it is and your connection has been compromised, you should be safe using the App Store.

Logging into and accessing the App Store has been using HTTPS since 2013 (see here for more). This means that any of the communication to the App Store should be secure.

As for the apps themselves, Apple makes the process fairly secure. Each developer of iOS apps is required to apply for a certificate to sign any application they create. iOS devices use this certificate to verify the signature that the application is authentic and unchanged before installing the application (I recall sometime before 2010 when they enabled this it created a bit of a stir as it deleted any "invalid" apps). An attacker would have to have a valid certificate from Apple as a developer and modify the application's signature to their own to modify the application.

Of course, no security it bullet proof, so if you want to err on the side of caution and use the USB transfer method you describe, there would be no harm in that either.


Peer review of C# cryptography for Azure Table security

I suggest you take a look at the thread on Lessons learned and misconceptions regarding encryption and cryptology.  If I'm reading your code right, it looks like this code makes at least one mistake listed there.  (e.g., use of encryption without authentication)  Please review that page carefully to make sure you're avoiding the mistakes documented there.

More seriously, it may not be a good idea to design your own encryption format.  Rather than re-inventing the wheel (insecurely), I recommend you use an existing well-vetted scheme, like GPG or PGP, for encrypting data.  Most crypto libraries are intended for someone who is already very knowledgeable about crypto design; if you aren't super-knowledgeable about design of cryptographic schemes, then crypto libraries may lead you astray, because the primitives they provide are too low-level.  You have to know a lot to combine those primitives properly into a fully secure scheme.

By the way, I find reading code a painful and inefficient way to review a cryptographic design.  I suggest that, if you would like external review from volunteers, you should take the time to craft a specification of the encryption format, in a standard cryptographic/mathematical notation.  Roughly speaking, the specification should define the format in enough detail that someone else could independently implement it an interoperable implementation, without any knowledge of C# and without any C#-specific stuff.  Such a specification should specify the exact algorithms in use.  For instance, it might say to encrypt a message M to the ciphertext C as C = (X, AES-CMAC(K1, X)), where X = AES-CBC(K0, M), or something like that.  If you have to design your own encryption format, that's the level of abstraction which is probably most appropriate for analyzing it.  But best of all is to avoid designing your own encryption format, and thereby avoid the need for such analysis.


Purpose of using API Key in addition to password

The point of an API key is to authenticate (or at least identify) the application, and not the user. Something called an “API key” does not normally determine what data a request is allowed to access, but how many requests can be made in a certain time interval through a given user account. It's a way to impose access quotas, to avoid denial of service, without completely blocking a user just because they've used a buggy app or have used it a little more than you'd like.

If your API serves public data then there's no reason to have a password in addition to the API key. The API key is the password, in this case.


GnuPG + Yubikey: Can a trojan extract any secret key or sensitive information?

You could wrap up the rest of the answer with "The YubiKeys implements the cryptographic smart card protocol using a programmable microcontroller". So what does this imply?
Cryptographic Smart Cards
The idea behind cryptographic smart cards is that they're equipped with their own crypto processor, and are able to perform several operations:

create keys for public/private key cryptography
alternatively load such keys
sign documents (hashes) using these keys
encryption session keys for symmetric encryption

An operation not supported is extracting keys, the idea of OpenPGP smart cards is limiting impact on breaches to the time the card/key is connected to the machine. This also means that if you want a backup copy, you'd have to create the key on a computer and then load it to the smart card/YubiKey.
All this is explained in Yubico's blog entry YubiKey NEO and OpenPGP:

WARNING: You cannot backup the secret keys – so if you lose the YubiKey NEO, re-generate another key pair or other lose the key pair there is no way to retrieve it! When you encrypt a file, make sure you have a plain text backup.

Sensible Information Beyond Private Keys
You can (but do not have to) store some personal information on OpenPGP smart cards, also the vendor could do so (for example, the FSFE signs the key's original contents with their own key, including some personal information they pre-programmed). I'm not sure whether the YubiKey implements the whole OpenPGP smart card standard and I don't have my YubiKey with me right now, but I'd guess it does. Information that is always stored are the serial number and as soon as keys are created their fingerprints and creation dates. There is a signature counter that might indicate key/card usage. Furthermore, you can (but do not have to) set the card holder's name, language, sex, public key's URI and some login data.
Programmable Microcontrollers
The YubiKey actually is a full computer, and all the smart card operations are implemented in software. There might be bugs and other issues, and you cannot really verify the software, on non-development products you cannot even install your own software (which of course also applies to hardware tokens, which also could include bugs and backdoors, where you also need to trust the vendor, but software is usually more complex, less well understood and more likely to have issues).
The YubiKey (Neo) was already affected by an issue, allowing to perform crypto operations without knowledge of the user's PIN. Extracting keys was not possible because of this issue.
A very sophisticated attacker might even be able to crack open the device and read the stored information (which also applies to "dedicated" smart cards for OpenPGP and other protocols, of course).
An alternative claiming to be open source hardware and software (which would in theory enable verification, while producing your own device is probably out of scope) is the Nitrokey. I'm not sure though how to verify the software running on the device and whether you could exchange the whole software with the self-compiled (and assessed?) source code, at least you should be able to do so for the individual applications (like OpenPGP).


Controlling variables used by an application

This is generally done by reverse engineering the game to find out where in running memory these variables live within the program.  There are two ways to modify those variables.

Program Patch
An attacker can patch the executable or DLL itself if there is no integrity protections on it.  Basically the actual bytes of the program are modified to be/do something different.  As long as the program does not check to ensure no data has been changed this is a very viable option.

This can be mitigated by performing some type of checksum over the entire executable.  A cryptographicly strong hash would do.  You wouldn't want to use something like CRC32 because with enough changes to the binary an attacker could make the checksums match.

You could also sign your program.  Before executing the program it verifies the signature of the program.  If this fails then the program doesn't execute.

In Memory Patch
This technique is generally a bit more annoying.  While the program is running an attacker either injects code into it, or finds where it's living in RAM and patches the program there.  Code injection is much harder to do, but the memory patching is almost the same as regular patching.  The attacker has to perform this every time that the program is run though since RAM will get cleared.  This is much harder to mitigate since you're program is already running.

There are techniques you can use to prevent reverse engineering in general.  During portions of the program you want to protect you can detect the presence of a debugger.  Reverse engineers will almost certainly need to use a debugger to figure out exactly what pirtions of memory effect what the program does during execution. Manipulating memory in a debugger to see how the program is affected.

You can also use code obfuscation to make the disassembly or decompiling of your code much harder.

Here is a fun link in that general direction.


Apple releases updates for older versions of their software including operating systems, however at some point in time they stop doing so for a certain major version, which indicates the end of support.

Apple does not publish a clear support calendar for their software products like it does for hardware.

This page lists Apple security updates to their major software:

OS X 10.8 has not seen an update since Aug 2015
iOS 7 has not been updated since June 2014

As a general rule of OS X Apple has supported current major version along with two previous ones.


Preventing outgoing Portscan/SYN/UDP Floods in the datacenter

What is the right way to prevent outgoing attacks since most firewalls
  only offer protection for incoming attacks?

To throttle or drop traffic burst I've tried different modules in iptables. The best of which was hashlimit module. I use it in FORWARD chain.

For example, to prevent outgoing TCP SYN traffic burst and limit it to 60 request a minutes use:

iptables -I FORWARD -p tcp --syn -s 192.168.1.1/24 -j DROP
iptables -I FORWARD -p tcp --syn -s 192.168.1.1/24 -m state --state NEW -m hashlimit --hashlimit 60/minute --hashlimit-mode srcip --hashlimit-burst 10 --hashlimit-name portscan -j ACCEPT

The order of commands is important. This will slow down the connections outgoing TCP SYN packets. To see how hashlimit operates in action, run:

while sleep 1 ; do cat /proc/net/ipt_hashlimit/tablename; done

The other way is to use tc.

Disclamer: I haven't tested the exact above command and it is just for a sample.


Why would a website serve different versions of a file over HTTP and HTTPS?

The simple answer is: because it wants to! The web server can serve whatever it likes, either by configuration or coincidence.

Right now, I get the same 75916c7b file over both HTTP and HTTPS and cannot confirm your theory that the web server is serving different content for HTTPS versus HTTP. However, if you managed to access the site near the time the file was updated, it could very well be that different servers were serving the different protocols and the file update had not yet propagated to the server that served you the old file.

Remember that one URL can be served by any number of servers - the fact that you get one file from a URL does not exclude there being 20 copies of this file on 20 servers/caches, some of which may be out of date.

This a certainty in this case, as the website appears to be using Cloudfront which is a Content Delivery Network - a piece of infrastructure explicitly designed for caching files on many distributed servers for delivery at global scale.


How does DOCTYPE selection affect security of my AJAX app?

Document types (or DOCTYPE) is a declarative and semantical element which is part of the W3C specification regarding markup languages documents (such as XHTML).

Their presence (or non-presence) within a markup document does not influence a whatever security aspect when they are being rendered and processed by a web browser.

If you are writing an XHTML 1.1 document, there is a DOCTYPE for it, same if you are writing an HTML5 document.

We say that these elements are essentially semantical rather than functional.


Difference between Oracle Label Security and Oracle Virtual Private Database?

Oracle Virtual Private Database (VPD) is provided at no additional cost with the Enterprise Edition of Oracle Database. Oracle Label Security is an add-on security option for the Oracle Database Enterprise Edition.

Oracle VPD is a term used for several powerful security features like, fine grained access control (FGAC), application context and global application context. VPD policies are written using PL/SQL, and can be assigned to an individual table or view. An information request, that accesses a table or view protected by VPD, is modified according to the policy assigned to the table or view.

VPD policies can be as simple as enforcing access during business hours. VPD policies can restrict access by comparing the value of an attribute in an individual row with an application context value. Global application context allows an application context to be accessed across multiple database sessions, reducing or eliminating the need to create a separate application context for each user session.

Oracle Label Security is an out-of-the-box solution for row level security. No coding or software development is required, allowing the administrator to focus completely on the policy. Oracle Label Security provides an interface for creating policies, specifying enforcement options, defining data sensitivity labels, establishing user label authorizations, and protecting individual tables or schemes.

Data sensitivity labels provide a powerful and flexible method of restricting access to data. For example, data belonging to different organizations or companies can be separated using data sensitivity labels and selectively shared between companies by changing the data sensitivity label.

Depending on the complexity of the security policy, Oracle Virtual Private Database may be the preferred method for implementing your security policy. Oracle Label Security is best suited for situations where access control decisions need to be based on the sensitivity of the information.

Please search in internet little

Reference: enter link description herehttps://docs.oracle.com/cd/B28359_01/network.111/b28529/faq.htm


What is the likelihood of a government organization having a copy of the major .COM private keys?

Keep in mind that, even with the private key, if a site uses Perfect Forward Secrecy, it would take an active attack (MITM) to see traffic, and could only be seen after the key was acquired.  Merely capturing data and analyzing later would be insufficient.  Also, many of the large sites have multiple keys and rotate them frequently.  If you look at encrypted.google.com, for example, you'll notice that the expiration date is less than 3 months after the issue date for the certificate.

So, while what you describe is possible, there are technological measures that can be employed to make it more difficult for governments to conduct this kind of dragnet surveillance.


User associated email address viewable in it's personal settings

One compromised account should be enough leverage to compromise others. The user knows their own email addressed; they just need a reminder of which one they used in the account.
Knowing the email address means that the attacker can use info from the compromised account to phish the victim with something specific.


What terms should I use to define security assessment work?


Would requiring multiple passwords enhance security?

It depends what you mean by "enhance security". On the one hand, yes, it's more pieces of information for a thief to steal, but on the other hand, if they can steal one password, chances are they can steal all your passwords.

For a great discussion on multi-factor authentication see this answer. by @tylerl.

The Cole's Notes is: we like to have multiple authentication elements which

  fall under different categories with respect to "something you have", "something you are", and "something you know".

Having authentication elements from more than one category (ex.: a password and a fingerprint, or a password and an SMS code on your phone) is properly called multi-factor authentication, while having multiple elements from the same category is called mutli-step authentication.

Stealing "something you know" typically requires planting a keylogger or file sniffer on your computer, watching you type your passwords, stealing the paper you wrote it down on, etc.
stealing "something you have" typically requires lifting something from your office after hours, stealing your laptop bag with the key gen token in it, etc
stealing "something you are" typically requires some kind of access to your biometrics.

So having multiple elements from the same category does add some barrier to theft, but not much since stealing all the passwords is not much harder than stealing one password, stealing all the physical objects is not much harder than stealing one physical objects, etc. Usually the inconvenience far outweighs the added security. It's much better to require thieves to perform a data theft and a physical theft, etc.


How could police identify digital contraband and charge someone if it's encrypted with keys?

1.They can't guarantee it's what it's said to be if they can't retain the original binary data that makes up the evidence of the accusation.
  In such a case, they could never charge anyone without proof, and if
  they can't decrypt it, they can't prove anything.

Assuming that any confiscated or eavesdropped data is encrypted in a secure way, there is no technical way for law enforcement to decrypt it. Most legal systems in the world allow a suspect to refuse to incriminate them self. But whether or not the disclosure of passwords or passphrases is protected by these statutes is a topic of debate which is currently handled differently by different jurisdictions. There are places in the world were refusing to provide decryption keys when under suspicion is a criminal act itself and can be punished on its own independently from what a person is actually accused of. Refer to the Wikipedia article on Key Disclosure Law for more information.

But depending on the circumstances, decrypting the data might not even be necessary. When there is other strong evidence that you are involved in the exchange of illegal material, that alone might be enough to convict you in some courts around the world.

  2.Even if they, by some miracle, found a key and or decrypted it, the file could be an executable wrapped around the actual data; be
  self-modifiable; and it could attempt to use a host software program
  or OS library to delete itself if opened from a modern desktop, or
  re-arrange its own data to make it unidentified without a
  key/passcode.

That's really not an issue when investigators follow common forensic practices. Usually all data is backed up to read-only media in every stage of the forensic analysis. This is required to prevent any suspicion that the evidence got tampered with.

Also, there is no reason to execute anything you find during a forensic analysis, except in a properly secured sandbox. When you are collecting evidence for trials, the last thing you want is to give attorneys a reason to claim that all your work is meaningless because your digital forensics lab got a virus during a different case.

  One could provide the keys to open the decryption and data scrambled within it over a throw away phone number, Skype, proxy, or unidentifiable remote locations.
  In short, can't decryption prevent authority from charging anyone in the legal system?

The problem with the scenario you described is that it is inconvenient. The moment you invest more work into providing someone with an illegal copy of a media than one would have to invest to earn the money to get a legal copy, it becomes pointless. The reason why movie- and software piracy is so prevalent is not just because it is cheaper than buying but also because it's often more convenient.

There are systems like TOR hidden services, Freenet or I2P which allow people to publish and download files anonymously and encrypted. Some people use them for piracy. But unfortunately these systems do not provide the performance necessary for exchanging large files quickly and do not provide a powerful search. That makes them very inconvenient to use, which drives people to less secure but much more convenient systems like BitTorrent or one-click filehosters.

The only people who really have a reason to use encrypted and anonymous filesharing in its current state are those who want to exchange material which can not possibly be obtained legally. Not people who want to avoid paying for media but people who want to avoid going to jail because of it (or worse).

Interestingly, there were various sting operations in the past were people who were doing this did get caught even thought they did use encryption technology which was not broken in a technical way. Usually the evidence against these people is collected in much more old-fashioned ways: Infiltration, detective work and of course following the money streams.


When you buy a certificate, does the certificate authority have (a copy of) the private key?

Depending on how the CA does things, it may or may not have a copy of your private key. Usually it doesn't.

The normal method is that you generate your private/public key pair on your own machine, then send the public key to the CA as part of a certificate request. The CA assembles and signs the certificate, and sends it back to you. Your private key never left your machine, and the CA never saw it.

However, in some cases, it is a good idea to let the CA generate the key pair, and send it to you. One situation where this is desirable is for asymmetric encryption keys: if you lose a private key, then you lose all the data which has been encrypted with the corresponding public key, since you can no longer decrypt it. Therefore, encryption private keys should be backupped somewhere, and having the CA generate the private key makes it easy for the CA to enforce a comprehensive, inescapable backup system.

To know what happens with a specific CA, have a look at what they return to you: if the CA sends to you a PFX (PKCS#12) archive, then CA has the private key, or at least had the private key (whether it saved it is another matter). On the other hand, if the CA sends to you a raw certificate only, then it does not have the private key.

In any case, the whole process should be documented by the CA with which you are doing business; if the CA does not document what it does, and in particular where private keys are generated and whether they are stored or not, then find another CA. CA which do things opaquely cannot be trusted. Indeed, it is a basic requirements of all "CA best practice guides" (e.g. Web Trust) that a CA must document everything.


How to respond to a request for information on a system's architecture without compromising security?

Ideally the security of the system shouldn't be dependent on not knowing the entire layout of the system, however, it does make things more difficult.  Certainly, anything like honeypots should be removed or altered on the diagrams and you should remove key details wherever possible so long as you can still get across the necessary information.

Exactly what is needed and what isn't depends on both the system design and the questions being asked.  Simply give the minimum level of information necessary to answer the question and try to leave out any security related details where possible, but also ensure that your security isn't compromised if someone knew more about the system than you are saying.


Banking application login leaks information

Yes, this is flawed in two ways:

It allows an attacker to enumerate usernames simply by trying them and checking the response.
It allows an attacker to get your "secret" image using a non-secret piece of information. This amounts to absolutely nothing in terms of security, and is simply theatre.

On top of that, I can see another potential hole: the attacker may not even have to download the images. If all you require is a valid username, what's to stop the attacker from creating a phishing page that uses the same mechanism as the real site to retrieve the picture from the real bank's server?

The correct implementation would be to have two authentication tokens, and only show the image after one of them has been correctly entered. This is usually done via a password and "secret word", but you could equally use a strong second factor like a hardware token.


Can a corporate proxy downgrade an SSL handshake?

I suspected the proxy to modify the list of supported ciphers and this problem came out again today when a website that I regularly visit stopped working saying that the connection was downgraded to a version of TLS lower than the minimum required by the server, an operation that my web browser wouldn't do.

It is not possible to just modify the ciphers within the handshake and leave the rest the same. Since the handshake is protected by a cryptographic checksum this would cause a handshake error because the checksum inside the Finished message (last part of handshake) does not match any longer. For more details see https://security.stackexchange.com/a/20847/37315.

Changes in ciphers can only be done with real man-in-the-middle attack (or SSL interception, which is the same but sounds more friendly), where the man in the middle must change the servers certificate too. This is often done in companies to make scanning of SSL traffic for malware possible. Change of cipher is only a side effect of this, since you have independent SSL connections from the middlebox to the client and another to the server when doing SSL interception.

  I checked the certificates, it doesn't attempt to do MITM attack by issuing fake certificates.

The contents of the servers leaf certificate like subject, lifetime etc often gets replicated when doing SSL interception. But if you check fingerprint, certificate chain and trust anchor (root-CA) you will detect the difference.


Reliability of DNSBLs for Stopping Forum Spam

Though my answer isn't to use DNSBL, there are services that provide an API-level plugin to help reduce spam for such use cases.  Defensio is one that comes to mind.  I'm sure there are others out there (and no, I don't work for Websense).  Depending on the volume of posts per month, such services could be available for "free."  With that said, many DNLBLs also limit the number of requests per day.


nf_conntrack: table full, dropping packet

The message means your connection tracking table is full. There are no security implications other than DoS. You can partially mitigate this by increasing the maximum number of connections being tracked, reducing the tracking timeouts or by disabling connection tracking altogether, which is doable on server, but not on a NAT router, because the latter will cease to function.

sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000
sysctl -w net.netfilter.nf_conntrack_generic_timeout=120
sysctl -w net.ipv4.netfilter.ip_conntrack_max=<more than currently set>


How Data Link layer trailer prevents data from being intercepted and tampers

In most cases the data link layer does not prevent interception and malicious tampering. Data link layer protocols like Ethernet or PPP usually have a checksum to detect accidental packet corruption, but that's all. This "can increase security" but it does not make sure that "data can't be intercepted and tampered". Somebody intercepting data at the data link layer could simply change the checksum too so that the manipulation will not be detected.
There can be better protection at the data link layer though, even this is not common in typical LAN or WAN. There are actually products which provide L2 encryption. In most cases though application simply do not rely on security properties L2, i.e. they use network layer (L3) protection with VPN like IPSec or use application layer protection with TLS like in HTTPS.


What does this activity record of gmail mean, when it says an authorized application with IP from India?

The accessor claimed to be "Yahoo Mail Client", so either it had to do with you using the Yahoo Mail Client, or coincidentally an attacker also used the Yahoo Mail Client while accessing your account.

The IP address shown (74.6.109.229) seems to be owned by Yahoo: https://db-ip.com/all/74.6.109. It's really unlikely that it is an attacker accessing your account (unless they're coincidentally doing it through a Yahoo server).

Another geo-IP database shows the IP as being in California (https://www.ultratools.com/tools/geoIpResult), so it's probably safe to disregard the detail in the message from Google claiming that the access was from India. Chances are that Gmail is just operating with an old geo-IP database. (Though even if it is from India, it seems to be from an IP block owned by Yahoo, so it would still likely be an Indian Yahoo server.)


Here there are a lot of .iso containing ctf:
https://www.vulnhub.com/
there a lot, some are stupid , others are more interesting.

Then there is exploit-exercises.com that has some very good ctf box.
Another is www.root-me.org that has a lot of challange and some ctf too.
Anyway, a ctf that is "not vulnerable by design" doesn't exists. You can take some open source project and try too find some vuln, or maybe look
for https://bugcrowd.com/ , that lists all bug bounties


How can WhatsApp be listed on the EFF secure application toolset when it's not opensource?

They do have reservations:

  WhatsApp does still provide end-to-end encryption, which ensures that a message is turned into a secret message by its original sender, and decoded only by its final recipient. We take no issue with the way this encryption is performed. In fact, we hope that the encryption protocol WhatsApp uses, the Signal Protocol, becomes more widespread in the future. Instead, we are concerned about WhatsApp’s security despite the best efforts of the Signal Protocol.

My emphasis. They provide a guide for making WhatsApp better privacy and security-wise. They do note that they see problems with it.


Yes, it's possible.

The WCE product you reference works by scraping passwords directly out of memory.  That method also works in Linux; a rootkit which has unfettered access to memory and can hook system calls can extract passwords from there - consider this example, which can steal username and password pairs

Both solutions are limited in that they

can only capture passwords as they're used - someone has to log in to have their password compromised, it's not dumping the authentication store for everyone.
require the OS to be hooked - let's just say compromised - at a deep level.


Is it safe for both client and server to use the same keypair in CurveZMQ?

The question you should ask yourself is: what are you trying to protect?

If you distribute your key between all peers and if proper key distribution is "too complex" for your use case, then you might as well disable encryption altogether: your keys ain't safe and so your messages ain't either. Even if you enable FS, you will not protect your system against MITM attacks.

Perhaps a better direction to look into would be implementing a key distribution system: have a central CA server allow for automatic client enrollment using whatever authentication mechanism you deem sufficient for your needs and simply have everyone trust keys issued by this CA. That would keep peer-to-peer communication secure while allowing you to scale it pretty much indefinitely.


How to support Forward Secrecy in OpenSSL

can I fix that in the build options of openssl ?

The problem is not your OpenSSL build but the configuration of your unknown server. In order to enable forward secrecy you need to enabled ECDHE and/or DH cipher suites in the server configuration.

For examples of recommended configurations see Security/Server Side TLS.


How can I ensure that default passwords are no longer in use?

So much depends on context - see @nealmcb comment.

If it's for an operating system, most OS's these days offer a setting for "change on first use"

If it's for an application you control, don't provide users with a default password - generate a unique password for them which expires on first use.

If it's a device shipped from vendor - trickier, unless you can persuade the vendor to do this for you.

In summary - various different options, but you need to place the question in context or you may not get useful answers. See the "what background" section in the faq.


(1) Does the verification of the chain end there or does it continue on until we get to D?

it depends on a certificate chaining engine (CCE) implementation. Different platforms have different implementations which may not support all recommended/mandatory validation logic described in RFC5280.

Certificate trust requires an end of chain point which is presented in a self-signed form (we call such certificate as Root CA certificate). Since certificate B is not self-signed (it is signed by C), the A-B-C-D chain is not trusted until C and D are fetched and validated. So, the answer to this question is: the chain continues validation to the root.

If we talk about Microsoft implementation (just an example which I'm familiar with), their CCE builds one or more chains (as much as possible) without performing immediate validation. They just fetch certificates and attempt to perform basic rules to bind each certificate at the correct place in the chain. When all chains are built, each of them are validated according to rules described in RFC5280. Once validated, there might be a case that there are multiple trusted and valid chains. CCE uses its own selection logic to select only one chain from a collection of chains.

When we talk about cetrtificate stores in browsers, they are used to:

establish a trust to a particular trusted root CA (Trusted Root CA store). These certificates MUST be presented in a self-signed form. Otherwise, they cannot be used as chain endpoint and the trust is not established (even though, the intermediate certificate is installed in the root store).
help CCE to quickly build the chain without having to download missing certificates from internet, because they are available locally. Some brwosers completely lack an ability to process Authority Information Access extension, which means that SSL client is able to fetch CA certificates only from two sources: SSL handshake, local certificate store.

  (2) When a server presents it's certificate chain to the browser, does it present the root certificate D as well or does in only present A-B-C?

it depends on a web server implementation. A reference from RFC 5246 §7.4.2:

  certificate_list
        This is a sequence (chain) of certificates.  The sender's
        certificate MUST come first in the list.  Each following
        certificate MUST directly certify the one preceding it.  Because
        certificate validation requires that root keys be distributed
        independently, the self-signed certificate that specifies the root
        certificate authority MAY be omitted from the chain, under the
        assumption that the remote end must already possess it in order to
        validate it in any case.

RFC suggests that root CA certificate MAY or MAY NOT be sent to client. As the result, when developing SSL client you should expect that root certificate may be shipped along the chain. Two major web servers: Apache and IIS by default DO NOT send root certificate during SSL handshake.


Can https with an invalid certificate automatically redirect to http?

If the SSL cert is invalid, can an https connection automatically redirect to http?

The redirect is sent with the HTTP protocol. With HTTPS you first establish a TLS connection and then HTTP is spoken inside this TLS connection.  This means  a redirect from a https://site UrL to a http://site URL  most first establish a successful TLS connection and only then the redirect will be sent by the server and executed by the browser.

But if the certificate is invalid the TLS connection will fail already and thus the redirect will not happen.


Sign certificates using a web server certificate issued by a public CA

My question, is this a bug in OpenSSL?

You could consider it a bug in OpenSSL that it allows signing by a non-CA certificate. But even if OpenSSL would refuse to do this you could simply change the source code to allow it again. Thus it does not matter much if the code allows you to create such a certificate.

  Can this be used as an exploit?

Instead the problem would be if somebody would accept such a certificate. Thus if someone presents a certificate it need to be fully validated by the peer. This validation includes checking all constraints, including that the issuer was a CA.

In the past several implementations had problems with this complete validation and some ignored the CA flag, so in this case the issue could be exploited. But again, this is not the problem of the application used to create the certificate but the one which failed to verify the certificate properly. Because identification by certificate should protect the TLS connection against attacks the application should always assume that an attacker tries to circumvent the validation and thus always do a complete validation of the certificate.


Can I hide information from the device I use to encrypt it?

There are certain algorithms that allow you to do calculations on encrypted values. http://en.wikipedia.org/wiki/Homomorphic_encryption however the things are still slow and impractical.

What you can do in your example is create two 'machines'. When you insert a ballot in your apparatus, one machine independently counts votes (which hole you punched), the other independently keeps track of the randomizer on the ballot card. You can later then merge that data to count the vote in a third machine.

Machines here could be virtual or even separate scripts, depending on the degree of physical separation you need and how 'trusted' your code is. Independently the data sources do not mean anything to either machine, only when you put them together will it 'resolve'.


Should company protect DB schema at the same level of the data itself?

No

Protection of the database schema is a type of security by obscurity.

Your software should be designed and configured in such a manner that none of its security is compromised when a hacker learns its design.  In fact, in the best case your design is made public so that security professionals can critique it and you can continuously improve it.


What threats does a stateless web application have?  (as opposed to a  "state-full" sessions)

Certain DOS attacks become feasible with a smaller number of misbehaving clients when it is unpredictable which real machine will service a particular request.

Send a series of messages which cause the receiving shards to fetch data into memory paging out most of anything else that is resident.
Switch to send a series of messages which cause the receiving shards to fetch a different set of data into memory paging out whatever was fetched by 1.
Repeat.

When allocation of messages to shards is random or mostly random, that randomness can be exploited to DOS a group of machines by a smaller number of attackers if an alternating set of messages can cause those shards to spend most of their time filling caches instead of handling requests.

With a stateful system that shards based on session ID, you need to be able to cheaply create sessions or have a large number of attackers that can each keep one expensive session.

Obviously, for certain applications it may be possible to define a stateless system that doesn't swap to disk.


...  that are parsed by an appropriate library

Can one create such an appropriate library which will look for payload inside arbitrary images (not only metadata), extract and execute it? Yes, this is possible.
Will a "normal" library behave this way? No, it will not. It might have specific vulnerabilities which can be triggered by interpreting the image in the wrong way, i.e. making wrong assumptions about needed buffer sizes, value of parameters in image etc. This is only about metadata but about the encoded pixels themselves, especially if compression is involved - like in CVE-2020-1895.
But a universal vulnerability, which can be attacked regardless of image format, is very very unlikely to happen by accident. It could be part of a deliberately placed backdoor though. Or it could be a way to hide a more complex second stage payload which gets retrieved and executed by a small initial attack payload.


Satellite dish giving off RF signal with no reciever

In principle, yes- it is just an antenna and you can use the to send and receive.

In reality, you'd need to replace the receiver circuit with one that can also send - these are cheap so relatively easy to do. You would need to think about where you are sending data to, as those dishes are very directional.

So point to point link would be do-able,  althiugh it might breach local transmission regs.

In reading this back, it isn't a security question so may get migrated or closed.


I would go there and look right now but my Wife is right next to me so its probably a bad idea. A good place to find information about this is here: https://www.google.com/policies/technologies/ads/

Different sites use certain cookies that basically profile you and store that information remotely.  When you go to another site that is using the same services, they can request an ad, and something relevant to your past browsing history or location will be served up.

This is usually done by the use of cookies.  For example, google uses the id or IDE cookie stored in browsers under the domain doubleclick.net. Any site can use google's api to serve you content that is relevant to you.  There are many more sites and cookies that do the same.


Is there any way to use an external form (like the one above) to send a malformed GET request with POST data to achieve this CSRF

A GET request with a body has no meaning. To cite RFC 7231 section 4.3.1:

A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.

Since it has no meaning you cannot send a GET request from a browser with a body.


It is very important for you to understand that ANY input from the users has to be sanitized in one way or another, or you are potentialy opening up for security holes.
Any input could mean dropdown boxes or other data you would think is static. Examples of this is simply anything returned from the user like for example:

Radio buttons
Dropdown boxes
Data coming from plugins like flash, silverlight and so on.
Simply anything that is sent to the client!

To better illustrate this I encourage you to download a simple proxy which will enable you to show all the data being sent to your server when submit a form. An example POST request is shown here:

POST /api/rest HTTP/1.1
Host: api.example.com
User-agent: Googlebot/2.1 (+http://www.google.com/bot.html)
Referer: example.com/admin.php
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Cookie: username=karrax&password=855425718dfe4a50f6f0bbb9335d3c3b&userid=591

dropdownBox=string&staticTextField=string&hiddenElement=string

Anything that you have to rely on in your business logic coming from the client side has to be cleaned.

Remember that this goes for anything coming from the client side. IT CANNOT BE TRUSTED! ... Even if it is simply a string being returned to the client (e.g. a username) it should be cleaned so that it is not vulnerable for cross site scripting and other attack vectors.

Edit: As @Avid pointed out in the comments it is also imperative to know that data passed through cookies is also sent from the client side, making them vulnerable to tampering. This also applies for any other field in the headers (or anything coming from the client) like the user-agent or referrer field to name a few.

In the example above the HTTP request may foil some security systems if they rely on the referrer field to for example authorize the user. The example also makes it appear that it is the Google bot which may in some circumstances provide different content on the page you are requesting (source).


If the drive is using Logical Disk Management and you acquired the physical drive (instead of the logical drive presented by Windows), then Autopsy won't know how to interpret it.  It doesn't currently have LDM support.


If you are working in a language which gives you access to the memory locations of the strings being entered, you could overwrite the sensitive information with null bytes when the user leaves the page/stops entering input for a certain amount of time.


If you suspect a local device such as a fax machine being unintentionally forwarded, change the id of the device.
If you can recall when this first started, it may shed some light on this.
I would look for teleconferencing voip equipment as well.
Why was this listed as fraud -- did you have prior issues with fraudulent calls?
Do you have any disgruntled employees leave the company?
Changing vendors due to inadequate support or to an SLA issue is enough to get out if your contract. Sounds like the best way to go if you are remaining calm and collected when dealing with their tech support, etc.
   Hope that helps...


What happens when the wrong key(3rd parameter) is used in openssl_decrypt() in PHP?

This is likely because openssl_encrypt uses PKCS7 padding by default.  The FALSE likely occurs when the padding is invalid.

It is possible to get the wrong result of decryption if the padding is kept intact.  You should use an authenticated mode like GCM or append an HMAC.


Password shown on screen after crash on Linux, any idea why?

In fact, it can be worst. I just take some check on Ubuntu Crash Reporting  and I found this.

  Bug reports about crashes which are automatically generated by the
  Apport system are now private by default. This avoids exposing
  potentially sensitive data like passwords to the public. Those bug
  reports are now inspected by a trusted Ubuntu developer before marking
  it public.

There is no indication which version(s) is/are affected. IMHO, to prevent password leak, you should either upgrade Apport or disabled it.

This issue is documented/highlight under Apport wiki

  Apport collects potentially sensitive data, such as core dumps, stack traces, and log files. They can contain passwords, credit card
  numbers, serial numbers, and other private material.

(update)
This issue need further scrutinize, because there are confusion of ecryptfs and login passphrase vs mount passphrase.


Please clarify what you mean by device?

I am assuming mobile phone/tablet, in which case I can answer for Android based devices. Simply having a passcode/pin set to lock/unlock your android device does not encrypt the data stored on the devices flash memory. This is an additional setting that can be configured under Settings - Security, usually titled "Encrypt Phone" or similar.

Most phones will have this setting off by default, however Marshmellow (Android 6.0) now has encryption on by default. Turning this setting on will usually result in having to enter your passcode at boot time (when you switch the phone on) in order to decrypt the storage before the OS starts up.

Some versions allow you to set a different passcode for the disk encryption to the one you use to unlock the phone, which allows you to set a longer more secure password without the inconvenience of having to enter it every time you unlock the device.

I believe the latest version of iOS also has encryption enabled by default, however I am not an iPhone user so perhaps someone else can confirm this.


You can establish a secure tunnel using SSH, OpenVPN, or any other VPN service.  Search this site for information on setting up a VPN.

Is it possible your ISP is blocking DNS access to those sites?  If so, there are two steps you can consider:

Route DNS through the SOCKS proxy.  You may need to configure your browser to do this.  On Firefox, set the network.proxy.socks_remote_dns configuration setting -- but see How to secure Firefox traffic (+DNS) through SOCKS proxy under Ubuntu 10.04? for some information that may be relevant.
Manually configure your computer to use a DNS server of your choice, not the ISP's DNS server.  You could use Google's DNS server (IP address 8.8.8.8) or OpenDNS.  Note that this may work (e.g., if the ISP is filtering its DNS responses in its own DNS server), but it may also not work (e.g., if the ISP is using dynamic packet inspection to inspect and modify all DNS traffic regardless of destination).

If simple solutions don't immediately work, I'd seriously consider trying a VPN or Tor (either Torbundle or a LiveCD).