It is possible to decrypt HTTPS traffic when a man in the middle proxy is already in place?

EDIT : If the proxy SSL certificates are already installed on the user computer then yes absolutely and here's the right answer. Otherwise keep reading...

Yes and no.

No because by replacing the SSL certificate of the server by your own, the user's browser will raise a big scary warning that the certificate is invalid and will warn the user that he should not proceed.

Yes because if the user still decide to proceed and accept the false certificate, then you will be able to decrypt everything since it was encrypted with your certificate.

Alternatives

If you are able to install your certificate directly on the user computer, then his browser will not raise any warning and you can decrypt everything. Check this link
Just replace the https by http. Most users don't take the time to check that it's really https so it's a very effective MitM attack.
Get a real certificate for a url that is similar to the url you are targeting.


How to get JS content fron XSSI vulnerability?

For a successful cross-site script inclusion attack you'd have to bypass this origin check:

if (window.location.hostname === 'Demo.site.com')

That isn't possible because modern browsers don't allow you to override window.location, as explained here and here. The hostname property is read-only for security reasons. This means that only Demo.site.com can access the IWANT-THIS-SECRET token by executing the JS file.

In older browsers, a redefinition of the property could have looked like this:

window.__defineGetter__("location", function(){
    return { hostname: "attacker.exmaple" }
});

But if you attempt that, you'll get an error message. E.g., for Firefox:

TypeError: can't redefine non-configurable property "location"

If you were able to bypass the origin check, a simple XSSI attack could then work like this:

<script>
function updateLoginHeader() {
    alert(arguments[1]);
}
</script>
<script src="https://targetsite.example/Dinamic.js"></script>

As you can see, you just have to define your own function that captures the "secret" function argument. (Your attempt to redefine Array looks more like an approach to JSON hijacking which isn't helpful here and would also generally be unsuccessful in any modern browser.)


What's the point of spam posts where the link is too small to be visible?

Increase site ranking

When search engines parse pages (Googlebot for example), they look for backlinks in order to try  to determine the popularity of a website.

The more backlinks go toward a website, the better search engines will rank it and the higher it will get in search result.

Decrease competitor site ranking

It's also possible that the attacker might be a competitor and try to decrease the ranking of a website (the forum here). In order to do this, attackers plant backlink in competitor website that links to porn, illegal good and services or untrusted website. There are then good chances that this will decrease the rank of the website.

You might find more informations about it by researching about Black Hat SEO


According to the documentation found here
This warning is raised because you're passing a variable into the Paths.get function. It could lead to overwriting of files you didn't intend.
In fact, I believe your mitigation technique would only serve to help an attacker because you'd only be allowing them to overwrite files that exist.
The documentation says:

Bug Pattern: PATH_TRAVERSAL_OUT
A file is opened to write to its
contents. The filename comes from an input parameter. If an unfiltered
parameter is passed to this file API, files at an arbitrary filesystem
location could be modified.
This rule identifies potential path
traversal vulnerabilities. In many cases, the constructed file path
cannot be controlled by the user. If that is the case, the reported
instance is a false positive.

If I were you I would look at rearchitecting this. Do you really need to pass in the path or can it be hardcoded to some constant value?
You may want to reconsider all angles of attack on this.


Is this a good enough approach to securing a RESTful API?

The way I want to generate tokens is this : SHA256 hashes of 3 randomly generated strings (characters - [0-9,a-z,A-Z]), concatenated.

There is no point in hashing random data.

Avoid use of the default random functions as those are insecure. Use a Cryptographically Secure PSRNG to generate the random data. For example, on UNIX-like systems you can read the data out of /dev/urandom. I expect PHP has a platform-independent documented way to create Cryptographically Secure random data.

The token should have 72 bits of entropy or more.

  I would store this token in a database table along with the username and the login time.

As you may know, you should never store user passwords, but use a Slow Hash such as bcrypt.

Similarly, for session tokens, you should not store those either, but use a Fast Hash for these. So your database should store an SHA-256 hash of the token. Avoiding storage of the original token is helpful for certain key management schemes or edge case attacks (i.e. limited SQLi) that you may have down the road.

  When an API request is made with this token, I would be able to get the user from the token.

Sounds good.

  I want to implement all of this in PHP.

These concepts are language agnostic. :-)

You should absolutely make sure you are using HTTPS/TLS to encrypt the connection and verify the server's identity before sending any sensitive authentication details such as passwords or session tokens.

I would recommend you also check that the IP address matches what it was when the user first signed in. If the IP address changes during the session, that may be a clue that the token was stolen.

Unfortunately mobile phone users, and users in certain foreign countries have frequently changing IP addresses, so such a restriction would not work for them.


forwarding company email to a contractor's email address

Not certain about blocking login but I think you can - I'm fairly sure there is a setting in AD that blocks login but whether that has other impacts, I don't know.

In regard to data sharing...

You should, at a minimum, have a data sharing contract between you and the contractor so that you can legally hold them to account.

If you need to keep tighter control on the information, you should restrict them to using your own mail system. Remember that, once the data leaves your email system, you have little control over the channels it goes over nor control over whether those channels are secure.

Ultimately, this will come down to a balance between cost, convenience and security and you need to understand both the risks and the impacts before you can make a sensible decision. If you work in a regulated industry or are a high-risk organisation then the risks and impacts are much higher and you should almost certainly be using only your internal system and be restricting to controlled devices. At the other end of the scale, you may see little impact at losing data occasionally or little risk that someone might be interested enough to try intercepting data and in that case, you wouldn't bother.


An interface is a property of the current system and not a property of the transferred data. Therefore there are no information in the packet which allow to specify the interface which should be used by the receiver or which should be shown as used by the receiver (i.e. different interface shown as actually used).
This does not mean though that an attacker could not indirectly cause malicious traffic originating at the loopback interface. For example an external web page loaded inside the browser on a machine is able to create network connections to 127.0.0.1 or ::1, which then originate at the loopback interface.


The contents of a Web page do not necessarily come from a single server. Web page from www.example.com contains a link  which your browser will dutifully follow. That secondary server stores a cookie in your browser stating "I have been through www.example.com".

Later, you visit www.sample.org which contains a link . Your browser also follows that link, and since it is for the same server than previously (ad.server.elsewhere.com), the browser sends the previously stored cookie. Boom ! You've been tracked.

Happens every day. Happens right now. Happy Web surfing !


How does encryption strength make a difference to an attacker

First and foremost rolling your own crypto is almost always a bad idea see Why shouldn't we roll our own?.

Now that that requirement is out of the way lets take a look at your question. In this case you have to ask what are you protecting against. The AES encryption (assuming that it is implemented correctly and there are no side channels) will protect your data from long term high resource attacks and from simple attacks like shoulder surfing. It should not matter if it is an attack of opportunity or a targeted attack, your data is safe.

All your home grown encryption can be counted on is a form of obfuscation. Tools like frequency analysis are very powerful. Looking like both strings are messed up is not enough. Shifting all letters in the answer makes it look all messed up. However this is trivial to break. It is normally not hard to find patterns that allow for complete decryption with only a small sample. All you can count on is resistance to shoulder surfing and unskilled attacks.

It also sounds like you have implemented both the AES and your algorithm yourself. This will likely open you up to increased risk of side channel attacks (timing, shadow copies ect.).

If you want an easy method for encryption you can use a project like KeePass or 7zip to store your data (with encryption). This way you have the benefit of a time tested and possibly open source project with strong crypto. Not to say that those attributes offer complete protection, just take a look at OpenSSL.

In the end you have to evaluate your threats and ask if you are will to settle for obfuscation or if you need full protection.


Does a Server connecting to port 3544 pose an increased risk

Recommendation at:
 https://www.stigviewer.com/stig/windows_7/2013-10-01/finding/V-17449
Is to  block outbound IPv6 UDP 3544 for Windows Servers
Reason:
IPv6 transition technologies, which tunnel packets through other protocols, do not provide visibility. Blocking UDP 3544 with the firewall aids in preventing this.


Why does message 1 of the WPA2 4 way handshake begin with the access point sending a random number?

This communication carries no information and could have come from any attacker.

Correct. But the server knows which random number (ANonce) it has sent and requires that the client does computations with this number and not with some other number set by the attacker. In other words: the ANonce is neither secret nor does it need to be protected. All what is needed is that it is defined by the server. The server uses the self-defined ANonce and not some attacker-defined ANonce when validating computations done by the client. Validating will only succeed if the client is using the server-defined ANonce and not the attacker-defined ANonce too.

Somewhere I am missing where the 4 way handshake proves the access point's authenticity.

From Wikipedia:
The four-way handshake[8] is designed so that the access point (or authenticator) and wireless client (or supplicant) can independently prove to each other that they know the PSK/PMK, without ever disclosing the key. Instead of disclosing the key, the access point (AP) and client encrypt messages to each other—that can only be decrypted by using the PMK that they already share—and if decryption of the messages was successful, this proves knowledge of the PMK.


How do I interpret output that produces gpg listing keys?

There are public and private (or secret) keys. A public and a private key make up a keypair. Some keypairs are bound to the other ones. The former are called subkeys, the latter master (or primary) keys. In spite of them being called keys, they are actually keypairs.

Keys you generate (and own) are keypairs. Whey you distribute your keys to other people, or other people distribute their keys to you, only the publickey is distributed, and the owner retains the only copy of the privatekey. This is how public-key cryptography works.

