Should IDM be private or exposed for app login?

I am not familiar with the acronym "IDM", but for this answer I will assume it means the same as an Identity Provider (IdP) in the SAML / OIDC sense.
The only difference I can see between those diagrams is whether you use your login page, or keycloak's login page.
I see your concern that Option 1 exposes the IdP to direct attack, but isn't your login page just a shallow skin for the keycloak login page? What are you really hiding? Do you believe that your developers can build a better and more robust login page than the keycloak developers?
Also consider also these points:

With Option 2, your application never handles passwords, which can save you substantial engineering effort to harden and protect them. Also, if you are in an audited environment, being able to say "We don't handle passwords, and here are keycloak's security certifications" is a much easier story to tell.
With Option 2, you can configure your app to accept 3rd party identities that your app should not ever see the password for -- for example if you allow partners to log in to your platform by authenticating against your partner's Active Directory. Same if you want to allow users to link their Google or Facebook accounts, etc.
Sometimes the fact that the client (browser) can reach the IdP is actually an important piece of information; for example if the IdP is in a backend prod network or a corporate network (ex.: ADFS in front of the prod AD), then redirecting their browser to the IdP proves that the client is also VPN'd into the backend network.

Summary: I don't see a security upside by replacing the IdP vendor's login page with your own; and actually a lot of security downside if the login page you build is less robust than the one built by a security specialty vendor. Also, Option 2 gives a lot more deployment flexibility, which you can leverage for increased security.


You cannot change the certificate but you can revoke it and issue a new one; or, keep the old one and let it expire on its own while issuing a new certificate for future email messages. The issue with revoking a certificate would be errors occurring if a mail client checks for revocation. To avoid this you can just leave the early certificate as valid and issue a new one as well. Any new email messages would be signed with the new certificate containing all of the email addresses.


Unfortunately, you cannot counter it without being technically incorrect.

Per Wikipedia, the definition of a Man in the Middle attack:

  "In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other."

The website owners who configure their site to use Cloudflare do not believe they are communicating directly with the visitors, so under the technical definition it's not a MitM attack.


Layer 4 (Transport) DoS attack is often referred to as a SYN flood.

Layers 5,6 and 7 of the OSI model are referred to as the application layer within TCP/IP. Which you mentioned as "Application-Layer-DoS (ALDoS), on layer 7". However, an application layer flood, could be referred to as XDoS. Unfortunately, besides DDoS Quick Guide by National Cybersecurity and Communications Integration Center, 29 January 2014 I could not find much regarding the OSI model for DoS. Instead, most documentation speaks about the TCP/IP model for DoS.

From DDoS Quick Guide I was able to determine these examples for the OSI Model though:

Layer 5 (Session) - Telnet DDoS attack
Layer 6 (Presentation) - Malformed SSL Request
Layer 7 (Application):

PDF GET request
HTTP GET
HTTP POST


Why did my DoS attack fail against Windows 10?

You assume that it's a software difference that enabled the Win10 box to survive. But the devices that fell have much reduced hardware. You likely just flooded the CPU/memory of the IoT devices and tablets. They are not designed for even small levels of direct traffic to them. A Windows laptop is.
When playing with network traffic you need to run packet captures to gain insight. Otherwise, you're just guessing in the dark.


Two-factor authentication w/certificate and username & password?

The question is a bit hard for me to decipher, but I am going to assume you are considering authenticating users by having the user present a username and password, and also having the user authenticate with a private key (client cert) that is stored on the user's device.

Short answer: yes, this is generally beneficial. If the user authenticates by both a client cert and a username/password pair, then yes, I would consider this two-factor authentication.

Even more important than whether it "counts as" two-factor authentication is whether it adds security, and whether it meets your security needs.  Generally speaking, I would say that yes, this approach is useful and does add security, compared to just using username and password.  You haven't provided enough information to assess whether it is adequate to your business needs, but I can share some thoughts on the strengths and weaknesses of this approach.

Security analysis. Generally speaking, requiring the user to authenticate using both a client cert and a username/password pair should be more secure than either one alone.  I'll assume the client's private key is stored only on their device, and the user's password is not stored on the device.  Here are some benefits:

Benefit: Security against social engineering. One weakness of passwords is that, since users know their own password, users can often be tricked into revealing their passwords, for instance by phishing, by spoofed email, by someone pretending to be from the IT help desk, or other forms of social engineering.  Client certs address this risk: the benefit of the client cert is that the private key is a secret that the user does not know, so the user cannot be fooled into revealing it.  An attacker may still be able to use social engineering to steal the user's password, but they won't find it easy to steal the user's private key, so they won't be able to get access to the user's account.
Benefit: Security against password guessing attacks. Another weakness of passwords is that users often choose poor passwords (which can be guessed through dictionary attacks).  Also, users often reuse passwords on multiple sites, which means that a compromise of one site can negatively affect the security of the others.  Client certs eliminate this problem: the private key is chosen randomly by a computer, and thus does not have problems with low entropy.  Consequently, even if an attacker can guess the user's password, the attacker cannot gain access to the user's account.
Benefit: Security against lost devices. One shortcoming of client certs is that the private key is stored on the user's device.  Thus, if the user's device is lost or stolen, the private key is compromised and the new possessor of the device may be able to access the user's account.  Using a password in addition to a client cert addresses this threat.  If the user's device is lost or stolen, the recipient of the device probably won't be able to access the user's account, because the recipient won't know the user's password (assuming the user did not choose a password that was totally terrible).

However, there are also some limitations and pitfalls with this approach which are worth being aware of.

Limitation: Does not defend against client-side malware. This form of two-factor authentication does not defend against malware or spyware on the user's device.  Such malware can record the user's password and also grab a copy of the user's private key, thus capturing all credentials needed to access the user's account.  So, if you are concerned about client-side malware, you will need to use some other approach to mitigate that threat.
Pitfall: Don't store the password. There is a pitfall with this approach.  If you store the user's password on the user's device, then the password just becomes one more secret on the device; the security is then no better than just using a client cert.  In particular, at that point, if the user's device is lost or stolen, all the information needed to access the user's account is present on the user's phone, so the user's account must be considered compromised.  Therefore, if you are writing a custom client app, it is important that you avoid storing the user's password on the user's device.  Similarly, if this is intended to be accessible over the web, you must ensure that the user's password is not stored in their browser password manager.

Caveat. One word of caution about my analysis.  I am addressing the general concept of authenticating users with a combination of username/password plus client cert.  I cannot speak to implementation details about Outlook, Active Directory, Exchange, ActiveSync, reverse proxies, or other aspects specific to the Windows environment, as I'm not familiar with those details.  I can only analyze the general approach.   If I'm missing relevant implementation details, then my conclusions may not apply to your situation.


Security implication of disclosing composer.lock?

As composer can describe the

  exact version numbers, and are useful to communicate the version you tested with to colleagues or when publishing an application

Reference #1

Revealing the version of the underlying library can be used against the application.

  composer.lock file also ensures consistency across clusters of servers

It will ensure that all the servers behind a Load balance will be evenly vulnerable which will make the exploit more stable against a target.

Reference #2


Is there a way to use private certs for accessing private websites that doesn't require installing a root cert?

If you are using Chrome, you could generate an SPKI fingerprint from the company's public key:

openssl x509 -pubkey < "pubkey.pem" | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64 > "fingerprints.txt"

Then you can start Chrome from the command line with this flag:

--ignore-certificate-errors-spki-list=$(cat fingerprints.txt)

Then chrome will treat any certificates with that fingerprint as valid and won't show the red security error in the URL bar. This will only last for as long as Chrome has that command line flag.


Are there any fast Homomorphic Obfuscuation techniques available?

There have been a few implementations of fully homomorphic encryption (2010).  Fully homomorphic means it can perform addition AND multiplication (as opposed to partially homomorphic).

The answer to your question though relies on what you consider "weak" and sufficient for security.  Does the encryption have to stand up for 100 years, or is it OK if it's cracked a week from now (short term secrets such as military troop movements)?

Anyway, homomorphic encryption really isn't ready for prime time.  It's mostly a research area at the moment.  The current "implementations" are very academic with little documentation and haven't been vetted (using encryption which hasn't been tested extensively is a fools errand).

Here's a link anyway if you want see what the current state of the art implementation looks like http://github.com/shaih/HElib/


Why is callerID spoofing not possible when using short codes?

Short codes have behavior similar to 1-800 numbers for phone calls in the US.  These provide the original number because the destination is being billed for the call, so the carrier provides the real number as part of the service.  This is provided by a different system than Caller ID, called Automatic Number Identification.


NIDS sensors placement in the network of an organization

It really depends on the network layout, and what you want to monitor.
Is the inbound or outbound traffic more interesting to you?

For bigger organizations, that probably have several offices, and server/infrastructure networks it makes sense to have dedicated sensors with a network specific configuration.

Traditional NIDS (Passive Mode)

I'd put it on a mirror port of the core of that network segment. Make sure that your hardware (NICs, switches) can handle that. For sensor reliability I would look into getting two network cards and setup bonding.

Traditional NID(P)S (In-line Mode)

The traditional setup I often come across is that the sensor itself acts as a router and handles all the traffic coming in and out. So it would be the second hop on the network for outbound connectivity, 2nd to last for inbound. There is a lot of design considerations that has to be done here to not compromise the reliability (additional packet loss), availability of the network, such as a fail-over when the sensor goes down, unintentionally or during maintenance.

This one is hard to scale, and you have to take software and hardware configuration very seriously, only enable features and rules that applies to your threat model.

