How secure is asking for specific characters of passwords instead of the entire thing?

This method of password entry is popular in bank sites in Poland. It's called masked passwords. It's meant to protect from keyloggers - and keyloggers only. The password transmission itself is protected from sniffing with SSL, so the reasoning is that if keylogger is installed on client's device, it will never get access to the full password.

However, this logic has a few flaws:

Attacker needs to enter fewer characters (e.g. only 4 characters, often numbers only) for a single try. Therefore it's easier to brute force this authentication step. That is why masked passwords need to be paired with account lockout policy.
With just a few known characters at certain positions (e.g. gathered by a keylogger/screengrabber) attacker can simply try logging in when the server chose positions he knows and refresh when others were chosen. So often masked passwords implementation stores the positions choice for an account server-side for certain amount of time (e.g. a day) until successful authentication.
Getting to know the whole password only needs capturing a few successful authentications (e.g. when password length is 12 and there are always 4 positions chosen, it usually takes 8 tries), so a keylogger/screengrabber will get it - it will just take a little bit longer.
The biggest threat for Internet banking authentication is malware (man-in-the-browser attacks) like ZeUS or SpyEye and this kind of software usually conducts social engineering attacks that totally overcome masked passwords scheme. For example, this software can:

ask for a whole password
display a fake password change form after fake authentication
simulate password entry errors and redisplay the form with other positions to fill to get full password in 2-3 tries

Masked passwords are being difficult to handle for users and tricky to implement correctly. At the very least developers need to add account lockout policy, positions choice storage and partial hashes.

Contrary to popular belief, masked password, especially in e-banking sites, though they offer protection from basic keylogging, completely fail to other, more prevalent threats like malware utilizing social engineering.


Is there a way to bypass Django's XSS escaping with "unicode"?

It is not clear what exactly the slide is referring to. Django's auto-escaping should be fine against HTML-injection in text content and properly-quoted attribute values.

There are not other Unicode characters that can evade HTML escaping, but in principle there are byte sequences that could be misinterpreted as being in the wrong Unicode encoding:

If the browser decides to interpret a document as UTF-7, +ADw- becomes a synonym for < (and similar sequences for &"'>), allowing HTML metacharacters to avoid being escaped.
Some East Asian multibyte encodings allow trailing bytes in a multibyte sequence to be in the 0x00-0x7F range where they could be interpreted as ASCII characters, and mis-escaped if handled in that way. Usually that would just lead to broken text rather than a security issue, though.
Invalid 'overlong' UTF-8 byte sequences may be interpreted as ASCII by some very old browsers (the original IE6 pre-SP1, and Opera at around the same time). This could allow HTML metacharacters to avoid being escaped, such the byte sequence 0xC0 0xBC representing <.

To avoid these problems you would (a) make sure to serve your documents with a UTF-8 Content-Type charset, and (b) keep all your text strings as native Unicode strings internally so that they can never encode to invalid UTF-8 sequences.

Since Django apps tend to do this by default already, it is not a likely scenario that Django templates' auto-escaping would be defeated by Unicode problems.

That's not to say XSS is solved in general of course - you still have to avoid misuse of |safe, unquoted attributes, non-HTML injection problems (like JavaScript strings, CSS properties, URL parameters), HTML content-sniffing, dangerous URL schemes (javascript: et al), and so on. But as a defence against HTML-injection in templates it should be sound.


Where do I get prime numbers for Diffie-Hellman? Can I use them twice?

Actually it is not that hard. It may be slightly expensive, computationally speaking.

A good DH modulus and generator is what you get when generating DSA key parameters; see the DSA specification. You get to choose the subgroup order (q, a prime number), the modulus (p, such that p-1 is a multiple of q), and a generator for the subgroup of size q. OpenSSL can do that for you. It is not very hard to implement yourself, provided that your programming language and environment provides some support for arbitrary-length integers (Python and Java do, C does not, unless you use an extra library such as GMP).

Alternatively, some effort has been invested into generating so called "safe primes": prime integers p such that (p-1)/2 is also a prime. A safe prime is called such because it does not suffer from some attacks which may make discrete logarithm easy (or at least easier) on some "weak" modulus -- but a randomly generated modulus will not be weak, with an overwhelming probability, so there is no real worry here. Also, "safe primes" have the advantage of allowing g=2 as generator, which promotes computational efficiency (not by much, but still). Generating a safe prime entails trying random odd integers of the right size until you hit a safe prime: nothing complex or even hard to implement, but it can take a few minutes to complete (about one odd 1024-bit integer in 400000 is a safe prime). Or you can use one of those from RFC 3526.

There is no problem in using the same group parameters (modulus, generator) for millions of distinct key pairs. They are indeed "public data".


I do the following to force youtube to "forget" me.

Use firefox (just because I think it's better, but this shouldn't be required)
Configure flash to not store any data (right click on a flash app/video, select global settings, storage tab -> "block all sites from storing information on this computer")
Now when you delete the cookies, google won't be able to re-create them from any flash data.

If you do want to allow some sites to store data in flash, you can block just one site.
The reason why google can rebuild the history is (probably) because it has the data both in web cookies and flash cookies, so as long as one is present when you visit youtube, google can rebuilt the other cookies.

Source: I just tried this :)


You do not speak of your email server/provider. Some allow you admin access to search for and delete/purge emails with certain header info or subject lines (I know I did it in MS Exchange and Google Apps).

But, technology can only take you so far with email protection. If your vendor is offering you all the technical support they can, you need to supplement with triggering your Security Awareness program.


Open IMAP connection using hashed password

The supported authentication methods depend on the specific IMAP server. Some supported methods like XOAUTH2 which delegate the authentication to some external server via OAuth2. There are also methods like CRAM-MD5 which don't transfer the password in plain. While with CRAM-MD5 it might be possible to store the password hashed (but not salted) it does not help much if the attacker can compromise the local password storage:
If an attacker steals these credentials they can identify themselves as valid user to the server no matter if the hash or password is used. The difference is thus more relevant for transport protection but there it is better to use TLS anyway. And it is relevant to protect against password reuse - so it is better to have a unique password for the IMAP access.


I'm afraid what you're asking for is impossible. If you want new users to be able to use your app, someone will find a way to pose as a new user every time and falsifying the votes that way. The only solution is to have a trusted party certifying the identities of everyone, and that won't happen until every ID card out there is a standard smart card with a client certificate in it. As of right now you could in theory rely on a CA, but that would be a huge barrier of entry and nobody will ever use your app.

You could make it more difficult though. Using certificate pinning on the app's side so traffic analysis is more difficult, and obfuscating the binary will slow down potential attackers who want to replicate the behavior of your app, but even then, the attacker just has to uninstall/reinstall your app and it'll appear like a new install on most devices.