Background: when PKC was first invented the terminology was rather ad-hoc. Cryptography in all of previous history depending on keeping the key -- the one, single, only key -- secret, but PKC invented a new kind of key that is not kept secret but rather can be and often should be made public.
Initially people called the other part, the part not made public, secret. As time went on it became clear that there is an important difference between the key in symmetric crypto that must (usually) be shared by two or more authorized parties but (always) kept secret from everyone else,
and the key in asymmetric crypto (PKC) that should never be shared at all, so we adopted the term 'private' to distinguish the latter. Because PGP was created before this terminology was settled, it often uses 'secret' where modern practice is 'private'.

  Keyrings are files. gpg-1.4.18 by default creates two keyrings: public (pubring.gpg), and secret (secring.gpg). Public keys go to a public keyring, private to a secret one.

Mostly true for GnuPG 1 and 2.0; 2.1 up changes secret-ring to a directory of separate files. GnuPG also stores trust settings related to the publickeys in a separate file named trustdb.gpg. There are other implementations of PGP besides GnuPG and they may use different files, or a database, or even turtle shells if they want, as long as they store the keys in some fashion usable for the operations they do.

  Let's take /etc/apt/trusted.gpg: ... Consider the Yarn Packaging key and its subkeys. First, all the keys listed are the public ones. And its public key has 6 public subkeys. Supposedly, the first subkey doesn't have expiry date specified

These keys belong to someone else, so you get only the public parts.

  Now if I do: $ gpg -k --keyring /etc/apt/trusted.gpg
  I can see only Yarn Packaging's first and last two keys. (1) Why doesn't it show all the keys?

By default it doesn't show expired subkeys -- crossdupe

  There's also uid line that shows user id, which is basically a key name. And as I said, trusted.gpg contains only public keys.

The userid is supposed to identify the owner of the key. That is not quite the same thing as identifying the key, but it is very closely related.

  But apt for one shows longer key ids. (2) Why is that?

Keys are actually identified in PGP, and GnuPG, by a fingerprint which is 20 bytes, and a long keyid, which is 8 bytes extracted from the fingerprint.
In olden times, it was thought that having to manually type, read, and compare the long keyid would be difficult for (some?) users,
so GnuPG by default used the short keyid which is the 4 byte (32 bit) low half of the long keyid.
Notice for the (long) keyid 23E7166788B63E1E in your error message the low half is 88B63E1E which is in the list you produced from /etc/apt/trusted.gpg -- and thus should be available.

In your gpg version you can add --keyid-format long to see the long keyids, and/or --with-fingerprint once or twice (or --fingerprint once or twice by itself)
to see the fingerprints, from which both keyids can be easily derived; see the man page. (You can put these, or other options, in your config file to use them automatically.)
Partial crossdupe

In recent years Moore's law has made it easy to fake 32-bit keyids so GnuPG 2.1 up shows fingerprint on masterkey (but not subkey by default).

  Let's take a look at a key I've generated ... So I've got two keypairs, or 4 keys. One master (or primary) key (or keypair). And one subkey (or subkeypair). 2 (public) keys in public keyring, and 2 (private) in the secret one. (3) Why do I automatically get a subkey?

The short answer is probably that you used gpg's default and that's the default, although gpg can create (and use) other arrangements. The long answer is more complicated and partly opinion-based.
First note each key/pair in PGP has 'usage' flags that control the operations it is used for, often displayed as single letters, and the gpg default is that the masterkey is only used for S=signing data and C=certifying (signing) keys, while the subkey is used for E=encrypting data.
Unfortunately before 2.1 (or maybe 2.2?) displaying the usage flags is inconvenient.
For DSA+ElGamal keys, which were more popular in the 1990s when the RSA patent was an issue for many people, this is a technical requirement: DSA can only sign (and certify) and EG can only encrypt (in gpg).
For RSA or ECC it is no longer a technical requirement but still the default.

There can also be operational advantages in at least some situations of having separate (sub)keys for encryption and signing,
and both of those separate from certifying (always the masterkey); gpg does only the former by default.
For some discussions on whether, when, and why you should have different subkeys for different usages or purposes, see:
What is a good general purpose GnuPG key setup?
Why do PGP master keys only have a single subkey, and tie certification with signing by default?
PGP - Why have separate encryption subkey
Purpose of secret-subkeys?
PGP/GPG: Do I need more encrypton subkeys?
Rationale for subkeys in OpenPGP?
GPG masterkey and subkey for encryption and signature and default keys
What exactly is a subkey?
https://superuser.com/questions/632375/why-does-gpg-pgp-by-default-use-different-keys-for-signing-encryption
https://superuser.com/questions/1113308/what-is-the-relationship-between-an-openpgp-key-and-its-subkey
and many other websites blogs etc all over the net, but Google gives me Stack results first because it knows I like them.

  (4) Are there other ways to display information about keys?

Lots, although most of them use something other than or at least added on top of GnuPG. A complete list would take me years to write, and Stack policy is mostly against lists anyway. If you have a particular need, ask about that.


Confused about GitHub's GPG key association and authenticity

Another individual could certainly associate your public key with their profile. They could also email it to people, upload it to a public key server etc.

But fortunately none of this matters, as they don’t have your private key. They can’t sign commits as you, so that verified status will not appear.

By design the public key is public, and there is no risk whilst you are adequately protecting the private part.


Session Expiry due to weblogic.xml for mitigation of cookie hijacking?

I am not sure if I completely understood the issue, but here are my suggestions:

If the HTTPOnly Cookie flag is set then:

 {
 <session-config>
 <cookie-config>
 <http-only>true</http-only>
 </cookie-config>
 </session-config>
 }

If the session ID is transmitted in an URL parameter, try to dump it and see if there is there any counter running on it:

 {
 <session-config>
 <tracking-mode>COOKIE</tracking-mode>
 </session-config>
 }

Next, try to increase the expiration time and then try to migrate it securely. If it is not configured well you might be able to:

Increase the expiration time:

 {
 <session-config>
 <session-timeout>Time Period(In minutes)</session-timeout>
 </session-config>
 }

Please notify me if I understood the question incorrectly.


Is md5(data + key) secure if a proper hmac function isn't available?