A good alternative is to go for the passive route and write an agent that triggers action on certain events, such as connecting to the firewall/router/DNS server etc, and applying rules. This way you would get the same effect with less risk of compromising the availability of your network. There is some (old) software known as SnortSAM that may serve as a good example on how to achieve this.

Good reads

Emerging Threats - SnortSAM summary

SANS Institute - How to place IDS sensor in redundant networks

Strategic Sensor Placement for Intrusion Detection in Network-Based_IDS

I hope you find this helpful, feel free to ask any follow up questions. I'm very interested and trying to keep up within the Network Security Monitoring field myself, so the pleasure is mine :)


Why is FF in Kali making requests to ocsp.digicert.com?

This is perfectly normal. ocsp.digicert.com is the server used to verify if an SSL certificate issued by DigiCert got revoked. This is done using the OCSP protocol.

For example the certificates for mozilla.org or addons.mozilla.org are currently issued by DigiCert. This means it will likely check at startup for extension updates and/or browser updates by using HTTPS and will in this context check that the certificates for these domains were not revoked.


What path (programming language, courses) should I take inorder to become a network/ security developer. (Not network configuration)?

There's no straight way to develop a product. It is non-trivial thing. I'd start from the top with the learning of the networking which is basically switching, routing, load-balancing, proxying, fail-overing, firewalling (so that would be Computer Network Course), and then I'd proceed to enterprise grade programming language which aids in things like Big Data, network capture and so on.

Network Course is non-trivial but very well structured so it's easy to complete one. It takes at least a year to learn what can be done with network switch alone. However, to invent any software takes another year. And then implementing the first version may take another year. That's how the R&D works.

On the other side, I'd take course in cryptography but I'd look also on concepts like SSO, network monitoring, orchestrating. It's not as heavy as big-data but very helpful and that's were new products are heading

There's also the secret sauce of next-generation products which is Machine Learning.

Regarding network products like switches and routers, it's usually more than a switch - it's whole ecosystem of software, which includes e.g. VHDL, Verilog for hardware and C for software, which is embedded software.

You can check for job posting to find out what specific company (e.g. the one in your country or city) is using.

You can also have a look on Arduino IDE.

See here: Hardware Description Languages

However, to produce the switch or security gateway, there's a lot bigger ecosystem of things like simulation, prototyping. You can still go for HDLs if you want to develop next generation networking products.

There's also Robotics, real-time network communication, network virtualization, for each of these, different programming language is used while HDLs are the Hardware Description Languages for programming the hardware itself. There's still software running on it as well (like C or Java, depends on the vendor).

As you have some experience with Web Development you would already know APIs and things related to the web which is better than good start.

If you intend developing products and platforms, you should decide on your product architecture and technology, so you can choose whatever suits you best. Plus, you should choose something which is more decent regarding syntax and has extensive libraries for the functionality you need, for example:

Java and Scala for high performance, high scalability enterprise applications, mainly if it's going to be huge platform. The build-in language safety and threading makes it very attractive and indeed very popular. Huge number of professional grade libraries. There's everything - profilers, debuggers, editors and it's whole load of them. JRE is the #1 runtime today.
C is universal language and anything can be done and there's also huge number of libraries. If you look into kernel hacking or other linux based development, that's the way to go. It is useful to know for debugging common issues, exploits, reporting issues and so on.
C++ similarly to C, if used well can do a lot for you, whatever it's cross-platform app in QT, GTK, DirectX, OpenGL, server or engine. There's are many paid libraries to do many things, however not every library is available in C++ nor it's always free. However, for things like web browser hacking, games hacking, C++ knowledge is very useful.
Python is general scripting language. It has excellent standard library which is very important, has built-in safety and it's also very popular. There's good ecosystem supporting it as good as in Java (from developer perspective, there are libraries, editors, visual debuggers). I said almost, but it's the only thing getting close. It's ideal for development of command-line utilities. It is extensively used in many fields so there are many experimental libraries not available in other languages.
C# is what powers Windows but regarding cross-platform support it is currently in flux, the new .NET Core has small number of issues regarding importing existing libraries, and Mono is another open sourced runtime. It's good for ASP.NET. The syntax and language design is superior. There's plenty of libraries for Windows. It can be used for anything like command-line utilities, GUI applications and IIS powered websites.
PHP is good for prototyping, scripting and testing and obviously developing web pages. It builds on any server like Python. Since it was designed and optimized for web, it is very compact and very fast and can be used for many other things. It's one of the most clever languages out there. There's little bloat in everything you do.
Javascript is the only choice (along with Typestript) for building client-side applications running in web browser. It can be also used for server-side applications, however, there are not as many libraries as in Java, Python and has bigger limitations than Python. However, it is fast and compact. Syntax is the most horrible one, but there's no alternative for web browsers. It is very quickly evolving. There's new JS framework every hour.
What Perl is everyone knows. If you want to develop server-side daemon it can do the job, however, you won't have editor auto-suggestions like with Java, but Linux packaging and Docker can help you dealing with dependencies when deploying it to cloud. There's more than one library to do anything, even most exotic things. It is closely tied to the OS just like Python.
Ruby is used for generation of web pages. Otherwise there's little libraries yet but it's slowly happening. But before it reaches the level of Python it may take long time. If you are interested in porting, integrating and creating libraries that's something interesting. Also there's relatively poor editor support. Linux packages and Docker can help you dealing with dependencies.

And finally:

Swift is the next-generation compiled language which has additional safety compared to C. It's not only that, there's the whole layer of libraries with it. I am currently onto it myself so I can't tell much yet how it works on Linux, but so far so cool.
Groovy is next-generation language running on JRE. With Grails you can create powerful enterprise applications with little code and you can use any Java library. It is usable and enterprise ready.
Scala is Java alternative, can use Java libraries, you can also create enterprise applications (Play framework), however with being enterprise ready there are few glitches you might not encounter if you are not in enterprise environment, in particular, they do not support HTTPS for their downloads which basically is big pain if you have to use it, and it's problem for many.

And finally:

Java, Scala, Static Groovy, C# are for high performance, multi-threaded application servers which can do more than serving web pages - like listening on sockets, schedule jobs, process data and so on with high performance and safety. Todays Java is really nice. Static typing is important if you want performance and safety, so anything where multiple clients are connecting or you process a lot of data like real-time systems. Java can handle it well today.
Use C, C++ only when you have to, including real-time systems which is must-have in networking.
Use HDLs for Hardware Development
Use dynamic languages for scripting, web pages for managed hosting. You can use Python for almost everything, but look at Java as well.

ps. I don't mention any GUIs - in fact, it's real hell. I do myself HTML5. Sometimes I build it with embedded browser engine. Sometimes C++ / QT, WinRT etc. Look out for the various widget libraries etc.

You will need also to seriously consider database engines. Historically, all database engines were SQLs - MariaDB, Oracle, PostgreSQL, DB2, SQL Server. These are good for generic engines like CRUD, for security you can look at MongoDB, Cassandra, Neo4j, Redis, and also Hadoop and things like Sping Framework, Apache Spark and so on. For embedded devices it's SQL Lite, but many newer embedded devices mainly rely on the real-time, super highly available databases, which are usually specialized for the job any sometimes not free.


How can I set up a secure virus laboratory?

The virtualization software and even the hardware can contain all kinds of bugs that would allow a guest program to access the host. There are already known malware that detects VMs and some may be able to use these vulnerabilities.

Also don't bother about dual-booting or changing disks as virus/rootkits that attack BIOS are not even new.

The only secure solution is to use a physically separated computer with an air gap.


PCI Compliance for developers accessing a production database for support

DSS 6.4.2 Separation of duties between development/test and production environments is careful to note that it is not prohibiting developers from Production, just controlling them:

The intent of this requirement is to separate development and test
functions from production functions. For example, a developer may use
an administrator-level account with elevated privileges in the
development environment, and have a separate account with user-level
access to the production environment.

So restricting privileges is a good start - read only access where possible, limited administrative rights enforced with something like sudo or PowerBroker as necessary.
Aside from restricting privileges, a standard way of dealing with this would be to use Incident and Change Control processes to document why any given developer was acting in Production at a given point of time, and to generate an audit log that can be used to evaluate what actions were taken in the time/place covered by a ticket.  Remember, at some level, you want to be able to walk the auditor through your controls.
If your workflow permits it, dual control can be a useful restraint upon developers, ensuring that a second pair of eyes is monitoring the activity.  That can be difficult to arrange; developers get called into Production emergencies because they're, well, emergencies, and not neatly scheduled.


A service that claims beyond army level encryption

In general there is no such thing as out-the-box security, so no, your privacy is not unbreakable if you use any service. I can still come sit outside your house with a microphone.

With respect to this service I doubt they are as secure as they claim. They don't use AES, but don't say what they do use. That's called security through obscurity and is basically bad practice. Furthermore they use NTRU, which despite their description is not 'super-strong'. Invented in '96 it's been broken and revised several times as the maths is not well understood. Basically I'd avoid these mavericks. They may be completely correct, but given that the stuff they do use is not well understood, and they don't give details of the symmetric key they use which makes me suspicious.


How does a browser choose which certificate to use if my web server has multiple certificates?

Guess
My educated guess from reading the spec: The browser will never see more than one server-certificate. Rather the cipher spec is negotiated in advance. And ONLY THEN does the server send the certificates.

So if negotiation winds up with an an RSA-cert authenticated cipher suite, then the RSA cert chain will be sent. And if the negotiation winds up with an ECDSA-cert authenticated cipher suite, then the ECDSA cert chain will be sent.

Standards document: http://tools.ietf.org/html/rfc5246#section-7.4.2

  7.4.2.  Server Certificate [...]
  The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm and any negotiated extensions.