If possible on your target devices, you should rely on an identifier provided by the host OS or the app store - that is harder to replicate (or even impossible if your server is contacting the app store's servers to validate the installation of your app) than replicating an app as the OS has ways to access the hardware and get per-device IDs from that (MAC address, IMEI, etc) while your app can't access those directly.

You could also tie the unique device IDs to something harder to obtain, like phone numbers by requiring an SMS confirmation every time the app is installed. It won't stop fraud (and as such is unsuitable for "formal" voting like elections or anything where money is involved) but it will help. It's like DRM, it doesn't need to be bulletproof, it just needs to be stronger than the competitor's apps and attackers will go after the low hanging fruit, leaving your solution alone.

Finally if all you're looking to defend against is mass-voting by bots but don't care about occasional, manual voting then adding a captcha is enough. Of course, this will only work while money isn't involved - otherwise it may still be profitable for the attackers to hire humans to type the captchas and commit fraud that way.


Is my email, pc or something else hacked?

I doubt that your account is hacked. I think what you experience here is cognitive bias instead.
Such phishing mails are pretty common and one even gets these without having iCloud or Paypal accounts. Usually one simply ignores these mails. But if one suddenly gets such a mail after creating or using such accounts, one is prone to assume a causal link between these two events - even if none exists.
This cognitive bias does not need to be solely caused by one's own mind. A self-adapting spam filter might play its role too: If usually such phishing mails are treated as spam and automatically moved away, the spam filter might realize that one suddenly has an actual interest in iCloud and Paypal. It might therefore treat new mails about this topic as relevant too. This way one will suddenly be exposed to phishing mails, which in the past would be automatically moved out of sight.


Maybe look into creating or applying advanced analytics to web application activity to profile users for the purpose of identifying potential bad activity.  Build on top of what ModSecurity outputs and test algorithms/models that make it easier for a security operations team to quickly understand what activity a particular user is doing and why it may be hostile (talking beyond reporting simple atomic events).

Do an amazon search for “machine learning security” or “data mining security” and find books, for example, like Statistical Techniques for Network Security: Modern Statistically-Based Intrusion Detection and Protection http://www.amazon.com/gp/product/159904708X/ref=wms_ohs_product and research which techniques described in those books may advance web application security.  There seems to be a near infinite way to mix and match algorithms - your research could result in new ways to combine existing algorithms to produce better results.

Reading Robert Hansen’s blog entry on web log forensics may spawn additional ideas:
http://ha.ckers.org/blog/20100613/web-server-log-forensics-app-wanted/


Should HMAC key be changed regularly? Should it be kept secret at all times?

You don't need to change the HMAC key unless you believe it has been compromised (or for some other reason, you wish for messages authenticated under the old key to no longer be considered valid).  Assuming you use a reasonable hash function, signing "too many" messages with the same key does not compromise the key.

All of the security of HMAC comes from the HMAC key being kept secret, so sending it in plaintext would almost certainly defeat the whole purpose of using HMAC rather than just a public, unkeyed hash.  If you need to be able to change keys, you may want to rely on asymmetric (public key) cryptography instead, although you haven't stated enough about your application for a more specific recommendation to be possible.


There is no one solution to this complex problem.

A client can enable the Do Not Track http header element.  But there is no guarentee that the server will respect it.  The PrivacySuite addon goes one step further to actively block tracking gadgets.  There are *MANY* other anti-tracking addons for firefox as well as some for Chrome and I have no idea which one(s) are the best.

Ad-block Plus will keep your browser from loading many of these tracking gadgets, and even if such a gadget where to be loaded it will block the targeted ads.  This solves the symptom but not the root of the problem.

NoScript might help,  but this doesn't stop a server from setting a cookie via the http cookie header.  It does however prevent some evercookie techniques.

Relivent TED talk:  Tracking the Trackers

Also its wroth while to learn about Google's "Remarketing" feature for advertizes.


Is certificate pinning enough to protect client (native mobile app) - server communication?

The app should consume an RSS feed (https call) from the server but there is no need to have authorization in place. The output does not depends on the user.

In this case I'd consider the need for an app at all... But that's not important.

I was trying to look around for ways to have some form of security for my server to be sure that the caller is my mobile app.

No, it would not be. It would make it more difficult to discover the endpoints used by your app, but still trivially doable. Replacing the certificate and rebuilding an APK is rather trivial - and it's enough that one person does it.
You can use Safetynet attestation or Devicecheck for IOS to verify that the device is not compromised, and verify your app integrity. Note that this is not foolproof either, but it raises difficulty somewhat.
Ultimately, your problem is unsolveable. The moment the data leaves your server, you have no control over how it's used anymore. You can make it somewhat difficult, but it can be broken. Hollywood has spent the last 20 years trying to implement DRM - but name a movie released in the same time span that has not been pirated...


You could use Burp Intruder. This is only in the paid version of Burp, but it's not that expensive.

You would first capture a manual login using the proxy, then use Intruder to fuzz for valid passwords.


What makes servers vulnerable to Return Of Bleichenbacher's Oracle Threat (ROBOT) attack?

The server is vulnerable to Return Of Bleichenbacher's Oracle Threat (ROBOT) only if it is hosted on a vendor software with RSA implementation bug and server supports RSA key exchange ciphers.

See the list of known vulnerable vendors and patches https://robotattack.org/#patches

Note: Not all servers that support RSA key exchange are vulnerable. But it is recommended to disable RSA key exchange ciphers as it does not support forward secrecy.

Robot vulnerability Severity:

For hosts that are vulnerable and support only RSA encryption key exchanges, it's severe vulnerability. An attacker can passively record traffic and decrypt it later.

Mitigation steps:

Ideally, following both mitigation steps should be taken.

Update your server; patches are provided by most of the vendors.
If you patch your server your immune to ROBOT vulnerability.

Note: If the patch is not available from your vendor, you can mitigate with 2nd step.

Disable RSA key exchange ciphers (Recommended): But if you want to keep support for RSA key exchange ciphers.
Your server should at least support forward secrecy with modern browsers. (keep RSA ciphers last)

Identifying RSA key exchange ciphers:

SSL Labs uses TLS_* format. So that means all ciphers starting with "TLS_RSA" on the report.
OpenSSL uses the different naming convention. All ciphers with "Kx=RSA"


What dangerous characters need to be filtered from user input prior to use in a DB2 SQL query?

"Sanitization" is fragile. You have to think of every single detail of how the database interprets "special characters", and you have to keep track of it closely, in case a new sub-version of the database introduces extra special characters. This is exhausting work and it often fails.

The (much) preferred way of inserting user data into SQL queries is to use prepared statement. This will be easier for you (the programmer), more robust, more secure, and quite possibly faster.


How to prevent attempts to log into my accounts?

It is possible that the username/password have been leaked somewhere.
For this you can check https://haveibeenpwned.com/.

You did the right thing by changing passwords and using 2FA where possible. Also make sure that you use unique passwords per service.
This can be managed with a password manager. Creating random strong passwords without the need for you to remember them all.

This way, if passwords get leaked, only one account can be 'hacked'.

If you're receiving failed login attempts, then probably someone is still trying to access the account with the leaked password. Knowing you changed it and enabled 2fa, it should be no problem.


The main problem I see with this scheme is what's called the Key Distribution Problem: how do you securely deliver password_b to the device?

In step 2, the user inputs password_b into a web-form. Presumably in step 5 password_b is sent to the device over an unsecured websocket connection. From then on, the device encrypts all websocket data using AES with a key derived from password_b.

My issue is with step 5: if it's being sent in plaintext then an attacker on the same network as the device could just wireshark the password out of the packet. Even if you use a standard server-authenticated TLS connection, the server would have no way of proving which device it's talking to and an attacker could connect and claim to be the device and get the server to send it password_b.

My suggestion is that if you can afford to run a TLS library, then give each device a client certeficite during manufacturing and have the server keep a table of which public key belongs to which device serial number. This way, when a device connects to the server over TLS, the server knows which device it's talking to just from the public key / signature.

Usually you would use an SSL/TLS ciphersuite that wraps AES, rather than inventing your own protocol because as @Rook suggests, there's just so many ways to shoot yourself in the foot. I understand that some low-power devices can do AES but don't have the memory footprint for a full TLS library. Fine, but you'll have to either become a crypto expert, or hire one, to be sure you're doing it right because you're going off the beaten trail here.


Securely determine my smart phone's position (in front of the door)

In this case the security can indeed be circumvented, because GPS isn't secure. Having the phone out of range of the Bluetooth device is actually a help.

The weak point of the attack is this:

  From outside the window, fake GPS signal to fake leaving and entering the geo fence

"Faking GPS signal" is not really easy since you also have the real signals coming in. You might set up a GPS receiver somewhere else, and have the signals it receives sent back to a powerful retransmitter next to the victim phone. This is probably not going to work too well due to retransmission delays, which will mutually invalidate several satellite signals (the satellite constellation will appear to be farther out than LEO orbit, and be wobbling something fierce). What you would see if you were looking at the phone with a map app turned on would be the "You're Here" dot jumping around like crazy, and disappearing altogether for several seconds or minutes. Actually I'm not so sure you could acquire a position. But I have seen that slightly messing with GPS signals results in the blue dot floating at random around the count(r)y, and its uncertainty radius to grow proportionally.

If this is enough to activate the geofence trigger, you're golden. And, to thwart this attack, what you need to do is monitor the GPS position and ensure it's sane (no jumping around at more than 200 km/h, for example). So an additional requirement for the "improved geofence" is for the phone to stably position itself outside of it for a reasonable amount of time with a small uncertainty radius.


Injection/SQL Injection Attacks in Layman Terms

In layman terms:

Typical web applications are three-tiered(browser +web server + backend databases). When a user accesses a website, his browser receives html and js which is product of static web pages as well as dynamically generated ones using server side code (e.g. php, asp). When you login, for instances, you send your password and username to the web server, which processes such parameters and applies the pre-programmed authentication logic (in php,asp).Such logic requires verifications using a database that stores users data and allows the simple verification: username matches password. So, the server side logic takes your arguments and queries the database (e.g. MySQL).

SELECT * FROM Users WHERE username='your_supplied_username' AND password='your_supplied_password';

The database processes this and returns (if the database is correctly designed) only one (username and password match) or zero (wrong password) matches which "represent you".

What about SQL Injection Bro?

I am not your bro, bro :P. A sloppy developer would take the parameters sent by you and put them directly on the your_supplied_* fields. If the user wasn't malicious, this would be no problem at all. Yet, for a malicious attacker, this opens a huge door for attacks. If you are familiar with SQL, you know that AND requires both left and right expressions to evaluate to true. Also, in SQLi, the comment character "--" is an helpful friend so, what if i write my_username';--?

SELECT * FROM Users WHERE username='your_supplied_username';--' AND password='your_supplied_password';

Server side code will take my input, apply it to the stringed query and send it to the database. The database will interpret "--" as a comment which will exclude:

' AND password='your_supplied_password';

while keeping:

SELECT * FROM Users WHERE username='your_supplied_username'

This is a valid query which will easily evaluate to true. Now, the behavior here varies. If the username is unique (typically it is), there will only be one record returned. If it isn't, multiple records will be returned and the web server code (e.g. php) will typically pick the first. If you are familiar with SQL, you may now get creative and chain queries, use wildcards and get wild. Now the question is:

As a developer, what can i do?

Now, this depends on the server side language you are using but the coding primitives are typically named alike. You can escape special sequences using php (http://php.net/manual/en/mysqli.real-escape-string.php) or use prepared statements (http://php.net/manual/en/mysqli.quickstart.prepared-statements.php).

How do i know if the server suffers from SQLi?
You can run tools such as SQLMap or SQLNinja. You can also go to the forms and write

'gibberish
where the ' will hopefully confuse the php query parser and leak an error shown on your browser (SQL statement error). There are other techniques such as injecting a sleep statement on queries to check if the database hangs for a few seconds before returning. As a defense mechanism, you should always process your SQL errors on the server side code before sending them to the user to avoid intel leakage.

Stay safe ;)


I'm not sure how I can further exploit this, maybe someone knows?

There is need of enumeration here to know what kind of protection is in place and if there is any known way to bypass it?. Try supplying clean ldap queries and looking for change at response's characteristics or values then try for other techniques like blind ldap queries and other known techniques. You may also receive help by reading burp suite's description over the vulnerability and follow their blog to see what techniques they have mentioned and follow the methodology to conclude if the techniques work in your favor. Hope this helps.


The safest way to transfer files to an offline test environment

Use a virtual machine that can control a USB device, and that takes away control by the host machine, i.e. the host machine no longer sees the USB when it is inserted.

Then transfer the files by cheap USB stick and physically destroy it afterwards
(Or store it safely for future investigation)

Sorry, I do not know which VMs offer this (does VMware do this?).


How can I prevent side-channel attacks against authentication?

From the code example provided, it is possible to determine the correct password by timing the code when given various inputs.

First, you shouldn't actually examine the password directly!  At the very least, you should hash the password with a password hash like Argon2id first, and compare the password hash of the input with the password hash you stored during user registration (or when the user last changed their password).

Even better, you should use a password-authenticated key agreement protocol like OPAQUE, but these may be beyond your pay grade at the moment until they see more widespread adoption and implementation.

  What can I do to ensure that my code is not vulnerable to such timing attacks?

The best way to start is to use a library routine or primitive that someone else has already written and has a reason to maintain.  For example, in NaCl/libsodium, you can use crypto_verify_32 to compare two 32-byte strings, like two Argon2id hashes, or two HMAC-SHA256 message authentication codes.  Then the effort to answer this question can be focused on a single place that will get a lot of attention and scrutiny and will keep up with advances.

But let's say you don't have crypto_verify_32, or you want to impleent it yourself.  What can you do?

To start, you need to understand what operations have side channels.  It's tempting to say—as other answers did—that the side channel arises only because of an early
abort.  But that's not the whole story.  In general, there are many operations  (here written in C for illustration) that may take an amount of time which depends on the values of the inputs—we call these operations variable-time operations, in contrast to constant-time*:

for (i = 0; i < n; i++) if (x[i] == y[i]) return EFAIL; obviously takes fewer loop iterations so it is practically guaranteed to run in variable time depending on the secret values of x[i] and y[i].
A mere secret-dependent conditional for (i = 0; i < n; i++) if (x[i]) bad++;, if x[i] is secret, may run in variable time too even if the loop doesn't abort early.  Why?

Here's a coarse approximation.  The machine instructions that the CPU may execute look something like this:

0:      tmp := x[i]
        branch to 1 if tmp is zero
        bad := bad + 1
1:      i := i + 1
        branch to 0 if i < n

The number of instructions executed depends on what the value of x[i] is at each iteration: we skip bad := bad + 1 on some iterations.  This is a good model for how early timing attacks on, e.g., RSA worked as in Kocher's seminal paper on timing attacks: the main modular exponentiation loop computes a (say) 2048-bit modular squaring unconditionally, but computes a 2048-bit modular multiplication conditionally depending on the value of the secret exponent.  Skipping the multiplication substantially changes the time taken by the whole operation.
There's another reason, though, and it has to do with branch prediction, a key design element in what makes modern CPUs run so fast on many workloads—even if you write the same amount of code (say, same number of machine instructions, and somehow you guarantee that they take the same number of cycles to compute) in each branch of a conditional, the time it takes to execute may depend on which way the condition went.
In general, CPUs are bad at keeping which instructions got executed secret, so don't make the choice of instructions depend on secrets.

Table/array lookups might take a different amount of time depending on what memory has been cached in the CPU cache.  Consequently, if the location in the array that you're reading from depends on a secret, the time it takes might depend on the secret, which has been exploited to recover AES keys by cache timing.

(This makes AES a rather questionable design in retrospect, with its intentional use of key-dependent table lookups!  NIST's published rationale (§3.6.2, Attacks on Implementations: The Role of Operations) curiously claims table lookups are ‘not vulnerable to timing attacks’ despite the numerous such attacks that have been reported since then.)
Variable-distance shifting like x = y << z may take more time on some CPUs if z is larger and less time if it is smaller.

(This makes RC5 and the AES finalist RC6 rather questionable design in retrospect, with their intentional use of key-dependent rotation distances!)
On some CPUs, multiplication may run faster or slower depending on whether the upper half of the inputs is zero or not.
64-bit integer addition on 32-bit CPUs in principle might take more time depending on whether there is a carry.  This is because, when x, y, and z, are 64-bit integers, the logic x = y + z might look something more like:

int carry = 0;
x[0] = y[0] + z[0];
if (the previous addition overflowed)
  carry = 1;
x[1] = y[1] + z[1] + carry;

Consequently, the time it takes may depend on whether there is a carry from the sum of the low 32-bit halves to the sum of the high 32-bit halves.  (In practice, this is usually only a concern on exotic CPUs or for other types of side channels like power analysis that are relevant more to smart cards than to laptops and phones.)

This might sound a little overwhelming.  What can we do?

There are some operations that generally do run in constant time on most CPUs.  They are:

Bitwise operations: x & y, x | y, x ^ y, ~x, and other ones that don't appear in C like AND-with-complement.
Constant-distance shifts and rotations like the shift x << 3 or the rotationx <<< 3 (not standard C but common in cryptography; it means (x << 3) | (x >> (32 - 3)), if x is 32-bit).
Often integer addition and subtration: x + y, x - y, when x and y are (say) unsigned 32-bit integers on a 32-bit CPU, and often even 64-bit integers on a 32-bit CPU with the help of ADD-with-carry instructions.
Sometimes integer multiplication, but the story about multiplication is complicated, which is unfortunate for cryptography because multiplication mixes bits around quite nicely and has useful algebraic properties.

To be clear: I do not mean that a C compiler guarantees these operations run in constant-time if you use them in a C program; I am merely using C notation for the operations that CPUs generally execute in constant time.  (More on this caveat in a moment.)

‘But wait,’ you protest, ‘how can I possibly write a useful program out of these operations?  No conditionals?  No loops?  No arrays?’

First, you don't have to eschew conditionals, loops, or arrays altogether.  They just can't depend on secrets.  For example, for (i = 0; i < 32; i++) ... x[i] ... is fine.  But for (i = 0; i < m[0]; i++) ... is not fine if m[0] is supposed to be secret, and for (i = 0; i < m[0]; i++) ... tab[x[i]] ... is not fine if x[i] is supposed to be secret.

Second, you can still build these things!  It's just a little trickier.  For example, suppose b is a uint32_t that is either 0 or 1.  Then b - 1 is either -1 = 0xffffffff or 0, respectively, so

x = ((b - 1) & z) | (~(b - 1) & y);

causes x = y if b is 1, or x = z if b is 0—much like x = (b ? y : z), but without a branch.  Obviously, this requires computing both y and z, so there is some performance impact!  Similarly, you can look up an element of a table by looking up all elements of the table and selecting the one you want with bitwise operations like this.  Not as fast as x[i], but not as leaky either.

In general, you can convert a program with conditionals into a logic circuit with no conditionals, even if you don't want to for performance reasons.  There are various other similar tricks you can do.  You might draft a constant-time memory equality routine such as crypto_verify_32 like this, assuming x and y are uint8_t arrays:

uint32_t result = 0;
for (i = 0; i < 32; i++)
  result |= x[i] ^ y[i];
return ((result - 1) >> 8) & 1;

Exercise: Does this return 0 for equal and 1 for inequal, or 0 for inequal and 1 for equal?

Writing programs like this—and adopting cryptosystems such as X25519 that encourage implementations that look like this, instead of cryptosystems such as RSA or AES that encourage implementations involving involve secret-dependent branches or secret-dependent table lookups—is a good start for plugging timing side channels.

But, there's a catch!  Remember when I said that the C compiler doesn't guarantee constant time?  A smart C compiler like Clang/LLVM might recognize that the clever crypto_verify_32 loop above can be executed more efficiently by making it abort early, and might undo the hard work you did to rewrite it as a logic circuit that runs in constant time.  (In other circumstances, it might help you out, for example by converting x = (b ? y : z); into a conditional move instruction, CMOV, without branches, but usually you can't rely on the C compiler's good will.)

There are some tricks you can do to thwart this, like an inline assembly fragment that causes the compiler to drop roughly all assumptions for optimization:

uint32_t result = 0;
for (i = 0; i < 32; i++)
  result |= x[i] ^ y[i];
asm volatile ("" ::: "memory");
return ((result - 1) >> 8) & 1;

This may or may not work with your compiler.  To be confident, you really have to examine the compiler's generated machine code—and even then, a compiler might perform just-in-time optimizations that rewrite the machine code according to profiling analysis, especially in higher-level languages like Java.  So you might really want to write the logic in assembly (or in a programming language like qhasm that can generate the fine-tuned assembly more reliably than a C compiler), and just call it from C.

Maybe some day C compilers will adopt a secret qualifier, like const or volatile, which forces the compiler to generate only machine instructions that are known—in some model of the CPU!—to run in constant time when operating on the object, and prevents the compiler from taking shortcuts like secret-dependent early aborts from a loop.  But that day is not here yet.

There's also a matter of which machine instructions actually run in constant time on a CPU, which is sometimes documented and sometimes reliable.  So in addition to doing engineering to build your programs out of logic circuits, you also need to do science to figure out which operations are actually safe to use on the CPU.

This brings us back to the original point: You really want to focus the effort of maintaining this into a library routine, so that each programmer doesn't have to keep track of vagaries of compilers (and CPU designs!) in generated code and timing on their own, and can instead leave it to our friendly neighborhood bear.

Are there other countermeasures than constant-time logic?  Sometimes, yes.

You could inject random noise into your logic, in the hope that it will confuse the attacker's measurements.  But there's already noise in their measurements, like scheduling in the operating system, so they just have to take more samples—and it turns out noise is not a very effective side channel countermeasure.

Specifically, artificial noise raises the attacker's costs by at most about the square of the ratio of artificial noise to true noise, which is far below what is usually considered an acceptable gap for security in cryptography.  So it mostly costs you a lot of time doing nothing.
You could use algebraic properties of the cryptosystem to randomize it, sometimes called ‘blinding’.  For example, instead of computing y^d mod n where d is a secret exponent in RSA, you could pick r at random, compute s := r^e mod n where e*d ≡ 1 (mod (n)), multiply y by s to get (y * r^e) mod n, compute (y * r^e)^d mod n = (r * y^d) mod n, and then divide off r.

Many implementations, such as OpenSSL, use this approach because it's an easy way to retrofit an existing implementation of a cryptosystem like RSA that has the necessary algebraic structure.  It's not a bad idea like random noise is, but it does have costs: you have to do the extra work for randomization, you have to have modular division or inversion logic—and side channels might still leak information about r and d.  For example, even blinded modular exponentiation will leak the Hamming weight of d unless you take additional countermeasures like adding a random multiple of (n) to d first—which may expose additional side channels, etc.
For the specific case of comparing two byte strings for equality (for example, two message authentication codes), one reasonable option is to hash them with a pseudorandom function family like HMAC-SHA256 under a one-time secret key k, and check whether HMAC-SHA256_k(x) == HMAC-SHA256_k(y).

The probability of a false positive is 1/2256, which is a smaller probability than you ever have to worry about.  You can safely use variable-time equality for the HMAC because if x is not equal to y, then the amount of time even in the naivest byte string equality routine (assuming it doesn't bail out at the first zero byte or something stupid like that!) will be independent of the values of x and y: there's a 255/256 probability it'll stop after one iteration, a 65535/65536 probability after two iterations, etc.

Of course, this really helps only if you can implement HMAC-SHA256 in constant time!  Fortunately SHA-256 is designed to be easily implemented as a constant-time logic circuit, so C implementations tend to be reasonably resistant to side channels—but, say, Python will get you into trouble because of the small integer cache if nothing else.

* The terminology is unfortunately a little confusing.  Here constant-time means that the amount of time does not vary depending on inputs, and is not the same as the asymptotic notion of ‘constant-time’ in computer science, often written O(1), which just means the amount of time may vary depending on inputs but is bounded by a constant.  I'm sorry.  I didn't invent the terminology.  I might have chosen ‘fixed-time’ vs. ‘variable-time’ but it's too late now—‘constant-time’ is entrenched in the literature.


PBKDF2: can the salt be known from the hash?

A “salt” which is derived from the input data is no salt at all. In other words, this is an unsalted hash function which only takes a password and an iteration count and calculates the resulting hash. If the iteration count is constant, then the same password always yields the same hash.

The whole point of the salt is that it's additional input. Contrary to popular belief, it's not secret in any way, but it must be sufficiently random.


Is there any benefit to requiring authorisation to access static assets in a web application?

Static assets like JS, CSS and Images those are already in public domain need not to be authenticated requests. By making it authenticated you are putting extra load on the server and restrictions on using CDN and Cache servers which will negatively impact the performance.

If these files are dynamically generated to serve differently for each signed in user or it contains user specific details like a JS data or a profile picture then it should be requested with authentication. Also, You can remove the authencation here by making the file names for such assets hard to guess.


Are there VPNs which don't log your activities?

The only way for you to know is if a given VPN provider (or an ISP for that matter) gives you access to their systems for you to see the configuration. And this is very likely to never happen on a large scale manner.
Therefore, you have to trust their claims and/or some third party auditing company which has done that work and vouch (with certain liability) for such statement.

All providers based in countries with modern legal systems have to comply with the law requests. If a judge orders them to log data from some user or certain type of activity they will have to do it or face the legal consequences (which vary from country to country...) of not doing so. But they can disagree with the judge's decision and fight, though it will get to a point where either they have to help the legal system or the legal system has to prove further that they need to break the very important right to privacy in such jurisdiction.

In any case, it is likely that the VPN services are not liable for the activities of their users in many jurisdictions.That being said... they may not be liable for the past activities and they can offer no help to any law enforcement since they do not have logs, but should they get a formal request from a judge (and do not fight it in court or do so but lose) they will have to either shut down their service or do what the request says (which is likely to say which user should be monitored).


When would group permissions be a security issue?

The principle at play here is the least privilege.

A chmod permission of 600 or 700 gives only the owner rights to the file, while 660 or 770 gives the same rights to the group too.  Whether this is intended or not depends on the use case.  Either might be appropriate.

A server might - and will probably - have different categories of users (students, guests, employees, administrators ...). Keeping privileges separated is important in this case.

The possible problem with 660 and 770 is that a sysadmin might inadvertently add an extraneous user to the group in question, hereby giving the group-crashing user the same rights as the owner.

It is worth noting that nowadays group permission in Linux are obsolete (they've been replaced by ACLs), and by default an user is assigned only his/her group.


Does Google collect and store data about activity done in Incognito mode?

I think you need to distinguish between "Google" and "Chrome".
Chrome is a browser and the main feature of the Incognito mode is to delete any locally stored information from the browser session after the Incognito mode was closed. The point here is locally stored because this is all the browser can fully control.
Google is instead a company which among others things collects information about the users behavior by being included with Google Analytics or Doubleclick into many websites. This is similar how other companies like Facebook or the various ad and tracking networks are included into the websites. And this kind of data collection is also independent from the browser you use, although some browsers have special features or some extensions can be added to reduce the amount of tracking and profiling.
This remote data collection does not stop when the browser is in Incognito mode. In fact, usually these ad and tracking networks are not even aware that Incognito mode is used. What is different though is that tracking information from the "normal" mode and Incognito mode cannot be easily associated with each other, so the profiling done in Incognito mode is mostly independent from the profiling done in normal mode or from profiling done in other Incognito sessions.


How should we respond to a root CA breach?

Certificates protect against man-in-the-middle attacks, which are already pretty hard to accomplish on the open Internet. The attacker usually needs to either control a router between user and website or the DNS server used by the user. That's not something a wannabe cybercriminal can pull off from their basement. That's something which is usually done by state actors.
For most regular users it would be good enough to just let the browser vendors assess the situation and wait for them to revoke the root certificate with the next update if they deem it necessary.
But when you are working in a particularly sensitive industry targeted by highly sophisticated attackers, then you might opt to remove the CA's root certificate from your browsers certificate store yourself (how to do that depends on the web browser you are using). The result will be that any website which has a certificate issued by that certificate authority now generates a security warning. You can of course choose to ignore that warning and keep browsing it under the assumption that what you see might actually be a fake website provided by your attackers.
Also note that some websites might use certificate pinning. So your browser will remember who signed the certificate when they first saw the website and reject a certificate by a different certificate authority.


Signing but not encrypting trivial generic e-mails

If the email was addressed to a specific student, the same replay attack would be possible if you intercepted the email in transit.

The problem with this email is not the vagueness of the recipient, it's the vagueness of the content. It doesn't specify what "tomorrow" is. Would the email read "there will be no class on December 8th 2017", this "replay attack" would be foiled.

It could also be foiled if S/MIME would include the mail header with the date. There is a standardized way to do that since S/MIME 3.1 (embedding the message in another message as the message/rfc822 media type). The recipient would then see that it is an old email and that it is addressed to someone else (unless it's an email with multiple recipients). But I am not sure how well this is supported by email clients.

By the way, in my opinion it should be common etiquette in email communication to avoid relative dates for a completely different reason: you can't tell when the recipient reads your email. When the recipient reads the mail tomorrow morning and doesn't check when it was sent, then they will believe that "tomorrow" refers to what you would have considered "the day after tomorrow". This problem is amplified if you are in different timezones. Your "tomorrow morning" might be your recipients "this evening".


For what malicious activity can one use a computer with a high-end GPU?

A high-end GPU makes it very easy to do any sort of computational process that can be highly parallelized, each individual process doesn't need a lot of memory, and requires similar operations to be done to differing starting input.

So if you have md5 hashes with salts that you want to find the password that goes with, its trivial; e.g., generate a simple scheme to feed the GPU billions of passwords per second to try simultaneously and compare to the hashes you have.  You could also do things like try constructing hash rainbow tables as well.

Another good candidate would be brute-forcing decryption of a file that's encrypted with a strong cipher.  A GPU could plausibly be used to parallelize the process of doing trial decryption under many candidate passphrases.

I wouldn't say bitcoin mining is malicious; its basically the intended method of generating currency (except a GPU makes it more efficient).

Off the top of my head could also use a GPU to better crack simple CAPTCHAs using computer vision techniques.


Did ZTE put a backdoor in my router? How can I remove it?

It is likely that there is a backdoor for the devs/support (ZTE) to connect to [of course we would all like if they would stop doing this...].  As for being open to the internet that is the fault of your ISP.  They can and should lock down the device itself so that the telnet, http, https, and ssh logins are only accessible from the ISP's CPE management VLAN.  It is however sadly common for ISP's to poorly harden their CPE (customer premises equipment).

Vendor backdoors for residential routers is not a new thing:
https://w00tsec.blogspot.com/2015/11/arris-cable-modem-has-backdoor-in.html

Specifically for ZTE it is not a new thing:
https://github.com/stasinopoulos/ZTExploit/blob/master/ZTExploit_Source/ztexploit.py

Since you have access you could harden the device yourself.  But this may lock your ISP out from doing updates/troubleshooting (but they probably aren't doing updates anyway).


How secure is Microsoft-mandated UEFI Secure Boot, really?

Matthew Garrett has some nice blog posts on UEFI Secure Boot. Concerning your question he writes:

  Anyone can pay $99 and get their binaries signed. So why won't malware authors just do that? For starters, you'll need to provide some form of plausible ID for Verisign to authenticate you and hand over access. So, sure, you provide some sort of fake ID. That's the kind of thing that tends to irritate local authorities - not only are you talking about breaking into a bunch of computers, you're talking about committing the sort of crime that results in genuinely bad things happening to you if you get caught. And secondly, the only way you get access to the system is using some physical smartcards that Verisign send you. So you've also had to hand over an actual physical address, and even if you've used some sort of redirection service that's still going to make it easier to track you down. You're taking some fairly significant real-world risks.

Storing the access credentials for your key on a smartcard was the bit of new information that convinced me that UEFI Secure Boot is not only security theater. As Matthew said it makes you more traceable. It also significantly reduces the probability of theft, which would have been the smart way to get your rogue signing key in my opinion.

It is still quite probable that signed malware will pop up. But large scale attacks will be easier to mitigate, first by revoking the signing key and second by tracing the signer via his or her physical address.

The system is not perfect (and falls quite short compared to what would have been achievable) but it will make writing bootkits more difficult. And in the same way that ASLR and the NX bit make us a bit more safe against malware even though buffer overflow attacks are still viable, secure boot is not a completely waste of time.

Concerning the CRL I have heard there will be a standard UEFI interface for the OS to push new revocation lists into the bios. That will make automatic updates very convenient.


Is it legal to log passwords from failed logins?

I don’t think that “legal” is the right term to use.

It’s not wise, a lot of times “right” password is only one letter different from the “wrong” password (typo/capital letters/…).
So if somebody evil will get this log he may easily guess the correct password.

Other problem is that people re-use passwords, so they use same password for your site/gmail/facebook/bank.
So even if your site doesn’t have sensitive information about users, it’s very possible that getting user’s credentials from your site will let hacker access other user’s accounts (email/CC/bank). And you don’t want to be a source of something like that.


Is Git crowdsourcing cryptographic attacks?

Is Git crowdsourcing the production of SHA-1 preimages?  Not to any meaningful degree.

Github doesn't say how many commits it's tracking, but it's probably not more than a few billion.  For comparison, there are 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 possible SHA-1 hashes, so the odds of finding a plaintext matching an arbitrary hash of interest are effectively non-existent.


Are there any potential complications with these secure baseband ideas?

4G LTE is already encrypted:
https://security.stackexchange.com/a/21400

Doing additional application layer encryption to cut out baseband malware would involve additional layers of key exchange and transport encryption management on the phone and the tower.  This would create additional expense.

The problem is better solved by using end-to-end encrypted application protocols for communication rather than trying to add additional encryption to the largely already sufficient link layer encryption.


With regards to Chrome browser:

Self-signed certificate that is inside your trust store is OK with SHA-1.
Root cert is OK with SHA-1. (This is just repeating point 1 in other words.)
All the other certificates in the chain need to be SHA-2. SHA-1 generates a warning.

The cause for the special treatment of self-signed trusted certificates (aka root certificates) is that they are umm... self-signed, therefore what shows in their "signature" field is rather cryptographical kind of nop, than a real security device. Verifying their signature provides next to zero additional security.


Trusted (sealed) execution environment in Linux

No, this is not possible. Not in Linux and not in any other computer environment. It isn't a limitation of Linux, it's a limitation of physics.

If you run your code on someone else's computer… it's their computer, so they control what runs on it. If they have your code then they can see it run, inspect its memory, make it do different things if they like. They can run your code in a virtual machine for easier debugging. You can try to detect that but whatever you do they can bypass by giving your program the right responses, if they're sufficiently motivated.

Intel SGX works because when I buy a processor with SGX, it isn't really my computer, it remains partially Intel's computer. Intel retains control over the software that runs in the SGX enclave. You ship code encrypted and signed with a key that belongs to Intel; the SGX enclave decrypts and verifies the code with a key that's only accessible by the enclave. The enclave doesn't belong to me, it belongs to Intel, hence if you don't want your code reverse-engineered you need to trust only Intel and not me. I only get an encrypted blob from you and I can't run it elsewhere because I can't decrypt it.

You can use SGX for applications that require I/O. You just have to split your application into two parts: the trusted part that runs in SGX, and the user interface (and storage backend) part that runs outside.

Keep in mind that defenses against reverse engineering are very expensive (in terms of debugging and support costs, and also development time and performance loss). Reverse engineering and modifying a program is expensive; it's usually cheaper to pay you to do the modification than to do it and maintain it in-house.


Can any certificate be used for TLS?

No. There are certificates for example for code signing, certificates which are only used to issue other certificates, ... How a certificate can be used is defined by various parts of the certificate, i.e. mainly basic constraints, key usage and extended key usage.

For some more information see  Which key usages are required by each key exchange method?, Is the Extended Key Usage extension mandatory on the web?, TLS/SSL Certificate - Key usage and encryption, Can I use a code signing certificate as a TLS certificate?, Can I use the same ssl cert to protect my web site and sign my app?.

  What requirements should the certificate meet for TLS? SHA1/Sha2 {key specs} etc.

To be wildly accepted the key usage extension should contain at least digitalSignature and keyEncipherment, extended key usage should at least contain serverAuth. Subject alternative names should match the fully qualified domain name, it should be issued directly or indirectly (via an intermediate CA certificate) by a trusted CA, key type should be RSA (better >=2048 bit) or ECC (better >=256 bit), signature algorithm SHA-256 (or better) ... - there are probably some more restrictions in some case like use of X509 extensions for certificate transparency etc. CA's usually do the right thing so just look at the certificate you get for typical web sites.


How is it possible to poison JavaScript Array constructor and how does ECMAScript 5 prevent that?

The attack associated with poisoning the Array constructor is called JSON hijacking. It's an instance of a problem known as cross-site script inclusion (XSSI) that stems from the fact that browsers generally allow websites to include external JS files cross-origin.

Let's say, an authenticated user on your site can access some "secret tokens" at this API location:

https://yoursite.example/api/secret_tokens

And let's say the API response looks something like this:

tokens = ["secret123", "secrect456"]

This creates a vulnerability. An attacker could trivially exfiltrate the tokens of a logged-in user by sending them a link to evil.example which would have code like this:

<script src="https://yoursite.example/api/secret_tokens"></script>
<script>
    alert(tokens)
</script>

This way, the victim's browser is tricked into interpreting the  API response as an external JS file. The API is inadvertently creating valid JS code (assigning the array to a global variable tokens) and thereby leaking the tokens of a logged-in user to evil.example.

Now, let's consider the more likely case that your API response looks similar to this:

["secret123", "secret456"]

This is still valid JS code, but since it's just an expression without assignments, an attacker can't access the content of the array as easily as above. The workaround here was to simply override the Array constructor:

Array = function() { foo = this; }

This particular trick was reported and fixed in Firefox in 2007 but since then, other techniques, e.g. employing Object.__defineSetter__ or Object.defineProperty, have been found (and fixed).

  How does EMCAScript 5 prevent that?

The ES5 specification demands that [] always uses the built-in Array constructor (and the same applies to object constructors):

  15.4.1.1 Array ( [ item1 [ , item2 [ , … ] ] ] )

  Create and return a new Array object exactly as if the standard built-in constructor Array was used in a new expression with the same arguments (15.4.2).

Finally, let's consider the case that the API replies with a JSON object:

{"tokens": ["secret123", "secret456"]}

The simple reason why has never been vulnerable is that it's invalid JS: An isolated object in curly braces is parsed as a block instead of an object. So you can't include this JSON object as an external script without triggering an error. Historically, triggering a syntax error has been a convenient way to prevent XSSI attacks.

Here are some additional references to JSON Hijacking:

Anatomy of a Subtle JSON Vulnerability
JSON Hijacking


RAR uses AES256 for encryptionsource, thus the question is whether AES is cryptographically resistant to a known-plaintext attack.

At present there is no known method that allows retrieving AES encryption key given unlimited number of plaintext inputs and corresponding outputs faster than brute-force. Although there is no proof that it is impossible.

See related posts on Cryptography SE.


Security configurations to protect against 0-day exploits?

Unfortunately, the risk with 0-day attacks is that you don't know what they can do or what they will do. Even if you have an up-to-date operating system, firewall, antivirus, and even full-disk encryption, a fault in any of these could potentially give an attacker access to your system and your data.

With that in mind, discovering 0-days is always a race between the good guys and the bad guys. The bad guys want to find vulnerabilities and exploit them, while the good guys work to patch any suspected vulnerabilities through constant code reviews, audits, and penetration tests.

One argument that could be made is that software released from trusted vendors like Microsoft, Apple, or Google is that, because they have obscene amounts of money to throw at security, their software is much less likely to have vulnerabilities than the average third-party application. And even if a malicious hacker finds a vulnerability in the software, it still takes time to conduct research and develop an exploit that can target computers on a large scale, giving security researchers more time to find and fix the issue.

But ultimately, the fact is that no computer is 100% secure, and Murphy's law holds true. Anything that can go wrong will go wrong.

If this is a matter of secure storage, then there is something to be said about encrypting data and keeping offsite encrypted backups, without an internet connection with which hackers could use to exploit a system and get to the potentially encrypted data. Or there are always type-writers and safes. But conventional software and IT security can only go so far, especially when dealing with the unknown.

Realistically though, the majority of viruses are going to target old, unpatched machines with no firewall. Unless hackers are specifically targeting  a victim's machine, it is much more likely that they will go after the thousands if not millions of unpatched and vulnerable computers out there. And if they are directly targeting the victim, there are other ways of getting information out of them: https://xkcd.com/538/


Yes. That code is wrong.
The test should only use the timed function:
if(!crypto.timingSafeEqual(password, allowedPassword))

Clearly some people do not understand the code they write.
But you'd only be able to determine the length of the password. Hopefully, your's pretty long... He! He!


If I am obliged to store a password/certificate on a client side, how can i make sure that it is protected?

Considering your comment up top, I would say that while this is possible, it is quite complicated with numerous likely pitfalls.

Though it is not yet so common, I would strongly recommend you look into CardSpace (nee InfoCard). Basically this provides a very secure implementation of what you're looking for, and additional benefits (e.g. the user has more control of what information is sent to whom). Of course it is not without tradeoffs, e.g. users are less familiar with it, and it's a bit complex to implement...


Is a VPN anonymous enough or do I also need to use TOR?

In general I'd say you need to do more than just use a VPN.

What VPNs do:

VPNs solve a couple of fairly specific problems:

Your local ISP (Internet Service Provider) and network provider can see all your unencrypted traffic. This could be groups like your school, work place or whoever is running the WiFi[1] at your local cafe. A VPN encrypts all the data between you and the VPN end point so it solves this problem.
When you connect to a website they can see your IP address, often all the computers on a network will use NAT (Network Address Translation) to share a single public IP address. So if your laptop, PC and Mobile are all connected to your WiFi they will most likely share a single public IP address that could be used to track you[2]. When your trafic goes through a VPN the website will see the IP address of the VPN instead of your home[3].

What VPNs don't do:

While a VPN will encrypt your traffic and hide your IP address the main way people are tracked online today is through cookies in their web browser.

Companies like Google and Facebook will places a tracking token in your browser that is sent back and forward between you and them every time you view a page that has Google Ads or Facebook Like buttons.

Ways around this involve things like Private Browsing mode in Firefox, privacybadger, Do Not Track and tools like NoScript or just clearing your cookies and cache regularly.

However tools like that don't hide your IP Address or encrypt your traffic, so they can be complimented nicely by using a VPN.

How to browse anonymously

With a combination of a VPN and selection of privacy tools it's possible to remain repetitively anonymous[4] online.

However rolling your own solution is hard, and it's easy to make mistakes where a single mistake can undo all of your effort.

If you want serious anonymity online I highly recommend checking out Tails it's a pre-built Live Operating System bundled with everything you need.

[1] Or if someone malicious is monitoring the traffic on that WiFi or network.

[2] There are large database that map IP adresses to approximate physical locations.

[3] or whatever network your on at the moment.

[4] Here I'm thinking for average people not nation state actors like the NSA.


How does a browser stop malware from executing?

Is it the various protocols like HTML and so on that don't support these security-related actions?

Since it is at the end the browser which downloads the content and interprets the content (including the HTML), it is also the browser which decides what the content is allowed to do. On top of this modern browsers have a robust security architecture with sandboxes which prevent most attacks even if the attacker could exploit bugs in the browser.

...  i.e. a malicious dev could release a fork of Chromium which just accepts binaries to run them and could read all files the current user has access to?

There is noting inherently magic in handling content from the internet, which might prevent an arbitrary program from interpreting it in a malicious way. Thus  it is of possible to create a browser which does not have any security protection. One might even create a browser which already has a back door or similar already built in, i.e. no download of additional content needed.
And this problem is not restricted to browsers. That's why it is important to not just install arbitrary software from the internet, no matter if it is claimed to be useful, secure, profitable or whatever.


Implementation of diceware: do I have to simulate dice roll?

The reason Diceware advocates using dice to select a password is that it ensures the password the user gets is generated randomly. So no, as long as you are certain your program is selecting the password in an unpredictable (cryptographically secure random selection with a uniform distribution) manner, it doesn't matter how the password is actually generated.

There are other reasons for using dice that are impossible to replicate in any program:

It's completely transparent to the user. They don't have to trust a computer program to use an appropriate cryptographically random number generator or to not leak their password to malicious actors.
100% malware-proof. Unless you have a webcam pointed at your table while you're rolling the dice, it's physically impossible for a malicious program on your PC to observe or influence the password you're generating.

Unless your users are particularly paranoid though, there's a good chance they'll be okay with forgoing these benefits in favor of the added convenience of generating a new password instantly.


sqlmap -u "http://vuln.url/x.php?param1=..."

You can add --dbms parameter like --dbms=myqsl if you're sure about the database used or --forms to inject the form in the page.


What attack modes does a VPN secure against over https?

If all you do is surfing the web and all the surfing you do is already protected with https and you only care about encrypting the traffic but don't care that somebody might see which sites you visit and when and if you can be sure that your https is not intercepted by some local antivirus, local malware/adware or some enterprise firewall or you don't care, then it is enough to use https.

If any of these conditions are not met a VPN might make sense depending on what you do. And note that a VPN is no replacement for https: https provides end to end protection while VPN offers no protection after the traffic leaves the VPN endpoint which is usually not the endpoint of the connection.


In what scenarios is relying on source IP address as a security control acceptable/unacceptable?

One thing I've noticed is that the idea of "spoofing" the source IP address gets brought up but people rarely go into detail about how challenging that might be in practice (eg, accurately guessing TCP sequence numbers), so I'd be interested in any opinions about the practicality of spoofing IP addresses with common application protocol such as HTTP.

A fair point which earns my +1.

If you're after hijacking an existing connection given you know for arguments' sake that 256.0.0.1 (deliberately not real) is on the whitelist is fairly tough, as you state.

I think we reach for IP spoofing as the most obvious threat, like with the idea that all hackers are "leet", use tiling window managers and have transparent terminals. However, there are some more obvious problems:

What happens if another computer acquires that IP address? If you use IP address based restrictions alone, then it becomes a problem.
What happens if that computer becomes compromised? Again, a problem if you use IP address filtering alone.
What happens when you have NAT and no access to the source IP address?

In other words, the problem is that whilst this might restrict access, it does nothing to check authorisation. Like a stateless firewall, which assumes everyone on this private subnet is good. That's all very well, but did you authorise their access? If they can acquire, by any means, an IP address in the right range, you're going to hand them trust.

By contrast, if you use some form of authentication layer, you make it harder for the would be attacker to gain access where they are not authorised.

A better solution in my mind is to use the likes of IPtables to mark certain interfaces as having access to more or fewer services. This is then tied to the physical network, which is much harder for an external (or even internal) attacker to manipulate. You still, however, need authentication on top of that.


The same origin policy does not prevent all authenticated cross site interactions. Specifically, cross origin writes and embeds are generally allowed, while reads are prevented:

  Cross-origin writes are typically allowed. Examples are links, redirects, and form submissions.
  Cross-origin embedding is typically allowed.
  Cross-origin reads are typically disallowed, but read access is often leaked by embedding.

Many of the allowed cases are important for the web to function properly.

Chrome will still soon change to a default samesite=lax, which will eg prevent cross-site POST requests with cookies (and also most embeds such as images or iframes).

It will however not prevent other "write" type actions such as visiting links. So GET-based CSRF remains an option even with samesite=lax (not with samesite=strict though).

Because of this - and because you should not rely on the client having additional security features (users may eg use other browsers than Chrome), CSRF prevention is still necessary to be employed by each site (using samesite=strict may be used as CSRF prevention, though it may break if the site allows users to post/control a sub-set of HTML such as links, forms, images, etc, or if it has other vulnerabilities such as open redirects).


How can PayPal spoof emails so easily to say it comes from someone else?

Here is a dramatization of how the communication goes, when a mail is received anywhere.

Context: an e-mail server, alone in a bay, somewhere in Moscow. The server just sits there idly, with an expression of expectancy.

Server:
Ah, long are the days of my servitude,
That shall be spent in ever solitude,
'Ere comes hailing from the outer rings
The swift bearer of external tidings.

A connection is opened.

Server:
An incoming client ! Perchance a mail
To my guardianship shall be entrusted
That I may convey as the fairest steed
And to the recipient bring the full tale.

220 mailserver.kremlin.ru ESMTP Postfix (Ubuntu)

Welcome to my realm, net wanderer,
Learn that I am a mighty mail server.
How will you in this day be addressed
Shall the need rise, for your name to be guessed ?

Client:

HELO whitehouse.gov

Hail to thee, keeper of the networking,
Know that I am spawned from the pale building.

Server:

250 mailserver.kremlin.ru

The incoming IP address resolves through the DNS to "nastyhackerz.cn".

Noble envoy, I am yours to command,
Even though your voice comes from the hot plains
Of the land beyond the Asian mountains,
I will comply to your flimsiest demand.

Client:

MAIL FROM: barack.obama@whitehouse.gov
RCPT TO: vladimir.putin@kremlin.ru
Subject: biggest bomb

I challenge you to a contest of the biggest nuclear missile,
you pathetic dummy ! First Oussama, then the Commies !
.

Here is my message, for you to send,
And faithfully transmit on the ether;
Mind the addresses, and name of sender
That shall be displayed at the other end.

Server:

250 Ok

So it was written, so it shall be done.
The message is sent, and to Russia gone.

The server sends the email as is, adding only a "Received:" header to mark the name which the client gave in its first command. Then Third World War begins. The End.

Commentary: there's no security whatsoever in email. All the sender and receiver names are indicative and there is no reliable way to detect spoofing (otherwise there would me much fewer spams).


Security issue with form action $_SERVER['PHP_SELF']

Think about the following:

    http://www.example.com/foo.php/">script>alert('hello');/script>

It will still load your page but also include it within the output as well.

    form method="POST" action="/foo.php/">alert('hello');/script>">

    /form>


Quite a few specific questions here, I'll break it down

  What is stopping an attacker from disabling the TPM until after boot?

Nothing if the attacker controls both the FW (UEFI, BIOS, etc) and the boot code.  I say the boot code because at some point near the end of the boot, the TPM would need to be initialized and put in the right run-level so the OS doesn't detect anything out of place.  You can't just turn it off, because user/OS applications expect it to be in a certain state and that would blow your cover, if you are the hacker >:)

You have to trust your UEFI/BIOS.  Did you accidently flash some hacker sh*t to your motherboard?  That's the only way this would work.  Don't do that.

  Then extending the PCRs with whatever he wants

Because of how PCRs work, this is "impossible".  You cannot update PCR's to arbitrary values, you have to hash things in the exact same order each time -> impossible to crack.

But you already know this, though, you mentioned the "extend" operation yourself. PCRs are not "written", they are "extended". For some good info on that, see here on http://opensecuritytraining.info/.  A quote from that presentation:

Digging a Little Deeper: PCR Extend
....
Computationally infeasible to forge (must break SHA-1)
    Given PCR state N and desired state M, adversary would need to find
    X such that hash(X,N)=M; violates one-way assumption

  and even recording the input to the extend function of PRC in the authentic boot chain

That's pretty darn smart, but how would this be done?  Physical probes on the bus?  Totally possible!!  But now we've gone beyond the TCG TPM specification, which specifically does not protect against physical tampering, AFAIK.  It does provide physical tampering evidence but does not protect against someone taking a trace on the pins.

  an attacker can try using the TPM on another system which will also send fake inputs to the PCRs at boot time?

Can you elaborate on how this would work?  But no, you couldn't remotely use another TPM without software to expose it to a service.  Doable in the OS, but if you could forge PCRs on the remote machine you can forge them here.

Again, you can't just put "fake inputs" into the PCRs, it doesn't work like that.


Does "=cmd" CSV injection still exist in 2020?

Finally found the reason why the payload were not executing: DDE launch was disabled in Excel options.

If someone has the same issue, this setting can be found in

File → Options → Trust Center → Trust Center Settings → External Content → Enable Dynamic Data Exchange Server Launch

Reference https://docs.microsoft.com/en-us/office365/troubleshoot/security/security-settings


Why is Windows password security designed this way?

Well, first off with LanMan you have to remember that it was designed and implemented in a very, very different security context than we're facing today, or even than we were facing when NTLM & NTML v.2 were designed and implemented.  It's probably going a little far to say that Microsoft--really, the tech industry in general--didn't care much at all about security back in the mid 1990s when LanMan was introduced. But as a concern and a priority it was a very, very different time. Windows didn't even have a multi-user model back then. Or administrator vs. user account privilege levels. Or interface with any kind of Windows Server network with anything like any Active Directory/ enterprise grade authentication/identity system.  It's sort of like the question of why the earliest versions of Internet Explorer and Netscape Navigator had almost no security protections whatsoever compared to the major browsers today.  Different circumstances, different threat environment, different level of technological knowledge about how to build more secure system elements.

Regarding NTLM (and even NTLM v.2), yeah that's a bit harder to absolve Microsoft of. Was NTML a considerable advance over what come before it? As you point out, absolutely. Has Microsoft tried to move away from NTLM via emphasizing using Kerberos authentication as a much more secure model (at least where Kerberos is used)? Yes. But has Microsoft propagated unsecure practices by continuing to rely on NTLM v.2 in the many situations that Kerberos doesn't cover? Given the weaknesses in the NTLM approach that you talk about, I think the answer to that has to be "Yes".

Why is NTLM still in use? Why hasn't Microsoft replaced it with something more robust to cover circumstances where Kerberos isn't used?  Here we're getting more fully into speculation territory. But if I had to speculate, I would say that (1) one has to remember how intensively Microsoft has historically been committed to backwards compatibility, especially in the networking and authentication areas; and (2) there actually is a pretty good question about how much extra security that an NTLM replacement would really provide. As you pointed out, NTLM has plenty of problems in terms of its resistance to cracking the hash, but most Windows authentication bypasses aren't accomplished by stealing an NTLM hash and cracking it to gain the cleartext password. Instead, attackers often take the easier ways of (a) passing the hash, if we're talking about non-Kerberos authentication to a network, or (b) just resetting an administrator password via command line in the recovery environment if you have local access to a machine. Considering those points, and that the only really secure way of locking down the contents of your PC against a local attacker--full disk encryption with Bitlocker, with TPM unlock--has nothing to do with NTLM, one can argue that replacing NTML v.2 with some kind of modern,much harder "NTLM v.3" (or whatever you might call it) would do less good than one might think.

(Still, I do have to agree with your sentiment. In my view, it's something Microsoft should have done. In the Windows Vista or Windows 7 eras.)

All of the above being said, I do think that with Windows 10 Microsoft has actually begun to make some first major steps toward finally getting away from NTLM--and password hashes vulnerable to theft/passing/cracking altogether, actually. Credential Guard is designed to use a virtualized secure area to safeguard authentication info--starting with password hashes--against theft or cracking even if the main OS kernel is fully compromised. The combination of Passport and Windows Hello is designed to do away with password hash based-authentication altogether: entering a password, PIN, and/or using biometric authentication just unlocks a private key for use to sign an authentication ticket in a secure part of the OS, which is then sent to the remote server. (Or, at least, that's the way things will supposedly work when all the promised Passport and Credential Guard capabilities are actually,finally delivered into Windows 10. Right now the functionality of those elements are only partially in the OS and/or enabled.)

So, change is coming. Sort-of. Slowly.


How does the optional "e-mail password reset" at sync.com work?

This is the official answer that I received from sync.com. So, as suspected, the promise of zero-knowledge only holds when this option is not enabled.

  Temporary means that your keys are briefly exposed to automated
  systems (not people).

  With the feature enabled, we store a backup key in escrow (on a
  separate offsite "cold server", not accessible from the public
  Internet or by Sync employees). The backup key can be used to reset
  your password, but not directly access your files.

  The password reset feature itself can only be enabled or disabled by
  you (technically we are unable to do so because enabling the feature
  requires your current password).

  We provide this feature because many industries require an email-based
  password reset feature for compliance purposes.

  For example, in some countries, legal firms that store client data in
  the cloud must be able to recover their data at all times, even in the
  event that they have lost their password and do not have the Sync
  desktop app installed (in which case they would be permanently locked
  out of their account).

  As long as you have the Sync desktop app installed, you do not need to
  enable this feature as the desktop app also provides a password reset
  mechanism that is fully zero-knowledge


SSO via HMAC and shared key. Can this be improved?

The MAC is the right tool here, and HMAC/SHA-256 is fine. Using a 5-second tolerance might be a bit optimistic:

You have to make sure that both servers have accurate clocks; use NTP. Also, make sure that you use a well-defined representation, i.e. something in UTC (otherwise, you'll run into trouble with Daylight Saving Time).
The "5-second delay" must be enough to accommodate the round trip: server A sends the "redirect" response to the client, then the client connects to B and sends the request. If the client is in adverse conditions (e.g. a client using a laptop in a train), network can be unavailable for a few seconds at a time.

Replay attacks from outsiders are prevented by SSL; the inclusion of the time stamp is to defeat replay attacks by the user himself. If server B requires a time stamp no older than n seconds, then this implies that if you block access to the user on A, then the user may still talk to B for n seconds. You can probably tolerate a longer n; personally, I'd use a 5 minutes delay. Another way to look at it is the following: if, once authentication was performed, B allows successive requests within a given time frame T, e.g. with a cookie-based session management and the session expires after T seconds, then it makes relatively little sense to use a n much shorter than T.

Note that an evil user may want to fake NTP packets in order to make server B's clock go back to the past, in order to reuse an old authentication URL with a long-expired MAC. NTP packets are not authenticated. A normal NTP client will not accept to alter its clock by considerable amounts even if a NTP server claims that it is off by several weeks; however, a boot-time ntpdate call may be theoretically abused. I have not observed this attack in practice.

Suggestions for improvements:

You may want to include an identifiers for A and B (e.g. server names) in the redirect URL, and as part of the MAC input. This keeps track of who is doing the authentication+authorization, and for what server the user is authorized. This is more flexible if you want to later expand the system with several distinct A and B servers.
You can replace the MAC by a digital signature (RSA, DSA...): server A owns the private key and uses it to sign; server B uses A's public key to verify signatures. This avoids sharing a secret between A and B (the more a secret is shared, the less secret it becomes).


Open your browser and navigate to the link below and check the IP returned before and after enabling your VPN software. You should see your VPN provider's IP when VPN is enabled to route your stuff via VPN provider's server. Otherwise, you'd see your hotel wifi provider's IP.
https://ifconfig.me/ip
Update:
As you know, the above check verifies if your browser is going through the VPN tunnel or not. So if all you care about is your browser traffic, this check is good enough. However, if you want to absolutely make sure all your traffic is routed through your VPN server, you can check your kernel routing table to make sure it is setup correctly by your VPN software which I am pretty sure is done correctly.
The following list is part of my kernel routing table. As you can see, my VPN inserted routes to override the 'default' route which is on my physical interface (i.e. en1) to VPN tunnel interface (i.e. utun2). As long as you see similar things on your machine you can be sure all your stuff is going through your VPN tunnel. I do not know what OS you are on but the following check can be done on MacOS or Linux and I assume Windows has similar tools. Open a command shell and do the following.
arul@lion$ ip route list
0.0.0.0/1 via 10.8.0.1 dev utun2
default via 192.168.1.1 dev en1
128.0.0.0/1 via 10.8.0.1 dev utun2
...

You can also do the following additional check that tells you how your connection will be routed. In this example, it tells me it would use my utun2 device to get to a public IP i.e. 8.8.8.8
arul@lion$ ip route get 8.8.8.8
8.8.8.8 via 10.8.0.1 dev utun2  src 10.8.0.75

Finally, you want to absolutely make sure you are only using VPN tunnel, you can delete the default route which I am pretty sure is how your VPN software implemented their 'Kill switch'.


Securing Diskless Clients from Data Leakage

For RHEL, you should be able to create a custom kernel with support for SATA/ATA and USB mass storage disabled.  If the kernel won't recognize the devices, the user can't access them.


Verify the password of an encrypted file without waiting for complete decryption

I want the user to see whether the password is wrong before the file is decrypted.

Decryption does not tell you whether the password was correct. If you supply the wrong password, you will get a decrypted result. A wrong one, but how do you know?

Usually the data that you encrypt has some structure that's known in advance. Say, it's a text file, and it must contain only printable characters. Or it's a video file and must begin with a well-formed MPEG header. If the password is accidentally wrong, then the probability that the output still has this structure is negligible. In most cases the first few decrypted bytes will give away whether the output is well-formed, and therefore whether the password is correct. But it's difficult for your application to tell — whether it performs that verification after decrypting the first few bytes or after decrypting everything — unless the application is specialized to a specific file format.

So what you can do is to start your plaintext with a known header, something like Elefantosque's exercise in password-protected encryption. If the first few decrypted bytes are correct, then you know the password is correct. The length of the header is determined by the strengh of your encryption; it should be at least the length of the secret key (i.e. 32 bytes here).

Incidentally, if your decrypting application can tell whether the output is correct in some generic way, then it is doing more than encryption: it is also verifying the integrity of its input. AES doesn't do this (it can if used in particular modes). So either your application is performing some other cryptographic verification of the data which you aren't telling us about, or your application is not really verifying integrity, and in particular does not detect a wrong password.

If you use the known header method above, then your application will detect a wrong password by verifying the integrity of the header (here, the integrity check is that the header must be equal to a known value). Note that you will still not be verifying the integrity of the data.

If you're worried about an attacker modifying the data in transit, then what you need is either some form of authenticated encryption in a single algorithm (which can be an AES chaining mode), or to combine encryption with authentication through a MAC (encrypt-then-MAC or MAC-then-encrypt).

Another thing that you aren't saying is how the use of AES relates to the supplied password. An AES-256 key normally consists of 256 bits which must be wholly unknown to the attacker (randomly generated over the whole key space). A password is a string, usually chosen by a human, which may have constraints to consist only of printable characters, have minimum length requirements and so on. Making an AES key out of a password is a non-trivial operation, and the way you do it is critical to your application (or rather your protocol)'s security.

An acceptable way to make an AES key from a password is key stretching and salting. The problem with passwords is that an attacker can often crack them by brute force. It doesn't matter how your password is used, if the attacker knows that it's one of password, 1234 or l33t, then the attacker can try all three possibilities. The most you can hope for (in a scenario like yours) is to make it expensive for the attacker to try many possibilities. A good stretching function takes a long time to compute. For legitimate uses, you only perform the function once, so the cost doesn't matter, whereas the attacker's cost is multiplied by the number of attempts he performs. As for salting, it lessens the amount of reuse for an attacker who wants to crack multiple encrypted files. Salting means including a random component (stored in plaintext) in the stretched data. As the salt is different for every file, the attacker cannot precompute a list of stretched keys derived from common passwords.

As a more general note, you seem to have a lopsided view of security (don't worry, it's common with beginners). You're putting a lot of importance on the choice of algorithm (AES-256, dismissing SHA-1), and none at all to other parts that matter, such as what makes you conclude that a password is correct or how you use the password in your scheme. In fact, finding weaknesses in a commonly-used cryptographic algorithm is very rare (especially practical weaknesses) compared to finding vulnerabilities in protocols, i.e. in the way the information flows and the algorithms are used. Cryptographic algorithms are hard to design, but a few of them suffice for most purposes and you don't need to understand why they work (or even how, really) to use them. Protocols are hard to design as well, and they are often application-specific, at least in part; so you need to pay a lot of attention to your protocol design. Reuse existing protocols whenever possible (but be careful that you're using them correctly!), and tread carefully when you need to design one. Again, you can bet your application will break because of a broken protocol (or a broken implementation, if you aren't a careful implementer), not because of a broken cryptographic algorithm.

As a matter of fact, there's no good reason not to use AES-128. It would cut down on the decryption time and not perceptibly reduce security. The use of SHA-1 has indeed not been recommended for a long time, though the attacks that were feared took longer to arrive than predicted. Still, SHA-1 is not broken for the purpose that would have mattered here, namely reversing a hash (the known weaknesses have to do with collisions, i.e. finding data with the same hash as some known data). Nonetheless SHA-256 is recommended where the design calls for a cryptographic digest.

P.S. I'm assuming this is a learning exercise. Obviously, for real-world use, you would use existing, well-reviewed software such as PGP/GPG.


"Yea, I can hear them" I just heard this from my computer speakers

Install Little Snitch for Mac and reboot. You can use the filter to limit external communications to just those that you explicitly authorize. If it's an ongoing thing, just disconnect for a while to see if it persists.

If you're really worried about it and don't want to monitor network connections, you could always block the microphone. On my MacBook, I used a few layers of electrical tape to cover the microphone (didn't fall off until a while after I stopped being paranoid). To find the microphone(s) on your machine, you can open QuickTime Player, click File > New Audio Recording, turn the volume up, and tap around the chassis. Use headphones to eliminate reverb loops while testing.

Really doubt an eavesdropper would use a two-way stream.


Heartbleed check for mobile and mobile apps

Heartbleed is a bug with the 'heartbeat' function within vulnerable versions of SSL. That's why the name 'heartbleed'. Your check is saying that your version is vulnerable, but the heartbeat function is not enabled.


I think the question is "how such a spoofing possible"? It's not a question how a domain owner protects it, because you can't control the whole web. The spoof IS a kind of lie, so EVERYTHING is possible here. The purpose is to shock you, so if you will see a BBC or CNN domains under this XXX videos - feel no surprise.


Is it secure to reuse CSRF token from existing cookie (for a new tab in browser)?

It sounds like this might lead to a form of session fixation, possibly preventing the system from ever re-issuing a new token by always making sure the cookie has one. The exploit vector for this might be a MiTM attack. Nevertheless, double-submit cookies are already somewhat vulnerable to MiTM attacks if not done properly.

Generally, with double-submitted cookies you don't need to change the cookie token for each request, just once per session.

If you need more strict protection, have long-lasting sessions, or multiple distinct sessions, you should look at using the synchronizer pattern.


How can my bank issue a new credit card with the same pin number?

Chip and pin (EMV) credit cards support online PIN verification, which means the PIN has to be stored somewhere (I don't know whether it's at a central location controlled by VISA/MasterCard or at the bank), I assume its hash is stored securely as VISA/MC are usually pretty up to date in terms of security, though it's still very easy to bruteforce a 4-digit PIN even when salted,

Now what I suspect is actually happening is that your bank also keeps the PINs on their side in encrypted format, though it's still reversible and someone working there will have no problems getting it out. Depending on the system on which they're actually stored, getting it out would be logged, but the encryption itself is still reversible.


How spf records prevents the server from attackers?

They don't. They allow the recipient of the mail to detect spoofed mails but they don't prevent attacks against the server.

  How to set an spf record for my website. (Any links pointing to securely set an spf record may be useful)

Add a TXT or SPF DNS record for your domain. How this is done depends on the way you can configure DNS for your domain. There are several resources online which help you to create a proper SPF record, just google for spf wizard.

  Is there a significant difference between using - instead of ~.

Yes there is. And it is documented also in the extensive Wikipedia entry. In short: - causes a hard fail where the recipient should not accept the mail, while ~ is only soft fail where the recipient should accept the mail but might increase the spam level.

  Can spf records actually prevent attackers from spoofing my mail server.

They can help a lot especially if strict settings are used (i.e. fail not soft fail). But they must be checked by the receiving mail server, because the recipient itself can not reliably know the senders IP address which is necessary to check the SPF record. With DKIM instead the senders MTA signs the mail (or parts of it) and this signature can be verified by the recipient.


You wouldn't be able to name a file ../test.txt as no filesystem (that I'm aware of) allows forward slashes within the filename.  (Certainly all POSIX filesystems do not.)

That being said, for an attacker, it doesn't matter.  The filename is sent as part of the HTTP POST data, which is of course subject to tampering by an attacker:

--------------------------d74596066958873e
Content-Disposition: form-data; name="formfield"; filename="file.txt"
Content-Type: text/plain

filecontents
--------------------------d74596066958873e

So an attacker can easily specify something other than "file.txt" for the filename field.  Whether your application server or application code will accept a filename containing is what will determine if you are vulnerable to a directory traversal via the filename.


Server echoes HTTP headers back to client - any security issues with that?

There is a vulnerability called HTTP Response Splitting  that may be exploitable, depending on whether newline characters are filtered out.


There are a number of providers available for this. You want to make sure that the provider you select has built in encryption options for which you can maintain the key. The below providers all support this.

Crashplan
BackBlaze

Remember that you need configure the software to use an encryption key you have generated yourself and keep this secure and safe. If you lose this key your backups are gone. It might be a good idea to invest in a safe deposit box or a fire proof safe.


AH includes the outer IP header in the HMAC calculation which is why NAT breaks it. My understanding was that NAT-T was never expanded to support AH because NAT breaks the outer IP header protection.

http://www.ietf.org/rfc/rfc3948.txt
"Because the protection of the outer IP addresses in IPsec AH is inherently incompatible with NAT, the IPsec AH was left out of the scope of this protocol specification."


Is opening all ports on a router safe if it is simply redirection to a VPN server at 192.168.1.2:51820?

Open ports in themselves do not pose a greater risk than closed ports. In order to exploit a security gap, the service behind the port must always be vulnerable. Conversely, this means that if your VPN service is always kept up to date and it does not pose a security risk, the open ports will not do it as long as there is no vulnerable service running
DoS/DDoS is not necessarily a problem of ports; closed ports can also be attack vectors for it. Since packets destined for your host still have to be validated by the Kernel/Network Stack and therefore your machine has to process these requests.
Measures against this could, for example, be a firewall that drops packets before they even reach your machine