No, md5(data+key) is not secure. MD5 is vulnerable to dirt cheap collision attacks. It's possible to craft a data1 that is innocuous and that your system, or the code that's calling your system, accepts as valid, and then later submit data2 which is malicious but such that md5(data1+key) = md5(data2+key), without knowing key (the collision works for an arbitrary suffix).
md5(key+data) would be more secure in this respect, because generating collisions would require knowing the key. However, it has other weaknesses, in particular a length extension attack which allows finding a specific md5(key+data2) from md5(key+data1). While the attack doesn't allow any freedom on the content of data2 given data1, sometimes all it takes is to arrange for an admin bit to be 1 instead of 0, and all it might take is a few tries of different data1 until the corresponding data2 works for the attacker.
The good news is that if you have a hash, you do have the corresponding HMAC. HMAC is a simple construction that just requires two applications of the hash function. In JavaScript-like pseudocode (I think this is valid code if xor is a function that performs xor on byte strings and pads key with null bytes if it's shorter, but I'm not competent in JavaScript and it's possible that string encodings make this a bit more difficult):
function hmac_md5(key, data) {
  return md5(xor(key, '\x5c'.repeat(32)) +
             md5(xor(key, '\x36'.repeat(32)) +
                 data));
}

If expressing xor is really impossible, my recommendation would be to keep the important parts of HMAC, but avoid the known pitfalls (collisions, length extension, algebraic relations). You'd end up with a construction that hasn't been studied, but at least you can avoid known weakness within your constraints. The following construct keeps the gist of HMAC, which is to do hash(key+_) with two different keys (here with a constant prefix to ensure that the two hash invocations don't start with a common prefix). It's homemade and hasn't been studied, so it isn't great, but it's better than using a construct which has been studied and broken.
function homemade_mac(key, data) {
  return md5('a' + key +
             md5('bc' + key +
                 data));
}

Using HMAC-MD5, or even worse a homemade construct, is not ideal, and you should arrange to upgrade your system to support an unbroken hash (SHA-2 or SHA-3), if only because it's a sign that other parts of the system are probably using MD5 in a vulnerable way. But HMAC-MD5 does not have any known vulnerability (other than being a bit too short at 16 bytes, but that at most leads to very expensive attacks which only become plausible if you have billions of data objects in your system).


Based on your comments it sounds like S is passing some encrypted or signed access token to P that it passes to H. H can decrypt or verify the token is authentic and use the information contained within to determine of P is allowed to perform the app. That sounds great.

I'm not sure that you need a nonce here if all you are trying to do is prevent replay. You could just use a serial number. Only accept requests that have a higher serial number than the largest one you've seen. This will remove a full round-trip communication and greatly reduce your bookkeeping. If H can lose the current serial number (eg: by rebooting) then maybe you should keep the nonce.

In general, what you're doing sounds pretty reasonable. That said, it would be better if you didn't design and write your own security. Use SAML. It has been extensively studied and is much less likely to have a design or implementation flaw than any solution you can come up with.


Sending Emails to Distro List w/ Authentication?

Maybe you can know whether in your use case it is fine or not that the DL accepts mail for unauthenticated sources, but certainly I cannot!

Anyway, you have plenty of security options:

allow any sender to write to the list without authentication - low security as any one knowing about the DL could send anything there
allow only one sender to the DL. Attackers will have to fake the sender address to post, but it is not that hard - slightly higher security but still not that high
allow only a restricted list of authenticated senders. Nice security level, but it supposes that your report engine is able to authenticate.
do not secure the sending of mail, but sign them - recipients should simply control the mail signature

If it is a confidential DL and information is not really critical, you are on you own. Said differently, if the risk is low the security can be low too. In any other use case (important data or large diffusion DL) you should either sign the mails or authenticate senders (or both)


why don't all sites generate passwords for users?

Security at the expense of usability comes at the expense of security

The problem is that there is only so much a web application can do to force good security practices on users.  In this particular case I can tell you what will happen in the vast majority of cases: people will write down their "secure" password somewhere nice and insecure.  As a result, this will not necessarily make anything more secure: it will just shuffle around where the vulnerability lives.  In essence, this system is missing some necessary supporting architecture to make the user experience very easy, and therefore very secure.  As a result there are basically three kinds of people with three different results:

People who don't care/understand about password security.  They are going to write down that uncrackable password in a place that is super-accessible, and as a result super-insecure.  These are the same people that reuse the same weak passwords on every site.  As a result, they go from one bad security solution to another bad security solution.  These are also the majority of web users, so for the majority of the internet your solution has no real benefit.
People who use password managers and other password helpers, their password systems cannot integrate with your website.  These people will be worse off, as suddenly their normally-secure system can no longer be used.  As a result they'll probably end up writing it down, maybe not securely, and be worse off then they were before.  To be clear, this will definitely happen: your "show the password in a form so that the password manager can record it" solution will absolutely not work with some password managers.  I can just about guarantee it.
People who use password managers, and those password managers integrate properly with your system.  They were already storing things securely and still are, but now with another point of failure: your random number generator.  Overall, though, there security will neither have decreased nor increased substantially.

Overall therefore, I would say that I see no real benefit for this system.

I have to say this out loud because it is critical in all other contexts: you never want to use SHA256 to hash passwords.  In this case you can probably get away with a fast hash because your password is too long for a brute-force to be feasible anyway.

Edit to add the obvious answer

I think the biggest problem with this solution is that it doesn't go far enough to fix the underlying problem.  The underlying problem is that people suck at passwords: we either pick poor ones, reuse them, or don't store them securely.  The solution isn't to come up with a new password system: the solution is to ditch passwords all together.  Many companies are starting to introduce password-less login.  That's the answer you really want.


This seems to be a way for the malware to check whether it has already infected the file or not. No tool is needed, it could be something as easy as hex-coded string that means something to the malware author, or it could simply be a randomly generated string of some pattern to help the malware identify its own code in the infected pages.

I have seen similar techniques in several infected websites.


Can it be dangerous to use not popular(unknown) dns servers?

A major concern would be that if you requested a legitimate domain, such as Google.com, they could direct you to a non-Google owned IP address. This would not be the site you were hoping to visit and there are major security concerns there. For example, the third-party website could be used to deliver malware. It might not be noticeable to you either. A common payload attack would deliver the legitimate website and embed a malicious iframe on the site. It's generally safest to use a known and trusted DNS provider.

See DNS Hijacking for more information:
http://resources.infosecinstitute.com/stop-dns-hijacking/


Restrict compilation to certain machines

For 1) the answer is sort of no. There are tools used to restrict code to a particular machine in various fields, by physical tokens, licence keys etc, but none are foolproof (DRM, or Digital Rights Management doesn't work) so the important bits are all in your question 2)

Various mechanisms should be in place:

Theft is typically a criminal offence, so employees know that if they steal code they could end up in prison. This works rather well as a deterrent, however as it is not preventative, most companies will also have
Data Loss Prevention tools, that will monitor for and alert on unapproved exfiltration of data
Access controls on the repo such that only those people who require access will have it, and then only the minimum required for their role
Searches for their code across Websites, online repos, or criminal trading sites

And various other tools depending on requirements.


Is using IsBadReadPtr and IsBadWritePtr considered to be insecure?

TL;DR

The reason why they're bad is listed in the links you've provided.  Due to how the Windows OS is designed, the way the functions were coded, and the fact that determining if memory is valid is hard makes these functions inherently unstable to use.

There is no good way to determine if a pointer is using a valid part of memory.  Freed memory doesn't necessarily get zeroed out or reset.  If there is a bad pointer floating around it could point to data that in a valid portion of memory.  Just because you can dereference the pointer doesn't mean that the data itself is valid.

Those two functions use page guard exceptions to determine if the memory is valid.  The design of these exceptions is not supposed to be used as a "valid memory address" check.  As described by the first link:

  The IsBadXxxPtr function will catch the exception and return “not a
  valid pointer”. But guard page exceptions are raised only once. You
  just blew your one chance. When the code that is managing the guard
  page accesses the memory for what it thinks is the first time (but is
  really the second), it won’t get the guard page exception but will
  instead get a normal access violation

Basically even by using these functions you can cause access violations because of the overall design of the Windows OS, and how these functions were coded.  Even if you're not using page guards there's no guarantee that other shared libraries that you're loading aren't using page guards.

Trying to catch exceptions from the OS that are trying to tell you that things have gone terribly wrong is a bad idea.  There is a programming error somewhere and the best option is to crash.  Trying to return to a good state when things go that wrong can cause undetermined behavior.

The bottom line is you can't fix what went wrong with memory.  Continuing execution will only burn you later.


Network ARP poisoned with Cain but Fiddler not modifying HTML.

As far as I understand, Fiddler is only supposed to work on local browser traffic. You need another type of program, a http proxy (like Squid) to do what you intend.


2-factor authentication - Who am I trusting?

A TOTP (Time-based One-Time Password) authenticator app will not have your username and password.  What it will have is a secret token that is used to generate a specific pseudo-random sequence of numbers that changes based on time (typically every 30 seconds).  The app need not even have any network connectivity itself - that is just for backup purposes in case you loose your phone.  It's job is simply to compute, for the current time, what the pseudo-random number should be. The site you are logging into will have the same token stored and associated with your account, and will compute the same pseudo-random value at any given time.  Thus, when you log in, it asks for the current value being displayed by the app.

Who are you trusting?

In general, the answer is 'no one', which is good:

Edit: Of course, you are always trusting that the app you have installed on your phone does what it claims to do, doesn't have nasty security vulnerabilities, etc... You can't ever really trust "no one" when it comes to computing unless you start from scratch (as in sand) and make your own computer hardware yourself ;-)
Google Authenticator only stores the tokens locally on the phone.  If your phone got hacked, somebody would have your TOTP tokens, but other than that, you're fine.
Authy apparently encrypts the tokens locally on your phone using a password you enter, so that they are just storing an encrypted blob for you (see their blog posting on this for details).  That means that even if Authy's servers got hacked, nobody would be able to determine your TOTP tokens unless they guess the password used to encrypt them.
Even if somebody got your TOTP tokens, that only lets them defeat the second factor: it doesn't give them any information about your username/password.

** Best Practice Apps**

As to best practices, here are some thoughts:

This posting favors Authy and seems to give a clear explanation of the problems with Google Authenticator, as well as some info about features that you would want.  In screening a potential candidate, it seems that the list of desirable features would include:

A way to de-authorize a particular device if it gets lost
A way to back up your authentication tokens, in case your phone gets wiped. This backup method should encrypt the tokens locally on the phone with a key/password that the entity doing the backup never gets: otherwise your are trusting them to not give your TOTP tokens to a bad guy.  Again, this is about TOTP tokens and is completely separate from your username and password.
The ablilty to de-authorize one device using another, in case the device is lost/stolen.  This would mean that each device has it's own TOTP tokens (not the same token shared across multiple devices).


Securing non-consumer machine-to-machine APIs with Encryption over SSL

You need to separate authentication from authorization. OAuth 2.0 and OpenID Connect is a system for managing primarily Authorization, not Authentication.

HMAC is a method for symmetric signing. It gives you integrity and partial authentication, but not non-repudiation.

Pubic key encryption is asymmetric encryption. It gives you confidentiality . Note however that encryption by itself doesn't guarantee integrity or authentication. To add these aspects to a PKI encryption system, digital signature and certificates are used. Digital signature also provides limited non-repudiation.

There's really no difference between users to machines, user to user, or machines to machines auth. A machine to machine communication is less likely to complain about the inconvenience of some schemes, but the tactics used to mitigate specific threats models are exactly the same.

Most user-to-machine authentication uses password. In machine-to-machine, this is called pre-shared key (PSK) authentication. TLS can be configured to use TLS-PSK, though this is a relatively rare configuration.

A PSK can also be used to create a message authentication code (MAC). An MAC asserts that the data hasn't been altered in transit. TLS signs the data with MAC for integrity, or you can add HMAC to any messages in any protocol, but it's not a replacement for non-repudiable signature.

In some higher security settings, the system might need a scheme that prevents requests/document from being tampered and prevents the user/machine from later denying the request/document. This non repudiation is provided by digital signature. You can use GPG or S/MIME signature for this. Note that there's limitation on non repudiation from digital signature, in that the signer can just claim that their private key is compromised. In many situations, claiming key compromise often have less severe consequences than admitting to have signed the request/document.

An asymmetric encryption can be used whenever you need asymmetric capability. For example, if you want to allow a machine to be able to write to a data storage, but prevent said machine from reading stored data in the future (or prevent compromise of said machine to allow attacker to decrypt the stored data), then you can use asymmetric encryption.

In many distributed system scenario, you'd also want to be able to prove sequencing or timing of events. Many systems used blockchain to prove sequencing of messages. Alternatively, some may use a timestamping authority. A widely distributed blockchain, like bitcoin's block chain, can also be used as a decentralized timestamping authority.


XSS inside anchor tag () without user interaction?

You can force the user interaction with CSS, by making the a element an fixed positioned block element with a large size and z-index.

<a style="display: block; position: fixed; top: 0; left: 0; z-index: 99999; width: 9999px; height: 9999px;" onmouseover="alert('xss')">


The difference of Security Policy and Acceptable Use Policy ?

The two concepts are related, but distinct. A security policy is generally somewhat detailed, and goes into depth beyond what every end-user must worry about. However, not all aspects of the AUP are security concepts; for instance, my school's AUP has a line forbidding the use of the network to suggest the school's endorsement of a political candidate, except when approved by the general counsel's office. AUPs are legalistic policies intended to govern conduct on the system; this goes well beyond protecting the IT system and into protecting the organization itself.

Now, in some places the information security office is also in charge of policy and regulatory compliance, as the ideas are often intertwined. But AUPs are not inherently part of the security policy, because they aren't primarily designed to protect the integrity of IT systems; they're to enforce acceptable conduct even if it poses no security risk to the organization, and involves no risk to confidentiality, integrity, or availability.


How do (CVE patched) package versions relate?

TL;DR: In principle u20 and any package with a higher number should not be vulnerable (hell, u1 and any higher should not be vulnerable since the upstream version of the package does not change and u1 is not vulnerable).  That is, unless VVV (the upstream version, see below) changes or you change your Debian release, in which case a different numbering is used (see below for an elaborate explanation of version conventions).  That is true in 99.9% of cases, but developers make mistakes and sometimes later changes awaken old vulnerabilities.  Yet, that is quite rare and in such a case a new CVE is raised.
Debian package naming convention
Heh, you will probably find this frustrating but the Debian FAQ explains the version part of the package as:

The VVV component is the version number specified by the upstream developer. There are no standards in place here, so the version number may have formats as different as "19990513" and "1.3.8pre1".
The RRR component is the Debian revision number, and is specified by the Debian developer (or an individual user if he chooses to build the package himself). This number corresponds to the revision level of the Debian package, thus, a new revision level usually signifies changes in the Debian Makefile (debian/rules), the Debian control file (debian/control), the installation or removal scripts (debian/p*), or in the configuration files used with the package.

But wait, what are those VVV and RRR?  The full naming convention is:
foo_VVV-RRR_AAA.deb

AAA is simple, it is the architecture.  VVV comes from the upstream developer, i.e. from the openssl developers in your case (e.g. 1.0.1 or 1.0.1t, see here).
Last comes the RRR which is left to the person packaging the .deb, and it really be anything.  On the other hand Debian packagers normally follow the debian version (deb7 for wheezy, deb8 for jessie) plus some update number.  The update number does not need to be sequential, it just need to be higher than the previous one.  This is likely because a packager will have failed test builds of his packages*.
In summary, there is nothing that links the .deb version string and the CVEs it includes.  You do need to go and read the release notes.  Moreover, often you need to read the release notes of the packager and of the upstream developer (the packager will often include a link to th release notes of the upstream developer).
(security) repositories
What wheezy (security) means instead of plain wheezy is that your Debian has the security repository installed as one of the repositories for apt.  This is normally performed with:
deb http://security.debian.org/ wheezy/updates main contrib

The guys at security.debian.org work on CVEs and produce all those CVE reports in the debian security tracker.  They update packages for old and new Debian versions as needed for the security purposes.  Using your example CVE: openssl in jessie is pretty new, in jessie (security) is newer, in wheezy (security) is new, but wheezy still uses a rather old version.
This allows sysadmins that use wheezy to get security updates without the need to upgrade to jessie.  Debian is incredibly robust and stable, and there are sysadmins that may wish not to update their packages with security updates fearing that code changes will make things fail (they simply do not enable the security repositories).
Now, the security guys will update an older package if it is needed, they prefer backporting the package.  Yet, sometimes it is needed to update VVV, for example the openssl at wheezy (security) is at 1.0.1t whilst on wheezy is at 1.0.1e, likely because of this CVE.
Therefore, we can say that wheezy (security) is more dangerous in terms of backward compatibility then plain wheezy but safer than upgrading to jessie.  As far as I am aware if you use just plain wheezy or plain jessie (you only have the stable repository in sources.list) you will never receive a VVV update through apt, you will only get updates to the RRR part.
Note that thanks to the fact that it is a different set of people that work on the (security) repositories and the normal repositories, funny things happen.  Here is a CVE in which the (security) package is vulnerable but the normal one isn't, in this case it is fine because VVV is the same and RRR of the non-security package is higher and will be selected by apt as the newest update available.
Related / References:

Debian packaging basics (FAQ)
Debian package naming convention on unix.SE

* I cannot tell specifically for Debian but one recent packaging adventure I watched was Vim 8.  The upstream developer patches came very fast and the testing repository of Arch had: vim-8.0.0001 => vim-8.0.0003 => vim-8.0.0005.  The last one, vim-8.0.0005, was moved into the extra public repository. Therefore packagers often jump release numbers because the package is updated before it is allowed to leave the testing package repositories.


I took a peek with Wireshark and I couldn't see any plain text message. Everything Facebook related was going through TLS/SSL. It appears that, at least in my case, everything was encrypted. I would, however, appreciate if someone more knowledgeable could confirm this.

That would be exactly what I would do to test whether my browser is sending plaintext messages from some webapp.  Yet, since you are on a page that is connected over HTTPS the AJAX call must be made through HTTPS thanks to the same origin policy.  There is an old (but still actual) question on SO about it.
If you look at the comments on that question you will also see a reference to the CORS spec which argues the following about Cross Site Resource Sharing:

user agents are allowed to terminate the algorithm and not make a request. This could be done because e.g.:
...

https to http is not allowed.

Now, this part of your question is another story:

And since my understanding of https is a bit shoddy, what would using https for chat actually mean in terms of encryption? Would there be encryption for incoming messages, outgoing messages, or both (or neither)?

For the encryption part I'll simply refer you to the relevant SO question.
For the "shoddy" part you probably mean the (quite) famous sslstrip attack by Moxie Marlinspike.  It is a MITM which fakes to your browser who it is actually talking to, it is an attack that requires the attacker to have control of the network you are on.  HSTS is being widely implemented these days (facebook uses it) therefore sslstip is becoming less of an issue.  And we also have a reference question for sslstrip.
References:

HTTP Ajax Request via HTTPS Page
Cross-Origin Resource Sharing
How does HTTPS provide security?
How does SSLstrip work?


Does "New seat seat0" indicate something successful?

New seat seat0 indicates that the login manager started successfully.

seat0 is a default seat in systemd and is created on service start (see Multi-Seat on Linux).

There must have been a reboot (likely not clean, probably the system crashed) on 21:29:52 (according to the clock settings before reboot). The lower numbers in PIDs also indicate that system was recently restarted.

Given the information in the question, not much else can be told. However, if you have not changed the default password for pi nor disabled the password authentication, then you can assume the system is not yours anymore.


How to keep track of passwords and avoiding password-reuse

Yes - let your password manager handle all of them.

400 sites is not a lot to have in your password manager - I have many more than that. Most I generated randomly. Some I created on other systems and then transferred them in. But most importantly, I don't worry what they are, because my password manager handles them.

Before I used a password manager, I tried patterns, but they are relatively easily guessed once a couple end up leaked and brute-forced, and yes, I have had the haveIbeenpwned alerts on occasion and had to change things. Trust me, doing that is much worse if you have used any pattern, as you have to change them all!!!


Can I expect my e-mail to be routed securely?

The SMTP servers may (probably will) still transfer the email as plain text. Sometimes SSL is used, but you cannot count on this being the case unless you specifically know the configuration of the specific servers on both ends. This means that in your scenario, an adversary capable of monitoring Internet backbone traffic could intercept the email. (Generally adversaries with this level of capability are state actors.)

SSL is still important on both ends to protect account credentials, and it will protect you against adversaries monitoring the traffic on your local network. Many attacks are going to be at this level - someone on the same wireless network as you, for instance, or who has compromised a local server on your LAN. However, SSL will do nothing to protect you against a compromised SMTP server. Message-level encryption is required if you want to avoid any transmission of the message in plaintext, and importantly means that the message will not be stored in plaintext on either server. For non-state adversaries this is the biggest attack vector - just compromise the SMTP server on either end and you can read all the plaintext mail even if every transmission along the way used SSL.

S/MIME and PGP (GnuPG) are the two standards for doing this. Even then, the message envelope will be visible. You cannot prevent an adversary who can sniff the traffic between the SMTP servers from reading the envelope, so they would know things such as the to, from, and subject line.

To directly answer your question, both parties using SSL to send and retrieve their email does improve your security - and it improves your security versus non-state adversaries a lot - but to secure the message content as much as possible you should use message-level encryption to fully encrypt the message body, and accept that the email headers will still be transmitted in the clear. An adversary capable of seeing the traffic between the SMTP servers would still be able to tell who you were emailing and what the subject line was - there's no way around that besides "don't use email" - but they would not be able to read the body of the message.


Is phone-based two-factor authentication significantly more secure than email authentication?

A good practice in two-factor authentication is to use an authenticator app (like Google Authenticator) as the second factor. If an attacker has access to your phone this won't help you either. But the thing with SMS as a second verification step is that it introduces additional risks pertaining to carrier security. Due to this, NIST no longer advises to use sms-based 2 factor authentication in the latest sp800-63b publication (https://pages.nist.gov/800-63-3/sp800-63b.html section 5.1.3.2. Out-of-Band Verifiers)


The attackers exploited a database weakness which caused the database to accidentally dump a large batch of username*||hash (and possibly salt) records.

The hashes were then brute-forced offline, revealing all the weaker passwords like "toto24" and "123456" or "mypassword", but not the strong ones. This compromised a really large fraction of the accounts, since most people have crap passwords. And often, even just knowing the username is enough, as the person might have signed up with the same username at a website with even weaker security - but here's the interesting part: he also signed up with the same password. Game over!

Yahoo never had the plaintext passwords at hand, although they could have cracked the weak accounts as well if they really wanted to, but they just have no incentive to do that.

*In the case of Yahoo, username = email.


After encoding process with msfvenom, my tool is not working. Why?

shikata_ga_nai is for encoding shellcode (aka, instructions to be executed by the processor).  You cannot process/encode arbitrary data (and ruby source is just data) with it.


How do I get unique users signed up? [Canada or US]

"Welcome to the Internet, where no one knows that you're a dog."

You cannot rely on any info supplied by a user to be globally unique in identifying themselves.

Any process you can devise can be manipulated. Even if you collected passport page photos, you would still not be able to confirm that every winner was unique. For example, my wife has a passport from one country with her maiden name, and a passport from another country with her married name. There are also online fake ID generators for just about any country you would like.

Instead, you have to design the process:

to be more expensive to manipulate the process than the prize is worth (e.g. have a proof of purchase tied to a specific account)
to be tied to a long-term proof of relationship or activity (certain amount of reputation points in your system, depth or complexity of history on a social network)

If you cannot do these things, or if they are contrary to your goals for having a prize, then you need to not care if someone was able to win multiple times, or gain enough benefit from someone winning, even if someone wins multiple times.

For example, in order to win (or claim their prize), they have to advertise you on their social network. Even if someone won 100 times, that would mean that they would have to have 100 accounts and have all of them advertising for you. That's not such a bad thing.


A customers site had a big mysql injection attack on it, just want to learn from it

The mere fact your DB ran the quoted queries (throwing you the error reports) means you do have injection vulnerability in PHP code. Note, that some methods of inspecting DB tables structure involve running multiple queries with different parameters until DB throws an error and HTML page breaks. That means the failed queries are only tip of iceberg of all queries that were run.

There're 5 queries:

1) Invalidates all previous restrictive WHERE statements by effectively adding " or 1=1" statement.