Testing
I can't test for this right now.
And: last I heard (2013) SSL-Labs couldn't either: Qualys Forums: Dual certificates and key exchange scores


Building a web app with encrypted MySQL database entries?

What you are talking about is a derived key.  The technique you describe is frequently used for high security systems, though I would further recommend that you use the derived encrypt a data key.  This allows the data key to be stored with more than one derived key and limits the use of the derived key.  This allows for data sharing, keyrings and account recovery.  Also, keep in mind that the derived key itself is only as strong as the password, so salting and slow key derivation functions should still be used to ensure that password derived keys can't be formed for all the users passwords at once.

Derived keys tend to be weaker than truly random keys, so you want to encrypt the minimum amount possible with them.  If you encrypt only the user's data key with it, you can decrypt the user's data key and then store it in the session.  That truly random key can then be used for encrypting and decrypting the user's data.

A further enhancement is to associated keys with records and then encrypt that record key with the user key in order to give the user access.  If you use asymmetric cryptography here, it would be possible for a user to grant record level access to another user by encrypting the record key with the public key of the user they wish to share with and adding it to the other user's keyring.

Similarly, for account recovery, the user keys could be encrypted with a public recovery key.  The private key could be held offline or associated to an admin user (with similar derived key protection) and only used by customer service when necessary to restore an account.


IntelliJ PyCharm promiscuously installing packages

PyCharm does not automatically install packages. What very likely happened is that you added import sklearn to the top of your file, and then used the install package quickfix. After you add an unresolved import, a red light bulb will appear, and you can choose to install the package with the name of your import, in this case sklearn.

The other ways to install packages from PyCharm are: installing them based on a project's requirements.txt file (a yellow bar will appear at the top of the editor, and you need to click 'Install' on it), manually using the package editor in the settings screen, or if you type the commands in the Terminal window.

Furthermore, the package you're worrying about is empty: https://pypi.python.org/pypi/sklearn/0.0. All it says is that you should download scikit-learn instead.


How can I generate a binary from an payload without any other addons?

It's as simple as:
msfvenom -a x86 --platform windows -p windows/format_all_drives -e x86/shikata_ga_nai -f exe -o /tmp/1.exe

where the -a option is used to specify the architecture, the -p option is used to specify the payload, the -e option is used to specify the encoder, the -f option is used to specify the output format (exein this case) and the -o option is used to specify the file to write the binary to.

Note: I have never used metasploit in my life and wrote this answer purely from this and this (found by a simple google search).


Need a software that can monitor and log network traffic of installed applications

Microsoft Network Mintor or NetMon for short allows you to monitor/log/analyze network traffic.

After you start capturing, you can specify a process and monitor the network activity of that process.

If you just want to know the IP addresses, ports, and protocols used by the process, you can try something like this in the command prompt

netstat -ano | findstr PID

You can get the PID either from your Windows Task Manager, or with the following command

tasklist | findstr /i PROCESS_NAME


How many characters should a session key be?

As Peter Harmann says, you really mean log2(x) rather than pow(2, x), besides that your formula is correct. The real error however is that you misinterpret your citation:

  Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.

You misinterpreted that as 128 bits of entropy, but it's only 64 bits (i.e. it's 64 bits in hexadecimal).