2) Check for DOS attack against SQL server DB by adding another delay query.

3) Inspecting number of columns in DB table. Number of null-s on change between passed and failed queries is the one attacker looks for.

4) Same for user auth tables: ends query with likely non-existent ID then inspects number of columns. null-s are replaced by HEX values.

5) misguiding auth check by injecting crafted $user into query PHP string like

"SELECT ... WHERE ... AND name = '" + $user + "'"

(note the exact sequence of single and double quotes) It's likely the user 'leachiancs' was real aquired by previous investigations.

Queries (1)-(4) carry SQL comment in the end for invalidating the rest of originally intended query and defeating LIMIT or other validation WHERE constructs.

The main lesson here is using only parametrized queries and not trying to reproduce all that dirty work of proper DB+PHP escaping for all possible versions and quirks in syntax.


How long would it take to bruteforce an AES-128 protected pdf knowing the key is 20 letter long and that the charset is A-Z,0-9?

A-Z and 0-9 means 36 possible characters. 20 such characters imply 3620 possible keys. That's approximately equal to 2103.4.

The biggest brute force effort currently known publicly was for a 64-bit key (for RC5, but the difference between RC5 and AES is not important here); it is described here. It took almost five years and a lot of contributors; the peak cracking rate was equivalent to what 30000 top computers of that time could do. Of course, this was a decade ago, and computers have become faster, but not to the point of closing the gap from 264 to 2103.4: we are talking about a problem which is 725 billion times harder.