Insecure to keystroke password via script (when paste doesn't work)?

Having your password in the clipboard is not safe at all. An attacker would just have to read the contents of your clipboard to elevate his privileges on your system.

Many of the usb 2 factor authentication devices has a button that can type your password when you press it. It sounds similar to using the clipboard but the idea is that you keep the usb key with you when you step away from the computer. I believe yubikey has a smart card version that works with Mac.


Preventing unvalidated redirects and forwards

Don't provide the actual URL as an argument to the script. Instead, provide some ID which you can translate into a URL in the redirector script.

For example use redirect.aspx?url=1 instead, and in the script, translate ID 1 to some URL using a map, database lookup, or whatever you find useful.

This way, only a fixed set of trusted URLs can be redirected to.


Reverse-engineering one-time passwords for two-factor authentication systems

If the OTP generation algorithm is any good (and HOTP is good):

the best attack when knowing one generated password, and trying to guess the next one, should be exhaustive search on the key (and exhaustive search is not doable if the key is large enough, e.g. a 128-bit key);
knowing many previous passwords should not give any additional advantage to the attacker.

Appendix A of RFC 4226 details the security analysis of HOTP; at its core lies the hypothesis that HMAC/SHA-1 is a key-selected random function:

  To be more precise, let Maps(c,n) denote the set of all functions
     mapping from {0,1}^c to {0,1}^n.  The idealized algorithm has key
     space Maps(c,n), so that a "key" for such an algorithm is a function
     h from {0,1}^c to {0,1}^n.  We imagine this key (function) to be
     drawn at random.

This is the random oracle model. HMAC with a secure hash function, or even HMAC with a slightly weak hash function like SHA-1, is about the best practical approximation of a random oracle that cryptographers have in store.

To sum up the security proof of HOTP:

with a random oracle, you know nothing of the output for a given input until you try it on that exact input;
the generated passwords are (derived from) the output of HMAC/SHA-1, believed to be indistinguishable from a random oracle, over a counter value;
thus, nobody knows anything of a password which will be generated until the corresponding counter value is actually entered as input of HMAC/SHA-1, something which did not occur previously (for the older generated passwords) because that's a counter and it does not "wrap around".

There are details to take care of, of course, but the RFC writers are known cryptographers and the proof detailed in appendix A is sound and clear (and has been reviewed by many other cryptographers, which is the real test of security).


End to end security for REST services, any emerging standards?

I believe you are asking about identity propagation through a RESTful stack.  In other words, you want to tie the request back to the original user so downstream systems can validate authorization on a per-user basis.  I have also been researching this problem recently.

At heart, no, there is no standard defined for identity propagation for REST services.  REST itself is not a standard, but rather an architectural pattern.

There are some libraries that provide integration with existing standards such as Kerberos (such as JAX-RS) or SAML via HTTP bindings.

Various approaches using JSON Web Tokens (JWT) are becoming popular, but this is more of a "roll-your-own" approach, which offers flexibility but at the cost of implementation risks.  This is somewhat bleeding edge.  The RFC for JWT was only approved in April, 2015.


Tl;dr: both using Tor via Whonix, share a single webmail account hosted by a Tor-facing .onion email provider, in which you communicate by putting pre-browser encrypted PGP messages in the body of unsent items in the Drafts folder (without ever sending it as an actual email), before quickly deleting each PGP message from the other party as you receive it.

Initial considerations...

A lot depends on your threat model - are you wanting to hide the communications (and knowledge of them), from the NSA, or from adversaries with less network surveillance and anti-encryption resources than that?

Let's assume it is a powerful NSA-level adversary, where you truly do want your lawyer-client communication to be both secure, AND secret.

For Internet communication, where it is between only two parties (and I assume it needs to be 'asynchronous', i.e. both parties are not connected to each other in real time online, i.e. usually email or other server-stored communication instead of instant messaging / P2P communication typically secured by OTR) and where, luckily, you don't need to share a publicly discoverable or broadcastable 'username', IM alias, or email address given there's only two parties that need to even know how to do this communication, then I would advise the following extremely anonymous, very secret, and highly secure setup for covert two-way communication:

Instructions

All parties use Tor. This is only one small part of the protection, specifically to very securely hide the IP addresses of you and your lawyers, but also, to use a Tor hidden service which will side-step the entire infrastructure of DNS itself and thus not leak what website you are using to communicate, to the NSA. (as end-to-end HTTPS server-client encryption does not hide the fact of you doing this, from the NSA.)
As for how to use Tor, rather than the simple Tor Browser on your (most likely) insecure Windows, OS X, or even default Linux system, I suggest doing this communication either using the Tails live boot OS, or, with longer setup but arguably better suitability for the way in which you will be securely communicating in this guide, Whonix. Graphical Linux is actually not that difficult to use, Whonix's particular chosen desktop (KDE) actually is quite similar to Windows in its interface. Whonix is a marvellous equivalent to Tails where it's not 'amnesic' like Tails but it is in the form of a Virtualbox-hosted VM, so you can securely store messages you receive from your lawyers OFFLINE on your computer and not leave them on the webmail server that you'll be using, and that will be crucal to this guide.
So, install Virtualbox, and download and install Whonix. This Tor OS works by having two VMs, the 'Gateway' VM to be the 'Torifier', then the 'Workstation' where you do the Tor browsing and communication in. It has the effect of NO IP address leak even being possible inside Whonix-Workstation due to its network interface being routed through the Whonix-Gateway VM, so even JavaScript or Flash could leak your real IP in Whonix - and yet, the VM is also instantly deletable when you need to as well. But still, please, disable JavaScript in Tor Browser once you are up to it.
So once Whonix is installed in Virtualbox (follow Whonix.org's excellent guides if need be, but it's all remarkably self-explanatory, make sure LUKS encryption is set up during the VM installation wizards) - and you get used to how it runs (you just thenm on at the same time (or better, in order), first wait for Gateway to set up its Tor connection, do its checks, do sudo apt-get update and sudo apt-get dist upgrade in Terminal if you need to, then once workstation is on and connected, same in there too), you are ready to move on to your super secret, lawyer-client communication.
Firstly, do NOT use the Tor browser for ANYTHING other than this exclusive lawyer communication on Tor (this applies to the lawyers too, obviously). Do not go to a SINGLE other website in Tor on Whonix. Even if your IP is hidden, that IP will still be correlated to ANYTHING else done in that same Tor session (and by that browser's unique or fairly linkable fingerprint), in the eyes of those running the Tor exit node, the NSA who's most likely listening somewhere along the path between your Tor exit node and the websites you'd connect to, or other malicious parties who have the ability to monitor or sniff.
The service we will be using for communication is a SINGLE webmail inbox (hosted on a Tor hidden service), that you SHARE with the lawyers and both log into with the same credentials (shared in person), and write PGP-encrypted messages in the DRAFTS folder - this will keep it ultra-private by never even having the communications leave the single webserver of the email host due to not actually sending emails (and involving other email servers and parties), at all.
It is crucial you pick a Tor webmail provider that you can log into the inbox only on a Tor .onion address. Consult this page to select and choose what looks good to you. Use one that can offer SquirrelMail login and not just Roundcube, as that way you won't need to turn on JavaScript in Tor Browser to do this. The reason to login exclusively on an .onion address, is for several anonymity and security reasons: again, you avoid DNS lookups taking place out there on the Internet and instead use Tor's highly encrypted/obfuscated hidden service protocol method of lookup instead, and you also avoid HTTPS MITM attacks by the Tor exit node, or anyone else between you and a DNS-hosted webmail address, who can, EVEN with HTTPS, potentially hijack the session (and easily systematically, not just as a targeted attack), to gain your login credentials, read the traffic and collect your PGP messages you'll be sending to each other, or even modify the pages and messages to absolutely anything they see fit.
To communicate your PGP messages in the least risky way possible, do the following: SHARE the same PGP key (ed.: unless it is better to have separate PGP keys? comments welcome), do NOT write your draft messages that you'll leave for each other INSIDE the browser, and encrypt your message content with the PGP client in in Whonix BEFORE pasting the encrypted blob into the webmail compose box each time you do it.
How to encrypt and decrypt the messages in Whonix: the easiest way is to use Whonix's pre-installed PGP client, KGpg, with its on the Desktop. If you use KGpg, first delete all Key Servers in Settings > Configure KGpg, so that no uploading of your key accidentally occurs at any time of your use of the program. To use, first setup up your key (Key > Generate Key Pair or Ctrl+N), securely share it and the passphrase with your lawyers (right click on the key in main window > Export Secret Key...), either in person or by some other non-Internet or -telephony means - UNLESS again it is better to have separate keys to each other, I am not sure - and then to encrypt for composing, or decrypt when reading, simply go to File > Open Editor and it is all easily done in there for either party once you have the key stored in KGpg.
To make the communication to each other practical in the drafts folder: good practice is to firstly, NOT leave ANY telling information outside the PGP blobs in the message body, and if you must differentiate between each other give the subjects or via a little text above each (new) blob, some random letter or number to indicate whether the blob was from you, or from your lawyers. Better than starting a new draft per new message, is just leaving a new PGP blob in one single draft, which is merely updated continually.
This is crucial: DELETE each PGP message from the other party in the webmail as soon as you receive and decrypt it in your PGP client. This means the communication is not stored on the webmail's servers to get leaked, hacked, modified, or otherwise breached for any longer than it needs to. Save any correspondance that needd to be kept for longer, locally in your (encrypted and secured) computer - (preferably within the Whonix installation with LUKS wholly inside the VM container file) - or even archived on an air-gapped, encrypted computer if need be.

Caveats

With this setup you have to trust the .onion-hosted email provider not to modify, make up, or erase any of the draft messages you leave for each other in your inbox on the server, and also not to leak any of it. Even with PGP, it is still data that could be decrypted later all the same.
If the NSA or another high-powered, global adversary were lucky, they be able to may de-anonymize your (or the lawyers') IP address via timing/traffic correlation attacks where they compare size of the packets being requested and sent between you and the webmail's server, IF they own (or have capability to directly sniff the traffic at) enough locations/nodes on the Tor network. However this particular form of de-anonymization (and especially if you are connecting to an .onion hidden service where, you actually avoid the need for a Tor exit node entirely), is extremely unlikely and requires enormous resources which appear only viable for them when trying to surveil someone they already know is a target, and not random Tor users, per se. But the random possibility, always exists.

However, I would advise a pre-Tor VPN connection to hide your 'real' IP as an extra precaution, even so. There are plenty of free VPNs around and I would advise no money to be involved so as to not involve financial trails to this communication in any way possible. Make sure you use a different free VPN to what the lawyers use at their pre-Tor end, as a correlation could be made otherwise. This also would be good for de-correlating the fact that both you and your particular lawyers (i.e. your real IP address and their real IP addresses), from the point of view of the NSA, even use Tor. VPNs are much more common than Tor, at this point in time anyway, and would distance suspicion between your real IPs and Tor even more. Obfs3 when connecting to Tor and also VPN obfuscation (especially with LEAP VPN technology) also can be put into use.

PGP, ordinarily, does not have perfect forward secrecy (like OTR, and TextSecure, do). This means if the encrypted blobs SOMEHOW leak at a later time, whether by a malicious webmail admin, via an unencrypted routine server backup, or if webmail provider turns out not to have the best opsec/server security and is hacked in general, is specifically targeted by NSA due to other high target communications taking place on the same server and then any messages you have still stored in your drafts folder are seized (which is why I urge you to delete them as soon as they are received), or you / your lawyers storing any messages are raided / equipment is stolen and things progress all the way to someone actually accessing your 'blobs', AND then you or your lawyers are forced to give up the (single) PGP password for your commuication (or additionally your opsec isn't as vigilant as it should be), then standard PGP will not save you from such a leak, and ALL your messages under the one key will be decrypted in one foul swoop.

I read somewhere that the PGP spec CAN include PFS key exchange, though do not know what client could be configured to do this. Someone feel free to edit this and give instructions (even in my main bullet-point guide, and then edit out this caveat), you'd be welcome.

Additionally, if someone knows of a simple, offline, portable, serverless, PFS-providing robust crypto implementation with a GUI that could replace a PGP client for communicating covert blobs in a scenario like this, that would be even better.


Why is the same origin policy sensible - for requests?

I think the issue is that you might have a bit of misunderstanding about the purpose of SOP/CORS in the first place.  An important point that often gets missed is that the SOP doesn't forbid you from sending data to a different origin - it only prevents you from reading the response from the separate origin.  You say this:

  First I thought it may be so that an XSS breach into a web app doesn't
  allow the attacker to send critical data to himself

And then clarify that the attacker would still be able to send data to himself by enabling some CORS headers on the receiving server.  However, even that is not necessary.  For simple GET and POST requests the browser will still send the request to the destination server, and that server will be able to receive and act on it normally without any issue what-so-ever.  The only thing that will change as a result of the SOP is that the browser will refuse to allow the calling script to receive the response from the server [**exeception at bottom].

That's really the key.  The same-origin-policy is all about refusing to let origin A read anything from origin B unless explicitly allowed by origin B.  That is why CORS headers are set on the receiving server, not the origin server.  If someone accidentally visits evil.com we don't want javascript on that page to be able to read data from facebook.com unless facebook.com has explicitly said otherwise.

Of course the primary use-case for this is with access credentials.  The browser will automatically attach cookies from facebook.com to every single request that goes out to facebook.com, even if the javascript making the request runs on evil.com.  As a result if the SOP did not prevent cross-domain reads, anyone would be able to read your facebook profile anytime you visited any page anywhere that had javascript they control.  The browser's insistence on sending cookies with every request to a given domain (which is pretty much a requirement for many web applications to work properly) is the main impetus behind the SOP and CORS restrictions.

For a website that doesn't use authentication CORS is generally going to be a lot less important.  After all (as you say) the request could simply be made by a server and the response relayed to whatever javascript is running in the browser.  In such a case a site can even disable CORS by sending the Access-Control-Allow-Origin: * back on all requests.  Note that if a server does that it cannot also set the Access-Control-Allow-Credentials: true flag on.  Browsers do not allow you to let everyone read your stuff and also send cookies along to all requests.

All that to reiterate: SOP is all about forbidding javascript running on origin A from reading anything from origin B.  It separates out domains/protocol/port so that people are only allowed to read their own things, and is one of the most basic protections baked into web browsers.

** I said that SOP/CORS does not stop the browser from sending your request.  There is an exception to this rule.  In the event of a "non-standard" request the browser will send a "pre-flight" verification request.  Specifically, it will send a request to the endpoint with a request method of "OPTIONS", asking the server what kind of requests it will accept.  If the request being sent doesn't match then the browser will not send the request in the first place.

Edit to add

Obviously your main question is "But if no cookies are involved then why even block reads in the first place?".  I aimed to get that with my original answer, but let me try to address that more directly:

You're looking at security from the wrong perspective (in this particular case).  You're effectively looking for a reason to deny access to a particular privilege (i.e. "why can't I do that?").  A much more robust way of approaching security problems is from the opposite direction: everyone should have the minimum privileges they need and they should only be given additional access if there is a reason.  Instead of asking "Why can't I do this?" the better question is "Why should I let you do this?".

When you look at it from that perspective the default policy of the SOP to block all read requests unless explicitly authorized makes much more sense and is basically just standard security.  Yes, people can circumvent this security step by doing things like making the request via a server.  However, the fact that a security step can be circumvented doesn't mean it is a bad idea.  There are lots of ways to circumvent the lock on your car door, but that doesn't mean you should just stop locking your car.  Good web security is about defense-in-depth: layered security so that if a weakness is found in one area your system can still be secure.  The SOP and read restrictions is basically just the very first layer of security for web applications.


Active Directory: Should Workstations be separated from servers to protect from related domain hacks?

I don't think this has anything to do with Active Directory.  It is a question about internal web applications.

Yes, I imagine there is some security benefit to placing the internal apps on totally separate domains.  However, this may be annoying from a usability perspective (it may be more convenient for your users to have all the services under a single easy-to-remember domain name), and I'm not convinced that the usability hit is worth it, given that the security risks are probably modest.  In terms of resistance to internal attacks, I suspect at most sites there will be other more effective ways to harden yourself against internal/insider attacks.  But that's something you'll have to evaluate for yourself; it is a risk management exercise.

I don't know if there are better ways to mitigate the risk while maintaining the same domain name structure.  There may be ways to implement the critical webapps (e.g., payroll.example.com) in a way that limits the impact of those kind of attacks, but I just don't know what ways those might be, alas.  Sorry about that.


Without deciphering your regular expressions I tell you that you are doing this wrong, here are some examples why:

HTML entities and attributes are changing all the time, you can't really blacklist things.
You can filter the input to avoid HTML tags altogether. This way you will still be vulnerable if you put the filtered data inside script or style tags for example.
You may need to accept formated user-supplied data (think FCKEditor), and you would kill the formatting with your filters. At this point you would basically have to deal with XML that you can't possibly parse with regular expressions.
The backend database or other system components can format the already filtered input in a way that it is becoming harmful on output (see the ValidateRequest filter bypass).
Also, good luck with debugging your code!

I would recommend not reinventing the wheel and separating your views from your controllers. Using some template engine/framework that HTML-encodes all template parameters before output will help a lot. If you need to display formatted content you can use HTMLPurifier.


How can I validate that a PRNG's output is insecure and predictable?

A problem you're having here is you're thinking about it in a much too black-box fashion (e.g., collecting a large collection of outputs), which is not what an actual attacker will do. An actual attacker will get as much concrete information about internals as they can, including the PRNG algorithm and the code for the applications that you use it in, and exploit specific details to break it.

So apart from pointing you at programs that demonstrate how trivial it really is to break a bunch of very popular standard library PRNGs, there aren't obvious generalizations to be made here, apart from maybe a bit of cryptanalysis (which is a black art not explainable in a Stack Exchange answer) they're just looking at PRNG code and figuring out what attacks that specific code:

https://littlemaninmyhead.wordpress.com/2015/11/22/cautionary-note-uuids-should-generally-not-be-used-for-authentication-tokens/
https://crypto.stackexchange.com/questions/51686/how-to-determine-the-next-number-from-javas-random-method
https://crypto.stackexchange.com/questions/52000/how-can-c-rand-be-exploited-if-a-secure-seed-is-used


How feasible is it for a CA to be hacked? Which default trusted root certificates should I remove?

Update 5 The root problem (heh) with the CA model is that in general practice, any CA can issue certs for any domain, so you're vulnerable to the weakest link.  As to who you can trust, I doubt that the list is very long at all, since the stakes are high and security is hard.  I recommend Christopher Soghoian's post on the subject, which clarifies the various approaches that governments around the world have used to get access to private user data - whether by directly demanding it from companies that operate cloud services, via wiretap, or increasingly now via CA coercion or hacks: slight paranoia: The forces that led to the DigiNotar hack.

Here I provide some specifics, and end with links to some potential fixes.

In 2009, Etisalat (60% owned by the United Arab Emirates government), rolled out an innocuous looking BlackBerry patch that inserted spyware into RIM devices, enabling monitoring of e-mail, so it can hardly be considered trustworthy.  But it is in a lot of trusted CA lists:
 http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

Update 1 See also an example of a successful attack, allegedly by an Iranian named ComodoHacker, against Comodo: Rogue SSL certificates ("case comodogate") - F-Secure Weblog.  F-Secure notes that Mozilla includes certificates issued by CAs in China, Israel, Bermuda, South Africa, Estonia, Romania, Slovakia, Spain, Norway, Colombia, France, Taiwan, UK, The Netherlands, Turkey, USA, Hong Kong, Japan, Hungary, Germany and Switzerland.

Tunisia is another country that runs a widely-trusted CA, and there is also good documentation of the actions of their government to invade privacy: The Inside Story of How Facebook Responded to Tunisian Hacks - Alexis Madrigal - Technology - The Atlantic

Mozilla notes another questionable practice to watch out for: CAs that allow an RA partner to issue certs directly off the root, rather than via an intermediary: Comodo Certificate Issue – Follow Up at Mozilla Security Blog.
See also more detail, including speculation about the claim of responsibility by a lone Iranian hacker Web Browsers and Comodo Disclose A Successful Certificate Authority Attack, Perhaps From Iran | Freedom to Tinker

Update 3: Another successful attack seemingly also by ComodoHacker was against the DigiNotar CA.  Their website was compromised starting in 2009, but this was not noticed until after DigiNotar had also been used in 2011 by Iranians to sign false certificates for the websites of Google, Yahoo!, Mozilla, WordPress and The Tor Project.  DigiNotar did not reveal its knowledge of the intrusion into its site for over a month.  See more at DigiNotar Hack Highlights the Critical Failures of our SSL Web Security Model | Freedom to Tinker.

I'd guess that the range of vulnerability of various CAs varies pretty widely, as does their utility.  So I'd suggest refocusing your strategy.  When you can narrow it to specific assets you're trying to protect, just delete all CAs except those necessary for using those assets.  Otherwise, consider eliminating the CAs you judge to be most vulnerable to those who care about your assets, or least popular, just to reduce the attack surface.  But accept the fact that you'll remain vulnerable to sophisticated attacks even against the most popular and careful CAs.

Update 2: There is a great post on fixing our dangerous CA infrastructure at Freedom to Tinker: Building a better CA infrastructure

It talks about these innovations:

ImperialViolet - DNSSEC and TLS
Network Notary - Perspectives : Improving SSH-style Host Authentication with Multi-path Network Probing
Google Online Security Blog: Improving SSL certificate security

Update 4 One of our IT Security blog posts in August 2011 also covers the case for moving to DNSSEC:
A Risk-Based Look at Fixing the Certificate Authority Problem « Stack Exchange Security Blog

Update 6 Several Certificate Authorities have been caught violating the rules.  That includes the French cyberdefense agency (ANSSI), and Trustwave, each of which was linked to spoofing of digital certificates.

Update 7 Yet another set of "misissued certificates", via the  Indian Controller of Certifying Authorities (India CCA) in 2014: Google Online Security Blog: Maintaining digital certificate security

See also the question on Certificate Transparency which looks like a helpful approach to discovering bad certificates and policy violations earlier.


How do I calculate md2 hash with OpenSSL?

By default, OpenSSL is built without MD2 support. People have been complaining since 2010 that the option is still listed in the docs.

What you can do is build OpenSSL yourself with enable-md2. However, this doesn't bring back the openssl dgst -md2 option just yet.

For that you also need to add the following line in crypto/evp/c_alld.c:

void OpenSSL_add_all_digests(void)
{
    ...
    EVP_add_digest(EVP_md2());
    ...
}

(If you want it as a first-level option, you should also add the same line in ssl/ssl_algs.c.)

Then just build it.
 What I did:

$ ./Configure linux-x86_64 enable-md2
...
$ make depend
...
$ make
...
$ echo -n foo | apps/openssl md2
(stdin)= d11f8ce29210b4b50c5e67533b699d02
$ echo -n foo | apps/openssl dgst -md2
(stdin)= d11f8ce29210b4b50c5e67533b699d02

(You can download the tarball from here.)


How could I totally secure a connection between two nodes?

Basically, the solution you're looking for is going to involve some sort of offline transfer. The two computers that are the endpoint nodes of your secure tunnel must be "introduced" to each other, exchanging some secret that will allow one side to initiate a connection in such a way that only the other node could understand it.

While this shared secret could be the symmetric key in itself, this can be problematic; symmetric algorithms are most secure when nothing about the key is known, even the fact that it's the same key as was used for another communication. An attacker could watch multiple "conversations" between the nodes, and if he knows the conversations use the same key and IV, and if he can guess the plain text (which he is likely to do as the information sent in the initial stages of communication is fairly boilerplate), he can use the ciphertext to reverse-engineer the key. For this reason, the symmetric key must be renegotiated often, even on the same secure channel, depending on how much data is sent across.

The go-to solution is asymmetric or public-key cryptography. Understand one thing; public keys are meant to be public. You could spray-paint your public key on the side of your car and drive it through Black Hat or DEF CON, and all anyone could do is attempt to connect to your endpoint securely (which is no more than they could do to any other TLS-secured endpoint, and they wouldn't get far here; keep reading). The private key is needed in any public-key scheme in order for data to be decrypted efficiently (and thus for information to be at risk).

Now, you may not publicly distribute this certificate; you could, quite plausibly, implement a simple variant of the basic TLS scheme where the normal first step, the client's request for the server's certificate, would be ignored by the server. Instead, the client must already have a certificate for the server "pinned" in the OS certificate store, and would not (could not) verify it had the latest version. It would then be able to negotiate a secure connection without a single bit of actual data being sent plainly (the packet data would still be in a well-formed IP packet).

Conceptually, it would work as follows; the client would have the public key of the server, which it was given offline (here, the only difference between "client" and "server" that we care about is that the client is the one initiating communication; both computers can be "servers" in other senses of the word, such as file servers in the cloud). The server would have the public key of the client, which it received offline. The client encrypts a request using the server's public key, which will contain the client's certificate. That request goes to the server IP, and only the server can decrypt it, even if someone else were sniffing or spoofing traffic on that same IP address. The request can contain a nonce, such as a simple counter value, preventing replay attacks (the server can ignore multiple requests from the same client with the same nonce, though it must decrypt each request it receives to determine this, which could make it vulnerable to DDoS).

The server would then use the client certificate, which it can independently verify as an authorized client because an exact copy of the client cert lives in the server's OS store, to send a symmetric key negotiation. From this point the scheme is virtually identical to two-certificate TLS negotiation; the server sends the client the key negotiation request, the client receives, sets up its cipher, and returns either a symmetrically-encrypted acknowledgement or the other half of the key-exchange protocol so the server now knows they're talking the same language. From then on, client and server can communicate using the symmetric channel. All this, without a third-party observer seeing any packet data in plain text.

Now, this is just to create a secure channel. Even if the client node has a static IP, it's always good to subsequently verify, after negotiating the secure tunnel, that the human controlling the computer on the other end is someone authorized to use the system. Credential exchange like username/password, or the entry of a time-limited key value generated by a fob, are common and perfectly feasible means to authenticate the user of the authenticated computer(s).


How secure is data at rest on Android/iOS mobile devices

The app uses those keys in an offline scenario to 'self validate' the signatures of its data

I'm not sure about the exact circumstances you have in mind, but if your application needs to validate externally provided data, as opposed to data it produced itself, the simplest approach would be to use public key cryptography to sign the data. This way, you'd only need to store the public key on the device, which isn't security critical and doesn't have to be protected (edit: see nolanda's comment for an explanation why this is completely wrong! you do need to protect the public key!)

  But how secure is this approach from attack?

What kind of attack? Are you up against the resources of a nation state, or a lone hacker? What do you know about the underlying devices? Are you trying to protect missile launch codes, or client phone numbers?

Key extraction difficulty from Android Keystore varies; for example, if the underlying device has a hardware security module, it's more difficult to extract the key material from the device than if it's just software-protected.

If your Android device or Apple device has telco capability (e.g. it is a phone), you might be open to attacks from the baseband processor, depending on how well your phone isolates the baseband from the application platform and who your attacker is. So that matters, too.

Without knowing what exactly you're dealing with, it's impossible to give a meaningful answer.

You should also consider that attacking the keystore might not be the easiest attack. The keystore is probably well-secured and flaws in it's security are taken seriously and fixed by the smart guys at Google and Apple. IMO it's more likely that your app has security flaws, and if an attacker gains access to your app, e.g. manages to execute his own code in your app process, he will also be able to use the cryptographic keys to encrypt / decrypt or whathever else you use them for, and it probably won't matter if he can access the key material itself or not, because he can make use of the keys just like your app can.

Another attack might center on the process/app isolation of the Android OS/iOS. Once an attacker manages to breach this isolation, or gains root privileges on your phone, again, he'll very likely be able to make use of the keys wherever they are stored, even if he can't get at the keys themselves.

All that said, I'd add that IMO it's very hard to secure a consumer mobile phone platform and if you're dealing with any kind of really important data (think e-voting systems or systems where human life is at stake), I'd be uncomfortable in trusting such a platform to keep my data safe.


How to turn off need for bitlocker to go on Windows 7

Not sure if this is still an open issue, but there are some registry settings that you can set to zero to turn off the read only access to external drives as enforced by BitLocker to go.

The settings can be found in the registry as follows.

HKLM\System\CurrentControlSet\Policies\Microsoft\FVE\RDVDenyWriteAccess
HKLM\Software\Policies\Microsoft\FVE\RDVDenyCrossOrg

I validated that modifying this setting works in the latest release of Windows 10.


Alternative to security questions for account recovery when email isn't an option

You could encourage your users to put their passwords in a secure password storage system such as KeePass. The system requires that the hold on to something anyway, better just have them hold onto the password and not add another piece (they would have to somehow secure the token file you give them to prevent it from being stolen/intercepted). You may also run into issues with the way your random tokens are created if the algorithm was not implemented correctly and some correlation or predication became possible.

There may be some potential to use a certificate based system for authentication, then they just hold onto their key, which is more likely to be held onto then a reset token (I can't even remember where my TrueCrypt recovery CD went). Maybe you tell them to put it in KeePass or jsut a encrypted file and then put it in their dropbox - it will be in multiple places, but accessible only in an encrypted/protected format.

I think your users need to make the tradeoff between convenience and security. (a) If the data on the site is so important, than you must be responsible enough to hold onto your password (b) If its not that important, you give up the convenience of a reset for the safety of knowing no one else will likely be able to get into your account.


Is it possible to attack the main server through a reverse proxy server that only serves as a url rewrite?

A reverse proxy is just an efficient tool, but not a magic bullet. When it is properly configured, it can ensure that only legal urls can be reached. But if you let anything pass through it will not protect much.

Security is hard because it is not only a matter of tools: any defect in the configuration of the security tools will open a breach. So the actual security of the solution will depend on the used tool but also on the proficiency of the administrator. Things are like that ...


snort rule to detect relay attempt not working

Changing the checksum_mode to none in the snort.conf file (config checksum_mode: none) solves the problem and I can now see alerts for the relay rule in my log file.


Reducing resolution of timers as mitigation against Meltdown and Spectre

The reason it is only applied to browsers is because there is no way to fully eliminate high-resolution timing information from code being natively executed. For example, the RDTSC instruction provides precise, sub-nanosecond resolution timing information to any process. While it is possible to disable this instruction by making it executable only by privileged code (by setting the CR4.TSD bit), much of userland relies on it. However even if you did successfully disable it without breakage, a timer of similar resolution could be jerry-rigged by incrementing a variable in a fast loop. Userspace code will always have nanosecond-precision timing information. Such a timer could be implemented easily:

register volatile unsigned long counter;

void counter_thread(void)
{
    while (1) counter++;
}

The counter_thread() function would be run in its own thread, and in another thread, the value of counter could be sampled at an arbitrary time. As the rate of the counter being incremented would be very high and fairly constant, it would provide a high-resolution timer similar to RDTSC.

As a result, there is no way to hide precise timing information from any process executing directly on the CPU. It is only possible in JavaScript because it is a managed, high-level language which does not have raw access to CPU instructions, and timing must go through dedicated APIs such as performance.now(), which can have its granularity adjusted by modifying the JavaScript engine.


The mistake isn't how you validate the file.  You should never execute any file that is uploaded.  Full stop.  If an uploaded file is supposed to be an image, then the only thing you should do with it is present it to an image processing program to be opened.

In a sense, the entire desktop paradigm of guessing the correct program to open a file by looking at its name and/or contents is a terrible idea, and absolutely must not be used by servers,
with untrusted data.


Can an error page (like 404) served without X-Frame-Options be exploited?

There is nothing inherent in a 404 response which protects against attacks like clickjacking (i.e. what X-Frame-Options tries to address). While most response bodies send with 404 are likely not vulnerable to clickjacking in the first place due to the shown content (i.e. just some more or less fancy error message), browsers do not add extra protection by themselves just because the response code was 404.


Should CSRF 'Double Submit Cookie' technique have a different seed value for the cookie versus the HTTP POST?

A few points of note:

Don't use double-submit cookies, as you said and as the article states, this not very secure, and opens you up to other attacks.
"a differently seeded value for the cookie and the HTTP POST embedded value" - Yes, this approach is much preferred, but this is not a double-submit cookie - you are referring to what is known as a Form Token.
Using form tokens used to be more problematic, since it was difficult to get it right and avoid the subtle errors which invalidate the solution. Nowadays, there are very good packages out there that do this for you, such as OWASP's CSRFGuard. Similar mechanisms are also built into many frameworks, including ASP.NET.
As I mentioned, ASP.NET's AntiForgeryToken (actually, that's ASP.NET MVC...) is based on form tokens, and not double-submit cookies. Which, as mentioned, is not secure.
ASP.NET itself also includes protection based on ViewState, when using UserKey attribute.
Many other modern frameworks also have some builtin protection, including Spring, RoR, etc.
Another alternative, which might or might not be relevant, is re-authentication of the user, for specific actions. E.g. before transferring a large some of money to a 3rd party from your bank account, or authorizing connections in LinkedIn.
Don't use double-submit cookies.


When paying by card on a website, will fake payment information make the order fail?

Verified by Visa (VBV)

  Verified by Visa helps prevent people using your details without your
  permission. And it’s good for retailers who want to make sure their
  customers are protected.

  When you complete your payment with Verified by Visa, your bank is
  able to make additional security checks to ensure your card details
  have not been compromised. Your bank wants to make sure that it’s
  really you making the purchase before they authorise the payment.
  After all, nobody would expect to take cash out of an ATM without
  using their PIN. Your bank wants to give you the same high standards
  of protection on the internet as well. VISA

As I understand the legacy payment system using CVV, exclusive, only requires three things: Card Number, Expiry Date and CVV. Anything else should not matter. However, this is why Verified by MasterCard and Verified by Visa came about, to mitigate this attack vector.

  What do they do with my personal information which are not my banking card information?

This can relate to the individual countries money laundering laws. Equally, this could be for their records, to detour fraudsters from committing fraud. As I understand, credit card (MagStripe and CVV) is not particularly difficult. Although, this is not a huge issue for the customers as authorisation hold is performed. Could the legacy system have been better, yes!

  Is it their own policy or an international banking policy?

If approached by the police, then they have records:

Card details
'Owner name'
Transaction time and date

  What happens if I just put James Bond born in 1980 living in 9000 South Pole Street, South Pole instead of my personal information (as long as my banking card information is correct)?

If a legacy payment system is used, then this should work. This is difficult to make a statement about because individual companies do not publish the source code for their antifraud systems. Hence, some conjecture with reverse engineering needs to be done here. But, this is why VBV and VBMC exist. To make this type of fraud more difficult.

So, the company's anti-fraud system should check:

Does our personal information match the card details?
Should additional verification be performed?
Is the email address domain from a 'blacklisted' domain?

In England, Anti Money Laundering Acts, require companies to validate each user with: government issue ID, utility bill, and sometimes a webcam chat. Before their account is marked as 'verified'. This is behaviour is seen with exchanges, LocalBitcoins encourages this model.


How does a new SMS message overwrite a previous one?

This is built in to SMS and is implemented in the Protocol Identifier (TP-PID):

  For MT short messages, on receipt of a short message from from the SC,
  the MS shall check to see if the associated Protocol Identifier
  contains a Replace Short Message Type code.

  If such a code is present, the the MS will check the originating
  address and replace any existing stored message having the same
  Protocol Identifier code and originating address with the new short
  message and other parameter values. If there is no message to be
  replaced, the MS shall store the message in the normal way. The MS may
  also check the SC address as well as the Originating Address. However,
  in a network which has multiple SCs, it is possible for a Replace
  Message type for a SM to be sent via different SCs and so it is
  recommended that the SC address should not be checked by the MS unless
  the application specifically requires such a check.

  If a Replace Short Message Type code is not present then the MS will
  will store the message in the normal way.

In the SMPP protocol specification this is REPLACE_SM:

  This command is issued by the ESME to replace a previously submitted
  short message that isstill pending delivery. The matching mechanism is
  based on the message_id  and source addressof the original
  message.Where the original  submit_sm ‘source address’ was defaulted
  to NULL, then the source addressin the  replace_sm command should also
  be NULL

And in EMI this is Type of Service 08, code 01:

  This Type of Service requests to replace a previously submitted
  message. It is only present when an update is requested. By default a
  message is assumed to be a new message.

The reason that this exists is so that services that send lots of SMS messages can avoid consuming the mobile phone's memory.  There is no security built in as far as I know; if you can spoof the source id, then you can tell the phone to overwrite previous messages from that same source.


SSL self-signed certificates in development vs acquired cert in production?

Is it ok to use self-signed certificates for development, and then use
  the acquired one for production only?

Yes, that is the way almost every one does. You don't have to pay a certification authority to certify that you are talking to your own server. Self sign it until production, buy a real certificate later.

  Does using self-signed certificates imply that in development, the
  clients need to add my CA to their list?

Yes, that's correct. Or that or the dreaded "The server you are connecting to can be trying to stab you" will display on their browsers.

  When we go live, using the actual acquired certificate, will there be
  any change in clients?

Nothing will change. Unless you have employed Key Pinning with a long max-age, you put a valid certificate on your server and forget about it until it's time to renew it. Your clients will never see any difference.

But if you are using Key Pinning, you must use at least two certificates. If you pin the wrong certificate, it expires, gets compromised or lost, your clients will not be able to connect until the pinning expires. Having a backup pin (the second, valid certificate) will ensure you can pin another certificate and fix any mess.


Difference between key generation and key agreement

Key agreement is a sub-case of key generation.

Key generation is about moving from a World where there is no key, to a World where there is a key. A "key", here, is some value with the correct structure for some cryptographic algorithm (e.g., an AES key is a sequence of 128, 192 or 256 bits; a RSA key is a set of a few big integers which fulfil some specific relations). Since keys have value by being unguessable by third parties, key generation necessarily involves using source data which is unknown to other people; in general, this "source data" will be random values obtained from a suitable source.

Key agreement is when the key generation must be such that, at the end of the process, two specific entities will know the key, and only them. A prime example is the Diffie-Hellman protocol where both parties use randomness to produce some data elements, exchange some of these elements with each other, and do some computations, which end up with both of them obtaining the same result at the end, while keeping external observers completely nonplussed.

A common method for key agreement is asymmetric encryption: Alice generates a key K for some algorithm (say, a sequence of 128 random bits), then encrypts it with Bob's public key, and sends the result to Bob. Bob decrypts it (with his private key), and thus obtains a copy of K. At the end of the day, Alice and Bob both know the same secret key K, so that's key agreement. If we look at the details, we see that the key agreement begins with a key generation, which is done entirely by Alice. That "local-generation-then-asymmetric-encryption" method is how most SSL connections are done on the Internet; note that Diffie-Hellman cannot be described that way, so one should not assume that all key agreement works that way.


Requesting CSRF token via AJAX for JavaScript webapp

You actually don't need token , you can make this using a custom header .

I know that CSRF-Token is important because I am a bug bounty hunter but you can depend on the browser security instead . I saw many cases when the CSRF-Token get leaked from the subdomain .

For example when you send data from a.mysite.com include this header :

Ok-Request: 1

Since you send data to cross domain you should configure your HTTP header
Just like this (for b.mysite.com):

Access-Control-Allow-Headers: x-requested-with, content-type, accept, origin, Ok-Request
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Origin: a.mysite.com
Access-Control-Allow-Credentials:true

When the browser will send custom header it will make An OPTION request first if everything is okay like (Origin , Method ,Headers) then the real request will be made . Otherwise the browser will throw a SOP error .


What level of compliance do I need as a software vendor?

Edit: This actually is unlikely to be correct.  See dave_thompson_085's answer about the PA-DSS instead.

Original answer:

Unfortunately, you do need to be PCI compliant, as a SAQ-D Service Provider.
Here is a link to the official PCI Quick Reference guide.  Some quotes:

  The standards apply to all entities that store, process or transmit cardholder data – with requirements for software developers and manufacturers of applications and devices used in those transactions.  [page 6]

  The PA-DSS is for software vendors and others who develop payment applications that store,
  process or transmit cardholder data and/or sensitive authentication data as part of authorization or settlement, when these applications are sold, distributed or licensed to third parties. Most card brands encourage merchants to use payment applications that are tested and approved by the PCI SSC. [page 7]

Think of it this way: If your network gets compromised, no one gets cardholder data.  But a vulnerability could be inserted into your application without you being aware, which would then be distributed to all your clients.  (This is known as a supply chain attack.)

This page even explicitly calls it out:

  However, not all organizations recognize their role as a service provider, and this lack of awareness puts their business—and their customers’ businesses—at risk.  The last part of the service provider definition (“also includes companies that provide services that control or could impact the security of cardholder data”) is what often causes confusion.  If a company offers, for example, a managed network firewall, and their customer uses that firewall to protect their point of sale systems and back office computer that make up their card data environment, then they absolutely can impact the security of card data.

  Examples of service providers that often don’t know they are service providers include hosting, billing account management, back office services and co-location providers, just to name a few.

I haven't had to fill out a SAQ-D SP myself, but I believe you should be able to mark large swaths of it N/A (with supporting explanation in appendix C).  For example:

  The questions specific to application development and secure coding (Requirements 6.3 and 6.5)
  only need to be answered if your organization develops its own custom applications.  You would need to fill out these sections, since you're developing software.
  The questions for Requirements 9.1.1 and 9.3 only need to be answered for facilities with
  “sensitive areas” as defined here: “Sensitive areas” refers to any data center, server room or any
  area that houses systems that store, process, or transmit cardholder data.  You could N/A this section, since you aren't touching the data yourself.

As always, I am not a QSA.  You should probably consult with one to confirm/help define what you need to assess, rather than relying on one random person on the internet.  This should get you started, though.


Windows groups and permissions: Authenticated Users group meaning

There are a number of special groups in Windows. Included among these are Authenticated Users, Interactive Users, Everyone, etc. These days, Everyone and Authenticated Users are effectively equivalent for most purposes, but if you had a pre-2003 domain level domain that would not be true.

In any event, there is no way to observe the membership of these groups. In a sense the membership is calculated when a SACL or DACL is processed.

That said, it seems strange to me that you would be assigning permissions in the file system to authenticated users, especially C:\.  A more appropriate setting would be Interactive Users or, if you're locking down workstations, read only.

The technical definitions of these two, according to Microsoft, are:

Authenticated Users:

  Any user accessing the system through a logon process has the Authenticated Users identity. This identity allows access to shared resources within the domain, such as files in a shared folder that should be accessible to all the workers in the organization.

Everyone:

  All interactive, network, dial-up, and authenticated users are members of the Everyone group. This special identity group gives wide access to a system resource.

You can find these for yourself, along with all others, here:  http://technet.microsoft.com/en-us/magazine/dd637754.aspx


Yes, it is possible to detect unknown keyloggers and other malware, usually through computer forensics (Volatility or EnCase are well-known software for doing that).

Keylogger detection, as for viruses and other malwares, can basically be achieved through two methods (I simplify for answer's clarity) :

Signature based detection
Heuristic based detection

Obviously, an unknown keylogger will not get caught by signature-based detection products (it can be though, in case of code-reuse for ex.), and you will have to rely on heuristics or behavioral detection, which usually generate a more false-positive results.

Fortunately, the thing is that keylogger developers usually rely on well-known methods to develop their malicious code, and that allows researcher to quickly find and detect them. Such methods are for example:

Using Loadable kernel Modules
Using System Call Table hooking
Using SSDT Hooking
Direct Kernel Object Manipulation (DKOM)

But generally, if your system has been compromised at kernel level by an unknown malware, the only thing you can do is get rid of it and reinstall a clean one, as kernel level modifications can be almost impossible to detect if done properly.

You can read this ESET Paper on detecting unknown malwares, or this one from Symantec, or just Google for one of the many interesting paper/article on this topic.


The single best way to begin in this area is to raise your awareness of others:

When conducting social engineering attacks, being very aware of this is part of understanding your target's reactions. Courses in social awareness, knowing your target, Neurolinguistic Programming and even sales training all build in elements of this, but it all comes down to practice and time - you can only get so far with theory.

Once you gain an awareness of what to look for, you will be able to look in a mirror to see what your face does.

And, disappointingly, you are likely to find at first that your microexpressions aren't controllable at all!

A suggested way to progress is to try and imagine basic emotions (like joy, sadness, terror etc) and seeing how they affect your expression. See what happens when you hear something sad but are thinking about something happy - that disconnect is what can happen when you are confronted by a target - your conscious mind is concentrating on not getting caught, which is different to the response of someone authorised to be there. So try and become adept at imagining and feeling the emotions of whatever character you should be.

Associated with this, being relaxed about the scenario should also reduce the magnitude of microexpressions, which makes them harder to pick up. Again, this will come with practice. I still find social engineering to be a challenge, as I'm often thinking about possible outcomes of any confrontation, rather than just going with the flow, knowing the scenario inside and out.

tl;dr - practice, be relaxed, gain familiarity with the scenario, and practice


What does Chrome use as the key for decrypting my saved passwords?

According to this article it's your OS password instead of your Google pass.


Manually migrate to another process without using metasploit?

There was recently a similar question here. The answer describes in a couple of steps how it works. In a second answer there is even a python example. I guess this also works relatively well with powershell - provided enough powershell programming expertise.


Is it possible to secure a web page from a Chrome extension?

No, because the user script/chrome extension could simply block the script element before it even loaded. A decently designed piece of malware would do this automatically.


Windows / Sensitive Data / Prevent access by various process

The best practice is exactly the same as for every privileged account (administrator, root, etc.): don't use it as a standard account.

All you need to do is NOT grant access to the DUDE.NAME account to the sensitive data and use HIGHSEC.DUDE.NAME instead.

You can effectively couple that with some form of isolation if necessary. For instance, you can require the user connect to a termnial services server using the HIGHSEC.DUDE.NAME account in order to access the sensitive data.


Heartbleed how to find out applications using statically compiled version of openssl?

In the OpenSSL code there are several string definitions related to the heartbeat feature:

./ssl/ssl_err.c:{ERR_FUNC(SSL_F_DTLS1_HEARTBEAT),       "DTLS1_HEARTBEAT"},
./ssl/ssl_err.c:{ERR_FUNC(SSL_F_TLS1_HEARTBEAT),        "SSL_F_TLS1_HEARTBEAT"},
./ssl/ssl_err.c:{ERR_REASON(SSL_R_TLS_HEARTBEAT_PEER_DOESNT_ACCEPT),"peer does not accept heartbearts"},
./ssl/ssl_err.c:{ERR_REASON(SSL_R_TLS_HEARTBEAT_PENDING) ,"heartbeat request already pending"},

So the chance is high the you'll find the string heartbeat (ignore case) in the statically compiled program.


What can an attacker do with Bluetooth and how should it be mitigated?

(Note: This answer is from 2013. A lot has changed in Bluetooth since then, especially the sharp rise in BLE popularity, new attacks, deprecated features. Having that said, most of it is still applicable.)
Introduction
I'll try to the best of my knowledge to approach your questions without touching the technical parts of the Bluetooth technology itself. I've learned a lot of the following while I had to write a security report to shape a BYOD policy. Knowing you, I won't have to lecture you on that there's nothing 100% secure, everything we do is just to make it harder for the bad guys.
What Bluetooth is NOT

Bluetooth itself as a technology isn't secure, it's not only about the implementation, there are some serious flaws in the design itself.

Bluetooth isn't a short range communication method - just because you're a bit far doesn't mean you're safe. Class I Bluetooth devices have a range up to 100 meters.

Bluetooth isn't a mature communicate method (security-wise). With smart phones, it has turned into something totally different from what it was meant to be. It was created as a way to connect phones to peripherals. My advice: Don't use Bluetooth for anything serious.

How is Bluetooth being secured now?

Frequency hopping like crazy: Bluetooth uses something called AFH (Adaptive Frequency Hopping). It basically uses 79 channels in the 2.4 Ghz ISM band and it keeps hopping between them on a rate of 1600 hops/s, while observing the environment and excluding any existing frequencies from the hopping list. This greatly reduces interference and jamming attempts.

E0 cipher suite: Uses a stream cipher with a 128-bit key.

Undiscoverability: Unless you set your device to "discoverable" it won't respond to scanning attempts and your 48-bit BD_ADDR (the address that identifies your Bluetooth-enabled device) won't be revealed.

Pairing: Unless the devices are paired with the parties' consent they won't be able to communicate. A pairing request can only be made if you know the other device's BD_ADDR (through scan or previous knowledge).

Is it a good idea to remove & re-pair my devices on a set interval
(thinking that this is changing the Bluetooth PIN)

Yes. It's a very good idea. You're eliminating the risks of being exploited by your trusted devices. Given that we usually pair devices for insignificant reasons (sending a file to an acquaintance, getting a VCard from a person you met somewhere..) it's very likely to build a huge list of "trusted" devices if you use Bluetooth a lot.

What is the security impact of making my device or computer
"discoverable"?

The problem with making your device discoverable is that you're advertising your BD_ADDR to anybody asking for it. The only way to pair with another device is by knowing the BD_ADDR. In a targeted attack, it's gonna take some time to brute-force the 48-bit BD_ADDR.
In the normal case, knowing your BD_ADDR shouldn't be a big problem, but in case there's a vulnerability in your phone or the Bluetooth software on your computer, it's better to be under the radar. Another problem is the impact on privacy; by being discoverable you're letting unpaired (untrusted) parties know when you're around.

What kind of access does a Bluetooth enabled device get on my system?

In the normal case (no vulnerability to allow arbitrary code execution) it all depends on the Bluetooth profiles supported by your device. Usually, you can assume that your computer supports all profiles. I'll just list a few:

BHIDP (Bluetooth Human Interface Device Profile) will give access to your mouse and keyboard event firing (moving the mouse and sending keyboard keys).
BIP (Basic Imaging Profile) will give access to your camera.
A2DP (Advanced Audio Distribution Profile) will give access to your MIC and to your audio output.
OBEX (OBject EXchange) is what you usually need to worry about. Depending on the implementation, it could give access to your files, phonebook, messages, etc.

Are there Bluetooth security features that may (or may not be
enabled)? How can I audit for the presence (or lack of) these
features?

Prior to Bluetooth V2.1, when implementing the protocol itself, the developer has the options to use Security Mode #1, which means no security at all. Devices are allowed to communicate without the need of pairing, and encryption isn't used.
Bluetooth V2.1 and newer require encryption.
As a user, there are a few things you can do to make your Bluetooth usage more secure. (See below)

Assuming encryption is a security feature that can be enabled, is it
required or is it optional?

As in the previous question, it's implementation-dependeant. Usually encryption is used by default in PC-PC, smartphone-smartphone, and PC-smartphone communication. As of Bluetooth V2.1, encryption is enabled by default.

What can an attacker do once a malicious device is paired with mine?

Basically, anything that your device supports. To demonstrate this, just use an application called Super Bluetooth Hack, you'll see very scary things including:

- Ringing: playing sounds of incoming call, alarm clock.
- Calls: dialing number, ending a call.
- Keys, Pressed keys: pressing and watching pressed keys
- Contacts
- Reading SMS
- Silent mode: turning on or off
- Phone functionality: turning off the network / phone
- Alarms
- Clock: change date and time
- Change network operator
- Java: start, delete java applications
- Calendar
- Memory status
- Keylock

So what's wrong with Bluetooth?

Complete trust in the paired device: A paired device has access to virtually all of the profiles supported by the other device. This includes OBEX and FTP (File Transfer Profile).

Profiles have too much freedom: Profiles are allowed to choose whatever security mode they want. You're even able to implement your own version of OBEX without Bluetooth requiring you to use encryption or authentication at all. (Prior to Bluetooth V2.1)

Weaknesses in E0: Since 1999, E0 vulnerabilities started to show. It was proven that it's possible to crack E0 with 264 rather than the 2128 previously believed. Year after year, researchers have discovered more vulnerabilities, leading to the 2005 attack by Lu, Meier and Vaudenay. The attack demonstrated the possibility to recover the key with 238 operations.

Pairing is loosely defined: Devices are allowed to implement their own pairing methods, including a 4-digit PIN which can be cracked in no time.

Finally, for good practice guidelines:
I'll list some of the important NSA Bluetooth Security Recommendations (I've modified some of them and added some of my own):

Enable Bluetooth functionality only when necessary.
Enable Bluetooth discovery only when necessary.
Keep paired devices close together and monitor what's happening on the devices.
Pair devices using a secure long passkey.
Never enter passkeys or PINs when unexpectedly prompted to do so.
Regularly update and patch Bluetooth-enabled devices.
Remove paired devices immediately after use.

Update: An hour ago I was diving in the Bluetooth V4.0 specs, and, to my surprise, it appears they're still using E0 for encryption, and there were no good changes to the pairing mechanism. What's even worse is that they're pushing forward the number-comparison pairing mechanism, in which the users are shown a six-digit number on the two devices and asked to verify if they're the same. Which, in my opinion, opens huge doors for social engineering attacks.

For pairing scenarios that require user interaction, eavesdropper protection makes a simple six-digit passkey stronger than a 16-digit alphanumeric character random PIN code.

Source
Update 2: It seems like this "Just Works" 6-digit PIN is indeed problematic. Mike Ryan has demonstrated an attack on BLE and released the code as his tool "crackle" to brute-force the temporary key and decrypt the traffic.