GPU would not be a very efficient platform for AES-breaking; the most cost-effective system would be CPU with AES-NI opcodes. Note, though, that an AES key is a sequence of 128, 192 or 256 bits; not a sequence of characters. Therefore, your characters are probably transformed through some kind of hashing into an AES key, and the hash function computation will probably be more expensive than the AES invocation itself. Depending on the used hash function, GPU may become competitive again. In any case, we are talking about, at best, a few billions of keys per second and per GPU. One billion of such GPU would produce a lot of heat... and would still need billions of seconds to get through (one billion of seconds is 30 years).

So the only realistic answer to your question is: forever. An key of the format you describe (20 characters in an alphabet of size 36) will not be cracked through brute force. Brute forcing such a key would not make sense: even if it was technologically feasible (which assumes more resources than is available to the biggest governments or corporations currently existing), it would cost a lot more than whatever the key is protecting. For instance, if I owned the millions of billions of dollars involved in the process, then I would simply buy the USA wholesale (top corporations, government,... including a complete national debt buyout)(that is, if it took my fancy to actually own the USA, which is, when you get down to it, a weird idea).

(In all of the above I am using the American "billion", i.e. one thousand millions, not one million millions.)


How to eliminate data leaks when accessing encrypted data?

Does method 2 address data leak vulnerabilities present when accessing files via method 1?

Not at all. It just ensures that the already-protected VeraCrypt container will be saved to an encrypted space when extracted for mounting and removed safely on unmount.

All applications used to open and process the files stored inside the VeraCrypt container will behave in the same way as in the method 1 and the possibility of storing temporary files on non-protected disks remains.

  Is there a "better" way to secure and access files?

For the concern specified in the question: the machine used to run the applications opening/processing the files must use full disk encryption for all its disks.

This KeePass feature is intended to protect for example a plain text file stored in the KeePass database. When you open such file, KeePass has to save it in the filesystem so that an application (like Notepad) can open it (because Notepad does not know how to read directly from the KeePass database).

KeePass ensures no trace of this file, which KeePass itself temporarily saves in the filesystem, will remain. But it cannot limit what the application can do with this file/data. Applications run in a regular namespace (they are not sandboxed by KeePass in any way) and can store temporary files wherever they "want" (i.e. were configured to).


Are there password/passphrase guessers/crackers which can utilize facts supplied about the target?

Who's your daddy

CUPP

Description and download link is in the linked page(s).
Downside is (as far as I know) they can be only used under Linux.


Why shouldn't I put user input in HTML comments?

The relevant entries in the HTML5 Security Cheatsheet are:

Ending HTML comments with a backtick character: html5sec#133 (IE6, IE8)
Injecting XSS or with a conditional comment html5sec#115 (older IE, IE quirks mode)

Apart from that user input might be used to change this comment into a conditional comment (IE only) and thus change the DOM or block the execution of script after the comment. This could change the behavior of the page in an unintended way.


Is INTEL-SA-00075 Detection and Mitigation Tool enough to mitigate IntelME attacks

No, as the link you yourself posted says (for both versions):

This version does not provide automated mitigation support.

For reference, we are talking about CVE-2017-5689.
Intel released a statement here:

Step 1: Determine if you have an Intel® AMT, Intel® SBA, or Intel® ISM capable system.  If you determine that you do not have an Intel® AMT, Intel® SBA, or Intel® ISM capable system then no further action is required.
Step 2: Utilize the INTEL-SA-00075 Detection Guide to assess if your system has the impacted firmware. If you do have a version in the “Resolved Firmware” column no further action is required to secure your system from this vulnerability.

Linux users may alternately use the following tools and documentation.  Note: Validation is ongoing and may result in updates to this release.
INTEL-SA-00075 Linux Discovery Tool and Mitigation Tools v1.0.zip

Step 3: Intel highly recommends checking with your system OEM for updated firmware.  Firmware versions that resolve the issue have a four digit build number that starts with a “3” (X.X.XX.3XXX) Ex: 8.1.71.3608.
Step 4: If a firmware update is not available from your OEM, mitigations are provided the INTEL-SA-00075 Mitigation Guide.

TL;DR:
You can check if your system is vulnerable by running the tool you have linked in your question. If your system is vulnerable, update the firmware.


Ssecure communication between Docker container and an Elasticsearch server?

You need to set up TLS support on the Elastic Search cluster, which is well documented by the vendor: https://www.elastic.co/guide/en/elastic-stack-overview/current/ssl-tls.html

Then you need to re-configure all method(s) your application uses in your docker container to connect to the TLS secured end-points in your Elastic Search cluster. For instance replace http://hostname.example.com:some-port/some-path use https://hostname.example.com:other-port/some-path.


Prevent the tampering of the logs of a service

Use Central Log Server - it can be as simple as cronjob to copy log files at one place or using Syslog-NG to store logs in Database. (https://syslog-ng.org/ )
Or You can use AIDE sort of tool to ensure integrity of the logs. Rotate logs at frequency based on size and criticality.

Also an excellent answer is given here Techniques for ensuring verifiability of event log files and https://crypto.stackexchange.com/questions/8104/tamper-proofing-log-files


using Yubikey (NEO)'s to store the private SSH keys of my users

This use-case is described on yubico website here:
https://developers.yubico.com/yubico-piv-tool/SSH_with_PIV_and_PKCS11.html

  What I can't seem to find anything about is a way to also sign the key and load that into gpg-agent using OpenSSH's method for signing user keys.

The step 2 from the above mentioned method can modified that you will not self-sign the key, but sign it with your CA key.

This method should work also on windows (yubico-piv-tool) has releases also for Windows.


REST API: does securing the first call with a CAPTCHA make sense?

The standard approach to this would be to e-mail the user to confirm the account and if this doesn't occur in a pre-defined period of time, to delete the registration.

You could combine this with some Anomaly detection so for example if you got large numbers of registrations from a single IP address you could assume that this is hostile and block that IP address. Not perfect against a determined attacker but could deter less determined ones.

You could also add something like a CAPTCHA to the registration process, again this could deter less determined attackers but there are a number of ways round these, such as CAPTCHA completion services which are relatively inexpensive, so a determined attacker could bypass them.

Which of these are reasonable largely depends on the risk/threat profile of your application.


IP address filtering vs web application security

If you're using IP only authentication, attacker can still use the web application through pivot attacks against a host that is allowed by firewall to access your application.

For example, let's assume your application is inside intranet (http://192.168.0.5) and one of the clients (192.168.0.100) is browsing the internet and visits a malicious web page that does intranet fingerprinting, requesting http://192.168.0.x/ (x=0..255) URLs through the victim (192.168.0.100) browser, effectively finding IPs with port 80 open and reporting them to attackers. Attacker can do it e.g. with BeEF framework. Later on, using the victim browser like a proxy, attacker can issue requests to the target application (http://192.168.0.5). There even is a framework for detecting what types of software do you have installed in the intranet - e.g. Yokoso. Using these will make further attacks easier.

Of course, attacker can also attack OS on one of the clients (e.g. with spear phishing or drive-by-download attack), so that he has more possibilities to attack the intranet application and is not restricted by Same Origin Policy.

If you're allowing access to the application only for some hosts in the same subnet (and other hosts are denied access), internal attacker has more possibilites because he has more knowledge (e.g. he might know the exact URLs for the application, it's version number) and is within the same network, so he can try e.g. ARP spoofing attack to hijack traffic between application and one of allowed clients.

I would recommend hosting the application only on SSL (to protect from man-in-the-middle) and adding login/password authentication (either cookie-based or a simple HTTP authentication)


What are the security implications of enabling a SNI-hole on a web server?

My gut feeling was that I would rather direct the SNI-less connections to a different server (not the same one serving Bob), and via means that are external from the same server.  Something like a Deep Packet Inspection firewall actually looking at the ClientHello versions and the SNI part.

I can see two reasons against SNI-hole being parsed in the same server:

1) TLS Server Name Indication and Host headers are completely different features at different protocol layers, but serve a very similar purpose. Because of this, it may not be in the interest of server software creators to interpret them differently - and it might be somewhat difficult to keep testing that the behaviour of selecting the virtual host is happening at the TLS SNI level - so at a future upgrade, Bob might end up at the unsafe server with a cookie that was not supposed to be sent via this method (or Alice might receive an error instead of a relaxing explanation about her connection.)

2) By keeping all the weak ciphers and protocol variations in the same server you keep the server software complicated, and possibly open for so far unknown attack vectors somehow able to revert/rollback to unsafe versions of the protocol.


How can I determine whether Remote Desktop hacking was successful?

Non-server editions of Windows only allow one user to be logged in at a time, so a successful login via RDP will kick you out and you will probably notice.

You can also find successful RDP login in the Security event logs by looking at the logon type. It is possible to use an XPath filter for this.

The bandwidth usage you're seeing is probably RDP serving the login screen. You can change the settings to require Network Level Authentication which validates the credentials before a connection can be made (no login screen).


Bug bounties - Shoud I report 0days in third-party components?

It is highly likely that the developer implementing the vulnerable piece of code would be restricted to modify it either by a license or by inability to do so because of either no sufficient knowledge to modify the code, no access to it or other similar impediments. This being said, you ought to report the vulnerability to the third-party developer who should then take steps to mitigate the issue and push the changes to anyone using the code.

It is recommended that you report the issue to any affected programs or applications, but that's up to you - after all, there aren't any regulations on vulnerability disclosure and the only guideline is your ethical reasoning.

To directly answer your question, if the developer of the vulnerable code is responsible for its maintenance (depending on the software license), they would most likely be the only party who would be willing or eligible to pay you a bounty. However, disclosing the vulnerability to any affected parties is recommended and they might also be willing to reward you depending on the severity of the vulnerability and their ability to mitigate it.


Password relevance in key derivation function

Key Derivation functions like PBKDF, KDF1, and, HKDF can use a single password to derive a key. To derive an additional key with the same password the common approach is using info as in HKDF which has two steps.
Extract : HKDF-Extract(salt,IKM)->PRK
Expand: DF-Expand(PRK,info,L)->OKM,

IKM is the Input Key Material
OKM is the Output Keying Material
PRK is Pseudo Random Key

The Extract mechanism is important if the IKM is not good random material. The salt strength the PRK. For passwords, this is the case.
With the info one can derive multiple keys ( a python code is included). This is due to domain separation.
The bottleneck is the strength of the password. If one uses a good mechanism like diceware with good entropy then it is beyond attack.
Password-based key generation is usually used for file/volume encryption like Vercrypt or password managers. For end-to-end communication Diffie-Hellman key exchange is used mostly with the ECC version. The established( exchanged) key then used with a KDF to derive a symmetric key.
For encryption, one doesn't need to change a key often. Since there is a good mechanism to reuse a key, the IV/Nonce as in CBC and CTR mode. With the IV/nonce these modes can achieve the standard notion of security IND-CPA.
Therefore, theoretically once can use one good password to secure everything. Practically, this is not preferred. Separating the domains with multiple passwords is better in practice than in turn will require a password manager like keypass.


How to protect against MAC spoofing in WiFi network?

You cannot prevent the user from changing their MAC address.  The MAC address is provided by the client and can be changed at any time assuming their hardware allows them to do so.  If you are relying on the client machine for implementing an effective control, you will fail because it will be able to be avoided.  Most users will not change their MAC address, but a dedicated user can do so without consequences.
In addition, captive portals are a security anti-practice.  As outlined in this article, you are basically intentionally tampering with the user's traffic to substitute your content instead of the content they wanted to see, and by any typical definition of network security, that makes you a malicious man-in-the-middle party.  In other words, you are a bad actor.  Moreover, because most sites are HTTPS with STS these days, it's very hard for a user to actually see your captive portal because their browser literally won't let them in many cases.
You should adopt a solution which doesn't rely on the security of the client and doesn't implement a MITM attack.  For example, you could have a set of randomly generated passwords, each one expiring on a different day of the week, and have the person call the front desk to add the charge to the room and get a password.  While it would be able to be shared amongst a group, it would not be any less secure than your existing approach and would be less hostile to your users.  You could additionally add a limit on the number of MAC addresses as long as you realized that a dedicated user can evade it.


How to get the cookie of embedded iframe

Assuming your site is not "example.com" (i.e. that this is a cross-origin iframe) and that there isn't a separate security vulnerability on example.com (such as cross-site scripting), you can't do this. It would violate the same-origin policy, which is a very major security boundary for browsers.

You could try attacking the network, but HTTPS is in the way. Assuming you have some way to capture or at least observe the victim's network traffic (such as DNS tampering, ARP spoofing on the local network, having control of the victim's router or other node on the path, etc.), you still need one of the following:

A trusted TLS certificate for example.com
A way to convince the client (browser) and server to accept a weak cipher suite, such as one using "export" encryption (or even RC4)
The server to be vulnerable to an attack such as BREACH, CRIME, POODLE, or similar
Some other as-yet undiscovered security vulnerability

Alternatively, if you have a network attacker position and the target site neither uses the "Secure" flag on its cookies nor uses HTTP Strict Transport Security (HSTS), you could have your iframe make a request to the HTTP version of the page instead, and steal cookies off the wire when it does.

You could also try attacking the server directly. If the server is vulnerable to Heartbleed, that's an easy way to steal somebody's cookies, though not necessarily those of the intended victim. Getting code execution on the server (through something like uploading a web shell or finding a command execution bug) would let you do whatever you wanted with the web server, at which point stealing cookies is often a waste of effort but technically possible.

Alternatively, for browsers not patched against Spectre or using site isolation (where each site's data is in its own process), you could use Spectre to attack the client and steal the cookies that way.

Basically, though, using only the tools you've described and assuming an otherwise-secure system, it can't be done.


The schemes you mention are protocols for securing 802.11x traffic over wireless networks. They don't mandate how the AP password is encrypted or hashed during storage. However, the security of the protocol does rely on making the key secure.

WEP relies on a broken RC4 implementation and has severe flaws in various aspects of its protocol which make breaking WEP near-trivial. Anyone with a laptop and a $20 wifi antenna can send special de-auth packets, which cause legitimate clients to re-authenticate to the AP. The attacker can then capture the initialization vectors from these re-authentication packets and use them to crack the WEP key in minutes. Due to the severity of the break, WEP is now considered deprecated. See this question for more details on WEP security.
WPA improves upon this, by combining RC4 with TKIP, which helps defend against the IV-based attacks found in WEP. It also improves upon the old handshake mechanism, to make it more resistant to de-auth attacks. Whilst this makes a large improvement, vulnerabilities were found in the way that the protocol worked, allowing an attacker to break TKIP keys in about 15-20 minutes. You can read more about the attack at this other question.
WPA2 closes holes in WPA, and introduces an enhanced version of TKIP, as well as CCMP. The standard also bring support for AES, which provides even further security benefits. At current there are no known generic attacks against WPA2.


I've shared my WiFi with my neighbour. How can I ensure they're not downloading illegal content?

I guess that most corporate people setting up Internet access for the employees may have the same need: how to ensure that employee does not waste enterprise's bandwith to download torrents?

Usually, the main answer lies in two things:

Restrict the destination port numbers to the really needed ones,
Setup a DNS cache server, which can provide an easy way to blacklist certain domain names (this implies that rules above do not allow port 53 as destination port),
Make the HTTP flow go through a proxy,in the current case a non caching proxy like privoxy may be usefull.

For HTTPS content, you will not be able to check the actual page or data content however you will be able to know the domain name of the website currently visited (both thanks to DNS requests and SNI) and compare it to a blacklist, which seems sufficient for your needs.

edit: Just a thought, in case of a one time check to answer questions like "Internet is going damn slowly, I hope my neighbor is not using all the bandwidth with torrents", you have the possibility to use a network sniffing software (like wireshark) on your wifi network to check what is going on currently.


Difference between access control systems that can/can't be compromised without valid credentials?

Why are you classifying a vulnerability leading to unauthorised access in sshd differently from that in encryption? In comments. you are differentiating based on "likelihood", but if you are talking conceptually, then they are equivalent and they are universally applicable in any discussion of access control. And since the concept is universal, it makes no sense to somehow discuss them separately.
What you are actually talking about is the process of risk assessment. That process occurs on a separate layer than simply discussing "access control". Risk assessments require context, which is where you then bring up likelihoods and impacts of the specific elements and threats involved. Risk assessments need to be done with every layer of control, including access control.


Why can't cookie hijacking be prevented by associating cookies with IPs?

If the cookie gets stolen inside a public Wifi Hotspot all users of the Hotspot have usually the same public IP address.  This means binding to an IP would not help against an attacker in the same local network.

Apart from that if the public IP of users changes like it is the case with moving between networks (Mobile, WLAN university, WLAN at cafe, WLAN at home...) they would need to login again and again.


Reading older mails signed with a certificate that has meanwhile expired

Let's give it a chance:

If you have a key which expires in a year, all the data sent signed with that key within that year is valid forever (unless the key have been exposed), the problem here is, has the data or the application which uses it the correct information about when it was generated? (date signature stamp).
A different problem may be, hey, you are signing your data with an outdated key, then, the data might be valid but you should have foreseen this problem and you should have already generated a new certificate (let's say, a month before expiring).

A pair of problems somewhat remain. What happens if the data or message is back to life again? Should I leave the old signature with it? Well, this just depends on your Secret Management, but what you could do is sign it again.  The other problem is, can I educate the people I communicate with about this certificates thing? This is a hard work and if they are not really into this stuff the warnings will feel like "everything is going fine, no problem" or "everything is wrong, nuke it from orbit".

Maybe (and I have added this after your clarification), your best option here (if you really want to avoid most of this warnings) is to choose a certificate which expires more or less with the information, so, let's say you are in a project that will take a year, then you better check your keys because if it expires within a month maybe you will face this problem again so you better generate a new key for the project (this could be a bit of a PITA if you work with different projects and so on).

After all, it is impossible to know how your client's software is going to behave, you might not even know what software they use so it is impossible to foresee the problems, you will need to educate them and be always aware of when your certificate is going to expire so you can notice your clients beforehand.


PMKID found , but it should be WPA handshake

you can certainly try your luck cracking it with hashcat. if you want to test it out, capture a PMKID of a wifi that you know the PSK password for and try bruteforcing with the known password to confirm it works.
install the latest version of hcxtool from github on Linux: https://github.com/ZerBea/hcxtools
then run hxcpcaptool on the pcap file to extract the PMKID like this:
hcxpcaptool -z pmkid_hash.txt your-pcap-01.cap

now run hashcat (using mode 16800) on the extracted pmkid hash:
hashcat -m 16800 pmkid_hash.txt -a 3 -w 3 '?l?l?l?l?l?lt!'

ref: https://hashcat.net/forum/thread-7717.html


What leaked mass surveillance capabilities have not been explained by vulnerabilities we have learned about since 2014?

I did some more research to come up with an own (quite possibly incomplete and/or wrong) answer.  This is a community wiki answer. Edits or separate answers are more than welcome.
TL;DR: Almost all mass-decryption capabilities can easily be explained using publicly known vulnerabilities, attacks against SSH being a possible exception.
The NSA BULLRUN program is the central part behind the Five-Eyes decryption capabilities. According to this presentation by the OTP VPN Exploitation Team, cryptoanalytic attacks where available against at least IPSec, SSL, PPTP, and SSH.  The leaked documents don't always contain a date, but it seems safe to assume that none are newer than 2012.  Newly introduced vulnerabilities like Heartbeat, which was widely deployed starting autumn 2012, are therefor not a sufficient explanation.

IPSec: The Logjam authors speculate that the Diffie-Hellman key exchange may have been broken by nation-state attackers using a precomputation attack.  This would have enabled agencies to attack the majority of potential targets, as many sites used the same Oakley group 1 parameters.  The SLOTH transcript collision attack is another likely explanation, as MD5 was still widely used back then.

SSL: The mentioned transcript collision and DH-Kx attacks are also possible (and possibly even simpler) on SSL connections.  Furthermore, numerous SSL/TLS vulnerabilities have become public knowledge in the early 2010s. This includes FREAK (resembles Logjam), BEAST, BREACH, and POODLE as well as attacks against the RC4 cipher.  According to SSL Pulse by the Trustworthy Internet Movement, close to 100% of all sites supported SSLv3 in mid 2012.  Routine decryption of SSL traffic is probably the least surprising in hindsight.

PPTP: Quoting Wikipedia:

Serious security vulnerabilities have been found in the protocol. The known vulnerabilities relate to the underlying PPP authentication protocols used, the design of the MPPE protocol as well as the integration between MPPE and PPP authentication for session key establishment.

SSH: The SLOTH attack also works against SSH, though the authors consider the attack impractical due to it's still very high computational cost.  DH-Kx attacks might be possible as well or could be combined with transcript collision attacks, though I'm not aware of any work that has demonstrated the feasibility of any of this.

The cryptoanalytic capabilities may have been known to the mentioned agencies well before being published in the unclassified literature.
Non-cryptoanalytic attacks may have contributed as well, e.g. backdoors or remote code execution on networking gear serve as a perfectly fine explanation.  This would have made it simple to extract encryption keys for any protocol from the affected devices, rendering attacks on those protocols trivial.


How to store data on server without an ability to read it?

So what you probably want is public private keys.

User A sends his own public key to User B, User B can then encrypt messages using Users A's public key.

User B then sends back the encrypted message to User A, user A has a private key which matches the public key, user A must always keep this PRIVATE. Using the private key user A can decrypt the message from User B. Once Encrypted user B would not be able to decrypt the message, the public key is used for encryption only.

what you are looking for has been used in many technologies, I use a similar method day to day with PGP.

obviously you would design your application to take this into account to handle all of the key generation and store them on the persons device (never store them on your server)

Another method would be to user a preshared key and another type of encryption like AES, this however would require the sender and receiver to know the same key. problematic if you only talk online.

preshared key would mean the user would need a key for every conversation, while a PPK (public and private) would mean that many people could have a users public key and the user hold securely on to that private key.


Decrypting AES-128-CBC leads to first block being correct, the rest corrupt

If you are seeing a partially correct result it is likely an IV problem:

In CBC the IV is XOR'ed to the plaintext after encrypt/decrypt. This means that if you've got the IV completely wrong then your decrypted message will have incorrect data of the first block (in CBC 16 bytes) as that is the length of the IV. This is in line with the quoted wiki.

However there is also the case where your IV is partially right (say the first n < 16 bytes are correct) then you will see the correct first n bytes in the decrypted file and the remaining (16-n) bytes incorrectly. This means that even if you try an IV of all zeroes you might still get the first n characters correct.

I can't say why your IV is incorrect but I would check the value there first.


What bad coding practices makes a browser extension vulnerable?

In browser extensions, the impact of a vulnerability highly depend on the context and the requested permissions. Static tools (JSHint, AMO validator) to check code exist, but none of them are 100% reliable, especially for obfuscated code.

So, I'm not going to show a magic regular expression which tells you whether some code is vulnerable or not, but give a brief overview on how extensions work, and a small list of potential extension-specific issues.

Existing tools

Mozilla's static code analysis tool, used on addons.mozilla.org is publicly available as AMO Validator. This tool works for all Jetpack-based add-ons. First, it identifies (by hash) and excludes all whitelisted JS libraries. Then, it runs these test cases on the remaining content of the XPI archive.

None of the other vendors have published such a tool. Fortunately, extensions (not plug-ins) for Chrome / Safari / Opera cannot get as much privileges as Firefox add-ons.

Extracting

Firefox (xpi) and Opera (oex) add-ons are zip files with a different extension.
Chrome (crx) extensions are zip files with a preceding CRX header.
Safari (safariextz) extensions are signed xar archives.

7-zip is capable of extracting all of these archives.

Permissions

Chrome, Safari and Opera require the extension developer to declare permissions to access certain origins or features. These declarations can be found at:

Chrome: /manifest.json. See match patterns and permission warnings
Safari: /<extension-name>.safariextension/Info.plist. See Access and permissions.
Opera: /config.xml. See config.xml.

Origin access cannot be configured in Firefox add-ons.

Content scripts / Injected scripts

All extension environments support execution of code on pages which match a pre-defined URL pattern. These are called Content scripts in Chrome / Firefox, and Injected scripts in Opera / Safari. These scripts have direct access to the page's DOM, but no direct access to the page's JavaScript variables, because the execution contexts differ.

Background pages

These pages are the most privileged part of an extension.

Vulnerabilities

I'm not going to mention obvious mistakes such as using setTimeout with strings (these are already mentioned in bobince's answer), or far-fetched methods which are unlikely to be accidental, such as an extension which grabs credentials from a page and sends it to a rogue web service.

Using .innerHTML or jQuery to parse external HTML (see this question on Stack Overflow):

// Example 1:
var heading = $(xhr.responseText).find('h1').text();
// Example 2:
document.body.innerHTML += '';
// For: <img src="bogus" onerror="do_something_evil_with_privileges()">

Use of the window.onmessage event without validating the data or checking event.origin. In the following example, any third-party can use window.open and postMessage to send a message to Gmail, and abuse the unintentionally leaked features:

// Content script running on https://mail.google.com/mail/
addEventListener('message', function(event) {
    if (event.data.type === 'send-mail') doSomething();
    // or:
    notifyBackgroundPage(event.data);
});

Loading external (JS) code (worse: loading external code over http). If the external source is compromised, all users will be susceptible to abuse.
Use of cross-browser extension frameworks such as Crossrider and Kango. These are convenient to developers, but the generated extensions request an unnecessary number of permissions.
Not sufficiently restricting the influence of an extension API. An extreme example: Removing the httpOnly cookie flag for all sites, instead of just the relevant site. This also includes running content scripts on too many pages.
Privacy issues:

Use of services like Google Analytics (search for _gaq.push)
Loading external assets, such as social media buttons.

Most of the regular vectors are also relevant for extensions. Use the cheatsheets on https://www.owasp.org/ or take a look at http://html5sec.org/.


What wordlist does OWASP ZAP spider use?

For  future reference:

ZAP works as spider. Spiders crawl through data and find connection points in nodes. Webspiders follow links, sources, anchors in HTML, JS and CSS. Every time a connection is found, it is added to the source tree, creating an hierarchical data structure knows as a searchtree. To give a simplified example:

\-root
  |-page
  |-page
  | |-css
  | \-js
  |   |-js
  |   |-font
  |   \-js
  |     \-img
  \-xhr
    |-js
    |-img
    |-doc
    | \-xml
    \-json
      \-html

At some point the tree is traversed, and ZAP requests each of these nodes individuality, allowing it to send additional form data, GET requests, headers and so on. These trees can become massive, which explains why ZAP takes a long time to complete. One can limit or expand the tree by suppyling a max depth or to include other (sub)domains.

The same technique is used by search engines to index webcontent.


Should we fear spammbots that write constructive and helpful posts?

Remember the actual objective of spam bots. Their purpose is to advertise a website, either directly or indirectly through search engine spamming.

A constructive contribution to a website which also includes an advertisement for some product might get annoying. But annoying posts would get downvoted by other users and thus fail the test, so the bots need to be sublime about this. In my opinion sublime advertisement which looks like constructive contribution but is actually just clickbait is even more dangerous because the reader doesn't realize someone is trying to sell them something.

Black-hat SEO in form of link spam (place your link everywhere on the web until Google thinks you are more relevant than you actually are) hurts the usability of search engines and thus hurts us all, so it should be the responsibility of all internet users to prevent it wherever we see it.


..sends a frame with an ACK flag...

I assume that you mean a TCP packet with the ACK bit set in the TCP header.
As long as this packet does not belong to any existing connection it gets simply discarded. Belonging to the connection means that source and destination IP and port match and also the sequence numbers are within a small window of previously received packets.

  ... and then uses the broadcast IP to infect all the network

I'm assuming that you still talk about the same "frame". First, broadcast does not work for TCP at all, i.e. a TCP packet with a broadcast address inside will be discarded.

But even if you use UDP instead of TCP (which means no ACK flag since this does not exist for UDP) the attacker has to be in the same network already since broadcast will only work inside the local network. And, no sane system would reply to a packet which has a broadcast address as source, so it gets discarded and your idea of attacking all systems via broadcast will not work. Still, if the attacker in the local network anyway he can directly attack these systems.


A lot of the security field is devoted to cryptography which is a beautiful field (of which I am far too ignorant) but crypto is often much easier to misuse than to use correctly.  Unless you've got a really strong math/stats background, I'd put off diving into crypto until you've got into the attacker mindset a bit.

If you're already comfortable as a coder, then you can probably learn a lot by reviewing code, including exploits, vulnerable code, and code designed for security.

"OWASP Code Review" might help you learn by example.  It'll introduce you to a bunch of practical attacks, and get you thinking like an attacker.

  The combination of a book on secure code review and tools to support such an activity is very powerful as it gives the developer community a place to start regarding secure application development.

The same OWASP organization has How-to pages that might be good starting points as well.

Other accessible resources include Scheier's blog which often discusses topics related to threat perception, the way social dynamics affect security, and what security means/should mean in various scenarios.


Both setups - publish posts via website and publish posts via local software - requires some kind of authentication. No matter if the user is making HTTP requests through a web browser or some other program, the server will need to authenticate them. If you get that authentication right you will be fine, if you get it wrong, you will have problems. The type of software isn't really the determining factor.

A separate application will give you a bit of obscurity. But I would not focus on that. The authentication is what is important here.


Staying safe, but still connected, at security conferences

There's no reason to use Linux instead of Windows under the premise that one is 'more secure' than the other (this is not a simple query to answer).

Software

If the Laptop you have is running Windows then it's OK to stick with it, just do the following:

Make sure it is fully updated with the latest patches
Enable and configure Windows Firewall
Disable any extra services you don't need (if running an FTP server, etc.)

This won't make you 'unhackable', but nothing will. Choosing Linux over Windows is a fairly arbitrary choice, neither OS will protect you from 0day exploits.

Network

You say you have a company VPN? Assuming it is encrypted this is ideal for this situation. Configure your system to only send network traffic over your VPN.

Assuming this is encrypted then your credentials should be relatively safe.


How can I use the free version of Burp to identify input HTTP urls for my site

You can filter or view parameterised requests (either GET or POSTs). These are shown in the site map. These will show you where input could possibly lead to an XSS or CSRF vulnerability.

However, be aware that XSS attacks can also happen via HTTP headers or cookies, or any other external source of data to the application.


Is it necessary to use PEAP for L2TP/IPsec?

I think you are correct but it would be nice to know for sure. Microsoft KB article (2743314) dealing with MS-CHAP in PPTP-

Unencapsulated MS-CHAP v2 Authentication Could Allow Information Disclosure

Expand Suggested Actions and it says:

  Or, as an alternative to implementing PEAP-MS-CHAP v2 Authentication
  for Microsoft VPNs, use a more secure VPN tunnel

  If the tunnel technology used is flexible, and a password-based
  authentication method is still required, then Microsoft recommends
  using L2TP, IKEv2, or SSTP VPN tunnels in conjunction with MS-CHAP v2
  or EAP-MS-CHAP v2 for authentication.


Will SHA1 of Email Addresses Always be Unique?

The chance of this happening by accident is negligible. It's approximately n2/2159 when you have n email addresses. For example if you have a billion emails, the chance is 2-99 or 10-30.

So assuming that it doesn't happen by accident is a pretty safe bet.
Somebody will be able to craft two email addresses that have the same hash, but he won't be able to craft an email that matches the hash of another person that's not identical to that person's email.

Or as a cryptographer would say, collision attacks against SHA-1 are feasible, but pre-images are not.

But collision attacks seem irrelevant for your application. Since I don't see how an attacker would take advantage of owning two emails with a matching hash.
Guessing the email and confirming it against a hash is possible. The main problem here is that SHA-1 is fast.

I ran such an attack against the MD5 gravatar hashes stackoverflow publishes, and recovered around 28%. Somebody who puts in more effort will probably be able to recover a bit more.

My recommendation is to use an expensive hashing construction such as PBKDF-2-HMAC-SHA-2 with a per-application salt.


How could one say that older operating systems are more vulnerable?

There is one flaw in your premise that since those malware ran on windows 10 but not on 98 and hence windows 98 is safe.
By that logic, I can say that my shell script cleared the contents of a linux box but not windows and hence windows is more secure.

Edit:
Modern operating systems are the primary targets for attackers as most of the users use them. If the features used in the attack are not supported by older operating systems, the attack will not run on them. It doesn't make them secure. The attacker is just not bothered about them.

The main reason older operating systems are not considered secure is that if a vulnerability is found on them, the vendor will not bother providing a patch for it. Their support has been ended.

All other reasons are secondary.


Symantec rooted certificates trust and Oracle Java trust store, is Oracle planing to remove trust as well?

According to Oracle JRE and JDK Cryptographic Roadmap Symantec Root CAs will be removed in April 2019 release:

Date: 2019-04-16
Releases: 12, 11, 8, 7
Action: Distrust TLS server certificates anchored by Symantec Root CAs.


Would it make sense to use Bcrypt and PBKDF2 together?

Mixing the two functions would not really help. Bcrypt and PBKDF2 both have a configurable cost: you are supposed to set the number of iterations at the maximum value which is still tolerable in your situation, given the available hardware and the environmental constraints (e.g. average user patience). If you want to use both function together, then they must share the same CPU budget; in other words, you would have to decrease the number of iterations compared to what you would use in either function alone.

So you do not get something stronger that way; instead, you get a security level which is an average of what you would have got with Bcrypt alone, or with PBKDF2 alone.

Combining two hash functions or similar functions together is good to avoid a catastrophic failure, if one turns out to be broken; but, assuming that both Bcrypt and PBKDF2 are strong, and the question is mostly about performance (both bcrypt and PBKDF2 are about making exhaustive search slower, so this is all about performance). For optimal slowness, combining bcrypt and PBKDF2 is not a good idea.

For the choice between bcrypt and PBKDF2, see this previous answer. To sum things up:

Bcrypt is better if your hardware is PC-like (i.e. has several kilobytes of RAM with fast access). It is harder for the attacker to optimize exhaustive search with a GPU, if bcrypt is used, compared to PBKDF2.
PBKDF2 has NIST's blessing (it is Approved, with a big 'A'). NIST says nothing about bcrypt.
Bcrypt outputs 192 bits, which is fine for a password verification token, or if you just need 192 bits (or less) of password-derived key material. On the other hand, PBKDF2 is a key derivation function and can produce as many bits as you wish, which is good if you need more than 192 bits of key material.


Is TLS 1.0 sufficiently secure for a bank?

What this means is that your bank's server supports TLS-1.0, not 1.1 or 1.2. Versions 1.1 and 1.2 adds some extra features, but that does not mean that TLS-1.0 is weak. In fact the only relevant security feature added by TLS-1.1 over 1.0 is the per-record random IV. This feature inherently protects against some chosen-plaintext attacks, namely the so-called "BEAST attack". However, this attack can also be defeated with SSL-3.0 and TLS-1.0 if the client implements a workaround known as the 1/n-1 split, and Firefox implements it. Also, BEAST can be leveraged only by exploiting a Same-Origin-Policy hole, and no such hole is currently known in current browsers (the two which were used in BEAST demonstrations have been fixed since that time).

For these two reasons, you should not worry about TLS-1.0. In very general terms, it is best when people deploy new protocol versions, so that the new features percolate worldwide; but there is no urgency.

When your bank account gets plundered, it won't be through a TLS protocol hole. Malware installed on your machine is a much bigger threat, indeed.