How do i know that 2ubuntu3.9 has the latest security patches

This is not a simple. Not all vulnerabilities listed on the Apache security page are relevant for the version shipped with Ubuntu. Ubuntu ships version 2.4.18 with backported patches they consider relevant.

The starting point to look what is fixed would be the Changelog and compare it with the list of bugs published by Apache.

But, that a CVE is not found in the Changelog does not mean that the version shipped is vulnerable against this. For example CVE-2018-8011 is considered to only affect Apache 2.4.33 and not the version 2.4.18 shipped with xenial. Similar the information on CVE-2018-1333 and CVE-2018-11763 say that the specific code where the vulnerability is not included in the version shipped with xenial ("not-affected (code not built)").

Thus, in order to know if a specific vulnerability is still a problem with the shipped version you need to dig through the Changelog and if you don't find the CVE there you need to check why it was not fixed, i.e. likely because it did not affect the version as shipped.

  How do i know if my ubuntu apache version is secure?

The basic idea of this question is kind of wrong. That some software is not vulnerable to known CVE does not mean it is secure. If new vulnerabilities get discovered software does not magically gets insecure until the CVE gets fixed: it was insecure before but the newly detected problems were not widely known yet.

There are several factors to look at in order to determine if a software is sufficiently secure for a specific purpose. One is probably the track record of the software: software which is widely used but had only low severity issues in the past is probably more trustworthy compared to software which had lots of serious issues in the past, even though all known issues seem to be fixed know. For example I would definitely not trust Flash even after the latest security patch but just expect that the next issue pops up within a few weeks (it usually does) and that attackers know and already use issues not yet published.

To keep the risk low (and managed) it is also relevant what impact security issues in the software might cause. Limiting potential impact by using the software only for unimportant stuff might limit the risk as does mitigating potential problems by running the software with low privileges, monitoring suspicious activity etc.


Encoding an Address that contains a null byte in a payload

There is a Immunity Plugin mona.py,  developed by awesome guys at corelan.be . you can check  pop/pop/ret  combinations using that . Morever mona.py also provides with a skeleton to convert your exploit module to metasploit module hence porting it there .

Also  try   !mona  suggest to see the exploiting options after placing mona.py in Pycommands folder of immunity debugger . It might suggest you something else as well .

You can use msfencode but encoding will make payload longer and  300 bytes is too less .But you can try to see if it fits .

If non of the above works then you might have to do what Ditmar suggested .


Ransomware (specifically Locky comes to mind) is able to attack unmapped network shares. I am not aware of any malware that is able to mount an unmounted drive, though I imagine that it's not outside the realm of possibility. Most variants I've seen or heard of use a dropper file to download a payload - this payload has the potential to change so just because it's not being done now doesn't mean it won't be in the future.

  I know this isn't a perfect defense since malware that gains admin
  privileges could mount those drives just as easily as I can, but that
  seems like an unlikely thing for malware to do since unmounted drives
  aren't normally of much interest.

I would disagree with this statement. The reason ransomware is so effective is that it manages to monetize data that is intrinsically worthless. Your data matters to you; you're likely willing to pay for it and that's enough to make it a target for ransomware.

I would advise always having a truly offline backup. Back in the day when more people were backing up to tape this was almost always the case, however as many have switched to drives these offline backups are not as common any more. If you truly want to protect yourself you'll have a truly offline backup (unplugged and not network accessible) with a RPO that meets your organization's business requirements.


TLS 39 month certificate limit and Chrome's NET::ERR_CERT_VALIDITY_TOO_LONG error

It should be noted that there's nothing wrong with the certificates from a TLS or x509 point of view. The CA/Browser forum applies to CAs issuing publicly-trusted certificates that subscribe to those guidelines. Not all TLS or x509 use cases involve public trust.

An internal government or enterprise CA, for example, might reasonably choose to completely ignore these guidelines. In fact, if Chrome is applying those rules strictly to non-public certificates it's kinda contradicting x509v3:

  In some situations, devices are given certificates for which no good
  expiration date can be assigned.  For example, a device could be
  issued a certificate that binds its model and serial number to its
  public key; such a certificate is intended to be used for the entire
  lifetime of the device.

Obviously Chrome is under no obligation to accept such certificates, but they are a legitimate type of certificate nonetheless. An intranet user who wants to trust their own intranet CA (say, Active Directory) might find Chrome prevents them from doing so, based on requirements that are irrelevant to them because they don't subscribe to the CA/Browser forum.

It is incorrect to say that an x509v3 certificate is invalid because it has a long expiration date in the general case.

It is correct to say that an x509v3 certificate is invalid because it has a long expiration date when it is being issued by a ca which is expected to conform to the CAB requirements and is consumed by a user-agent which expected to conform to the CAB requirements.

It is therefore important to recognise that there's no intrinsic technical mechanism for determining whether a CA is supposed to be CAB conformant or not. Thus, browsers are left to either:

a) Assume the CAs subscribed to the CA/Browser Forum are conforming appropriately and accept false positives if the CA doesn't conform, for whatever reason.

b) Aggressively reject certificates that don't conform to the requirements in every case, regardless of who the CA is, imposing CAB-style requirements even where they might be actively harmful.

Neither is wrong, I think (unless there's a bit of the CAB that puts an obligation on the browser, I can't claim to have memorised the entire thing word for word - See addendum). What is correct is the SSL testers you've used don't reject the certificates as being inherently invalid. Without any context, it would be wrong to say they were invalid.

The outcomes you've described, then, is exactly what one might expect from these requirements and the answer to the question "Is this an issue with the certificate or a bug in Chrome?" is, in my opinion, the certificate, because it was issued by a CAB-forum subscribed CA that failed to implement their obligations in a non-ambiguous manner, forcing the browsers to make up their own mind about whether to enforce those obligations by veto or not.

Addendum:

  The Requirements are not mandatory for Certification Authorities
  unless and until they become adopted and enforced by relying–party
  Application Software Suppliers.

Chrome (a relying-party Application Sof..... zzzz) have adopted and are enforcing it, thus by the letter of the law we can assert is mandatory for CAs that are dealing with publicly-trusted certificates and are subscribed to the CAB Forum requirements to create certificates that conform to this requirements.

(Unless we're being hyper-pedantic, in which case it's a plural and we'd actual need 2+ browsers to enforce it because otherwise Chrome is only a relying-party Application Software Supplier, not Suppliers.)

I think it's amusing that the obligations CAs are actually bound to changes depending on individual implementation details in every supplier. Any time a web browser or any software associated with the CAB anywhere in the entire world is updated suddenly a CA might have to implement a requirement that they didn't previously.

Thus, until it failed in Chrome, there was no obligation on the CA to conform. The moment Chrome was patched to start throwing this error, the CA was in breach of their obligations. Surprise, MF!


Pros and cons of password policy filtering common weak passwords?

It's not used widely because if you block 123456, users will use 1234567, you block qwerty they'll use qwertyu. Honestly, "The blacklist approach will be bypassed". And this makes the outcome minimal, to the extent that its not worth implementing.

The approach could be beneficial but when coupled with other types of policies like min-length, uppercase, digits, etc. And you see this type of policy in action when systems prevent you from using your last 'x' passwords or alert you that your password can't contain your username. (And a lot of weak passwords are blocked via length/complexity rules)


What's the practical limit for rainbow-table based bruteforce?

Let's say they randomly chose alphanumeric (A-Za-z0-9 no symbols) for both salt and password; e.g., the sample space is (62)^M possible salts and (62)^N passwords.

Say they have a million GPUs in a farm at their disposal that can each generate a billion hashes a second (assuming a simple MD5 or SHA type hashes - bcrypt or PBKDF based hashes are much slower).  So for a given salt, they can crack a 8 character password in 0.2 seconds (200 000 GPU-seconds), a 10 character password in 14 minutes (26 GPU-years), a 12-character password in 37 days (100 000 GPU-years), a 16-character in  password in 1.5 million years (1.5 trillion GPU years).

Or another way to think about it; a typical GPU to crank out a billion hashes a second uses ~200 W.  So if electricity costs you $0.10 per kWHr and neglecting start up costs, a GPU-hour costs $0.02.  So an 8-character password costs ~$1, 10-character $4600, 12-character $18 million, 16 character - $260 trillion (the world's money supply is on the order of $10 trillion).  (And this neglects the cost of buying/maintaining a million GPUs -- just electricity).

As for a rainbow table  -- at some point it has to be constructed.  So you want a complete rainbow table for all 4 character prefixes; and want to cover all passwords up to 8 characters (e.g., total of 12 char password) it will take 100 000 GPU years (37 days of a million GPUs) and cost about $18 million in electric bill.

Basically when M+N > ~12 for random alphanumerics it starts to become unfeasible (e.g., is unfeasible at M+N = 16).

EDIT: New summary table, where I list password length and type (e.g., 8 A-Za-z0-9 means 8 character uppercase + lowercase + numeric password).
Also included is a google application-specific password (16 random lowercase letters) though obviously google type password typically would have to be attacked online (not like an offline hash attacked by a GPU farm).

  PW Length  | # of PW | PW Entropy |       GPU-time | Electricity Cost at $0.10/kW-hr
-------------------------------------------------------------------------------------------
 8 A-Za-z0-9 | 2x10^14 | 47.6 bits  |       60 hours |                  $1
10 A-Za-z0-9 | 8x10^17 | 59.5 bits  |       26 years |              $4 600
12 A-Za-z0-9 | 3x10^21 | 71.4 bits  |   100 000 years|         $18 000 000 ($18 million)
14 A-Za-z0-9 | 1x10^25 | 83.4 bits  | 390 million yrs|     $69 000 000 000 ($69 billion)
16 A-Za-z0-9 | 5x10^28 | 95.2 bits  |1500 billion yrs|$260 000 000 000 000 ($260 trillion)
-------------------------------------------------------------------------------------------
16 a-z       | 4x10^22 | 75.2 bits  | 1.4 million yrs|        $242 000 000 ($242 million)


I'm running Android 4.1.2; it includes known vulnerabilities. Installing a newer firmware image would take time and effort. Must I really do so?

That depends how important is anything you do on the phone. If it is prepaid plan and you only anonymously watch youtube clips and surf the web, the worst that could happen is your phone becoming just another of zombies in some botnet and use up your credits and spy on you.

If it is postpaid, it could build up your phone bill with extra data usage, calls and sms/mms to who-knows-where. If you use it to access email, it could destroy or takeover your email account. If you use it to enter credit card details for online shopping, your credit card could get maxed out. If you are famous person, your pictures and homemade videos could make some paparazzi very happy. And so on. So it really depends.

Another question is how likely you are to be exploited. That is also pretty hard to say. If you drive Audi A7 while under influence of alcohol, how likely is it you'll have an car accident? There is just no way to tell (even if you provide much more detail), and even if we had accurate statistics, they still won't tell what happens to individual.

So, you should assess what is the worst risk that can happen if your phone is taken over, how likely you think that may be, and how much effort are you willing to put in to avoid it. Nobody else can do it for you but you...

About exploits - some are pretty bad, other less so. It depends mostly on your luck... Judging by amount of red stuff there, I'd upgrade if I were you...


Google Authenticator supports both the HOTP and TOTP algorithms for generating one-time passwords.

With HOTP, the server and client share a secret value and a counter, which are used to compute a one time password independently on both sides. Whenever a password is generated and used, the counter is incremented on both sides, allowing the server and client to remain in sync.

TOTP essentially uses the same algorithm as HOTP with one major difference. The counter used in TOTP is replaced by the current time. The client and server remain in sync as long as the system times remain the same. This can be done by using the Network Time protocol.

The secret key (as well as the counter in the case of HOTP) has to be communicated to both the server and the client at some point in time. In the case of Google Authenticator, this is done in the form of a QRCode encoded URI. See: KeyUriFormat for more information.


How to handle sensitive data like API-keys and DB passwords on production

Confirm. For sure those secrets should not be hardcoded in the code. The best would be to have a separate file with secrets encrypted. This file should be stored on some area which is not accessible by the application server (outside its scope).

According to the encryption of data in the config file, unfortunately, I am not familiar with features that Ubuntu has. I am a .NET developer and there was a mechanism presented by .NET Framework which allowed to encrypt parts of the config file (web.config) using a defined key stored on the machine (MachineKey)


Do dynamic certificates for SSL-Interception pose a security risk due to weak entropy?

Yes, there is a risk here, though it is almost entirely limited in scope to the network/users of such  proxy/firewall devices. Low entropy could also have a very minor effect on the client nonce in the TLS handshake impacting outbound connections from the proxy/firewall device.

Low entropy might mean guessable primes, which means guessable private keys, which can lead to viable MITM attacks. If there's a low-entropy issue on such a system, and the CA key is the first thing generated, then you might have a real problem.

(There's an obvious beartrap with such systems if using a shared or vendor provided key/CA, but that's quite a different problem.)

Greater risk is generally assigned to issues of proper chain and revocation verification, and poor configuration leading to the use of insecure legacy SSL or ciphers, see US CERT TA17-075A HTTPS Interception Weakens TLS Security (to this I would add insufficient protection of private keys, at least one commercial product supports HSMs, though I suspect that only works for the internal CA rather than the on-demand certificates).

The potential issue here is that if the entropy is low, the primes may be predictable — but this alone doesn't make the modulus easier to factorise (to determine the private key). It does make a brute force attack viable, in this case brute forcing PRNG input (the attacker knows the PRNG) to attempt to discover a prime (and hence key) that's in use.
If you happen to be an evil administrator with access to such a proxy that you can harvest keys and certificates from, then you have the deck stacked in your favour if attacking someone else's proxy.
As an evil user you might be able to generate enough traffic to find collisions, but this is less interesting.

In practise (certainly the case with OpenSSL) a PRNG is used to generate the key source material (to search for primes), so very little "real" entropy is required. A proxy is generally a good candidate for harvesting entropy from timing and hardware events (potentially busy network and disk, with many random connections).

I estimate roughly 90-100kiB of PRNG output would generally be required for a 2048-bit key generation (2x 1024-bit primes, with a naïve generate/test/discard algorithm), requiring only a handful of non-PRNG bytes of "real" entropy to seed (32 bytes by observation). The delay in key generation is actually the primality testing.

For the implications of low-entropy keys you can read the (wittily titled) paper Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices (PDF).

There are two useful papers which discuss security issues around the use of such proxies:

The Security Impact of HTTPS Interception (PDF)
Killed by Proxy: Analyzing Client-end TLS Interception Software (PDF)

These raise many other security concerns, but randomness/entropy is only referenced briefly in the second one:

  Entropy during generation.
  It is possible that the entropy
  used during the generation of a new public/private key pair
  in install-time generated certificates is inadequate. In practice,
  since most products we analyzed generate a root certificate
  with RSA keys using OpenSSL, the generation process is
  expected to call certain known functions, e.g., RAND_seed(),
  RAND_event(), RSA_generate_key_ex(); we found
  calls to the last function in many cases. However, we did not
  investigate further the key generation algorithm in CCAs.

See also:

Attacks on keys generated with low entropy


Client authentication is for the benefit of the server. Preventing a man-in-the-middle is a distinct matter.

If the key exchange uses DH with a signature by the server (relatively to a public key which is known to the client) then the client is protected from a man-in-the-middle: the client has a strong notion of who it should be talking to, and the signature by the server prevents an attacker from impersonating the server in any way (e.g. as a "man-in-the-middle", which is just a specific kind of impersonation).

Without client authentication, the server does not know who is contacting it. The rest of the protocol (e.g. SSL/TLS) will still provide protection against attacks in the following sense: it will be the same client all along the session, and no other party may spy on the data contents or alter the data in an undetected way. As such, a "man-in-the-middle" (as in: an attacker who acts as a relay, decrypting and re-encrypting data on the fly) is averted, because the client has verified the signature from the server, and therefore used the "right" Diffie-Hellman key, keeping any attacker out of the key exchange.

Client authentication as a signature, computed by the client with his own private key and corresponding to a public key known to the server, could help preventing a man-in-the-middle in a devious situation where the client does not (stupidly) check the signature from the server. Nothing can prevent this moronic client from connecting to a fake server, since it checks nothing and can thus be embezzled at will. However, client authentication is enough for the server to make sure that if the client talks to it at all, then it will do so in a secure way.

The key point here is a matter of definition. What is a "man-in-the-middle" ? This is a case where an attacker impersonates the intended peer (for it to be a "true middle", the attacker impersonates the server with regards to the client and the client with regards to the server). This makes sense only insofar as there is an "intended peer". If the server does not care who is contacting it, then there is no notion of "man-in-the-middle".

In the usual HTTPS scenario, the client is authenticated through a password: the client needs to be sure to talk to the right server right at the beginning (using the server certificate) because the client does not wish to send his password to anybody. The server just wants to have continuity: if it got a correct password through a SSL tunnel then the tunnel is good and will keep on being so.


How can I ensure that I connect to the right wireless Access Point?

Speaking generally
MAC's are easily spoofed.
WEP is cracked in minutes.
WPA/WPA2 implementations are not secure in all routers.

IMO man-in-the-middle attacks are almost unavoidable
The main problem is that the control data in 802.11x is never encrypted.
Because every wireless authentication must start using the unencrypted control sequence, it will be vulnerable to a man-in-the-middle attack.

To make matters worse, 802.11x sessions can easily be forced to disconnect and re-authenticate, so the man-in-the-middle can appear at any time in the session.

By using a radio-beam directed only at the client, it is very hard for intrusion detection systems to intercept this traffic.

Don't worry
The solution to this is to stop worrying about the man-in-the-middle at this or that access point.
Just make a connection with any access point, secured or not.
None of them can be trusted, so don't bother.

The solution
Instead use a VPN solution that is safe from man-in-the-middle attacks*). e.g. SSHv2 in a MITM-safe configuration and connect to your endpoint using that.

What can the attacker do?
Than your attacker can listen in on the stream of data to his hearts content, all he can infer is how much data you are sending and receiving at your laptop (traffic analysis), this is still useful, but he could do that anyway by silently sniffing the wireless traffic.

But keep your laptop safe
You will still have to keep an attacker out of your laptop, employ a firewall that only accepts traffic from your VPN connection and nothing else. Use a secure operating system.

Benefits of this approach
Your laptop will be usable outside the corporate infrastructure. Realistically it will almost never stay inside that safe shell and securing all the access points you want to connect with is a pipe dream.
If you set up a proxy server for web and mail server reachable through the VPN connection you'll have full secure use of your laptop from any and all locations.

To recap
With WEP and WPA outside attackers can spoof your wireless access point.
With WPA2, regardless of encryption used authenticated attackers can initiate a mitm attack regardless of encryption scheme used. This can be done by unreliable insiders or malware on a trusted laptop.
Whilst there is no need to get all paraniod about this as D.W. correctly pointed out.
The bottom line is, there is no way to be 100% sure that you are not connecting to a rogue AP.

Now you only need to worry about that iphone.....

WPA2 has a mitm attack vector called Hole 196, see: http://www.airtightnetworks.com/WPA2-Hole196

*) not all VPN solutions are and lots of them have configurations where an otherwise safe solution is still at risk, but there are safe options and if you have a good sysadmin it is not a difficult thing to setup correctly.


When performing a PenTest against a WAF-protected site, what should a Pentester know to enhance the Test-Quality?

Your approach should be two-fold:

Technical:
Check for:

Various escape sequences (e.g. \x00, %s, \\, etc.)
Unicode tricks (e.g. multi-byte characters that end in 0x22 to produce a ")
Alternative XSS methods (e.g. <img src=0 onerror=alert(1) /> instead of <script>alert(1)</script>)
Various nasties (e.g. XSS, SQL injection) inside of cookies and HTTP headers - often WAFs miss these!

Advisory:
Ensure that the client understands that a WAF is just a sticking plaster, and cannot fix a broken limb. If the application is broken in an exploitable way, a WAF may prevent the attack or mitigate some of the impact, but there is no way to be sure if it will be effective.

It is also a double-edged sword, in that people often assume that a bug that a WAF makes unexploitable will always be unexploitable, and therefore doesn't need to be fixed (at least with any haste). Browsers and HTML / CSS / JavaScript / SQL / XML / server-side languages, etc. evolve constantly, so new exploit techniques may come along that make old bugs exploitable.

One additional point I'd like to make: if the test is aimed at the web-app, and not specifically aimed at the WAF solution they have deployed, then I would highly recommend asking the client to disable the WAF on their staging site for the duration of the test. Leaving it on makes it much harder for you to give them a reasonable estimate of the security posture of the application, and that means they get less value from the test. If they're really interested in testing the WAF, they could do an additional test day afterwards that compares the exploitability of the found issues with and without the WAF being enabled.


Should I authenticate user on every request?

You should be using session management to handle information transfer between clients and servers.

Session management essentially involves authenticating  a user to initially perform a privileged action, with all subsequent activities being authenticated via 'shared' information eg: cookies.

Asking users to authenticate for each and every action might be considered more secure but will heavily reduce platform usability and overall user satisfaction as a  result.

With regards to database load, without seeing the specific application I can't be 100% however I would advise as long as you are logging the last time the session was used, you don't need to write much other information to the database.


You could try to use WireShark on your network and see if there is any traffic passing through from that device, and also see what kind of traffic (ex. is it going through Facebook, Twitter or anything else).


Is using numeric passwords on Macs reasonable for average users?

The security requirements for passwords are independent from the operating system. It's the same for iOS as for any other operating system, because the usual attack vectors are the same.

There are best-practices available for what is considered state-of-the-art password strength. Normally, I would link to one of the standards here, but for a private user like you describe yourself, a simple guideline of 10 characters with a good mixture of letters, numbers and special characters will suffice to be on the safe side.

If you want to follow those guidelines, depends on your risk appetite. If you rather run the risk of getting compromised to avoid entering a more complex password, that's up to you. Companies may be bound to regulations and have to be compliant to certain standards. As an individual, you are free to decide how insecure you dare to be. But please, just for a minute, imagine how it would make you feel, if someone breaks into your system, gets access to all your data, monitors everything you do 24/7 or destroys all your data. Is usability still worth using a weak password? If it is, go ahead, no one is stopping you.

Having said that, limiting yourself to just numbers isn't necessarily bad, if you choose a long enough pass code. A 20 digit number is stronger than a password that uses an alphabet of 60 characters (upper and lower + some special chars) with only 10 characters. You can calculate it yourself, the number of potential passwords is simply the size of the alphabet to the power of password length.


Can a man in the middle hear half the HTTPS conversation

No. A cryptographic system that only protected half of the information would just be slightly better than useless.

During the handshake, a symmetric key is exchanged. After the handshake, that symmetric key is used to encrypt all data (usually with AES). So without that symmetric key you are toast - you can not read 50%, you can read 0%.

When RSA is used for key exchange, the client encrypts a random symmetric key with the servers public key. Since the attacker does not know the servers private key, she can not decrypt it.

When Diffie-Hellman is used for key exchange, it also makes it possible to establish a symmetric key without an eavesdropper being able to get it.


The Content-Security Policy or CSP allows you to create a page of user controlled HTML that does not execute JavaScript, and therefore not XSS.

This is telling the browser not to execute JavaScript,  which is a lot stronger than filtering the output,  and using both will improve security. HTML filtering libraries such as HTMLPurifer, antisammy, safehtml,  have all had numerous bypasses and therefore should not be used as the only means of defense.  These are very complex filters,  and complexity is the worst enemy of security.


Is there a true alternative to using CAPTCHA images?

Thinking outside the box...

In most cases this applies: The business purpose for CAPTCHAs is to identify that the person accessing a page is a human being.  The underlying reason for needing to know it it's a human is to prevent automated form submission, and the main reason for preventing that is to prevent brute force attacks.

So the ultimate purpose of a CAPTCHA in most cases is as a tool to prevent brute-force attacks.

If this is your underlying reason for wanting to use a Captcha, read on.  Note that there are other reasons for using CAPTCHAs, and these suggestions may or may not be applicable.

That said, there are alternatives to CAPTCHA for preventing brute-force attacks.  The OWASP web site lists a few with pros and cons of each approach:

1. Locking Accounts

The most obvious way to block brute-force attacks is to simply lock out accounts after a defined number of incorrect password attempts. Account lockouts can last a specific duration, such as one hour, or the accounts could remain locked until manually unlocked by an administrator. However, account lockout is not always the best solution, because someone could easily abuse the security measure and lock out hundreds of user accounts. In fact, some Web sites experience so many attacks that they are unable to enforce a lockout policy because they would constantly be unlocking customer accounts.

The problems with account lockouts are:

An attacker can cause a denial of service (DoS) by locking out large numbers of accounts.
Because you cannot lock out an account that does not exist, only valid account names will lock. An attacker could use this fact to harvest usernames from the site, depending on the error responses.
An attacker can cause a diversion by locking out many accounts and flooding the help desk with support calls.
An attacker can continuously lock out the same account, even seconds after an administrator unlocks it, effectively disabling the account.
Account lockout is ineffective against slow attacks that try only a few passwords every hour.
Account lockout is ineffective against attacks that try one password against a large list of usernames.
Account lockout is ineffective if the attacker is using a username/password combo list and guesses correctly on the first couple of attempts.
Powerful accounts such as administrator accounts often bypass lockout policy, but these are the most desirable accounts to attack. Some systems lock out administrator accounts only on network-based logins.
Even once you lock out an account, the attack may continue, consuming valuable human and computer resources.

2. Inject random pauses when checking a password.

Adding even a few seconds' pause can greatly slow a brute-force attack but will not bother most legitimate users as they log in to their accounts.

3. Lock out an IP address with multiple failed logins

4. Design your Web site not to use predictable behavior for failed passwords.

As for this:

  I have a registration form to be filled, but I don't want my user
  table to be filled with trash.

In your particular case, I'd go with the a two-tier approach:

First, I'd use the "Inserting random pause" option just to limit how many bogus submissions could be entered in the first place.

To deal with potentially bogus registration attempts, use a verification mechanism.  Register them but not as active, send them an email with an "Activation" link. For those that activate - at least you know you have a valid email address of someone who actually wants to register.  Then implement a scheduled task that automatically deletes un-activated accounts after X hours or X days.


The CSRF attack scenario relies on the victim browsers which are almost always latest greatest.  Having an outdated browser (even a Firefox of few major versions back) presents a greater risk than CSRF due to chances of breaching the browser itself.
The SameSite attribute (and the transition to the Lax value from None by default) guards applications whose UI is hosted by the same host with API or by a sub-host of API.  Such same-site UI hosting turns friendly to own API cookies. CSRF attacks rely on accidental surfing foreign (malicious or hacked) origins. Browsers will ignore SameSite=Lax and strict cookies when these origins send malicious requests to API.  (Surfing through a hacked sub-host of API will send the API cookies, so this less likely chance needs weighing).
The Lax or Strict value of the attribute (or its default Lax value) turns prohibitive for previously normal operation of applications where API is hosted by a sub-host of UI or by a sibling host of UI or by an unrelated host.  These disperse applications turn to using tokens.  Tokens are not sent by the browser's platform authentication in case of a CSRF attack.
I read that only HTTP GET requests were supposed to carry Lax cookies across sites (if resulting from a click, I guess). But the browser vendors permitted fresh Lax cookies to be sent with POST requests for some transitional period.
Finally, from my other reading, I suspect that Microsoft web apps and OpenID authentication implementations heavily depend on passing cookies across sites.  That is, they fail in newer browsers.


Code Change That Resulted in Database Fields and Values Exposed

Security is rarely a binary proposition: whether or not something is a security concern depends on the circumstances.  The sort of security you need for an anonymous cat-picture voting site is different than the security needed for the president to launch a nuclear assault.  As a result, only your development team can decide if this is a security concern.

What is clear is that you can access data.  The next question to decide if this may be a problem is very simple: Are the users in question supposed to have access to this data?

If the data you found is data that would normally be accessible to the user through the application anyway, then it really isn't a problem at all.  There are plenty of situations where you might find info in the Developer Tools that isn't visible on the page, simply because the user hasn't asked to view it yet.  However, If this allows people to access data they aren't supposed to have access to, then it definitely is a problem.


If your bank uses TLS 1.0 with an SSLv3 decoding function, it is vulnerable to a MitM attack using the POODLE vulnerability.

If they are vulnerable, you are no safer accessing online banking from any particular location, the vulnerability is in the bank's TLS implementation.

You can check Poodle Scan to see if their server is vulnerable.


Universal clipboard iOS10 and macOS. How secure?

Personally, I would not put anything truly sensitive there.

Even if you trust that Apple really encrypts its databases, doesn't give away keys or back doors, the algorithm hasn't been perverted by the NSA, the crypto library isn't buggy, it's also secured in transport with perfect forward secrecy and mutual authentication (no MiTM SSL inspection), RAM is randomized and encrypted, you were not on Wi-Fi/Bluetooth, no renegotiation or compression type garbage... then you still need to consider that every time there is a jailbreak, that means someone has discovered a bug that allows them to completely compromise the security of the endpoint's iOS.

It's another tradeoff of security for convenience. Use it wisely. Consider the risk and manage it. For some uses, it's secure enough. For others, it's not.


What is the best way to browse the Internet anonymously?

Best is difficult when you havn't given the parameters of interest.

Get cash.
Get a deck of standard playing cards.
Shuffle the deck of cards at least seven times.
Remove everything from your person except locally acceptable clothing, the playing cards, and the cash.
Walk to the nearest public transit.
Board the first public transit vehicle that arrives.
After boarding the vehicle draw a card from the deck. Use the value of the card to determine how many stops to wait before exiting the vehicle. If the value of the card is greater than the number of stops remaining, then modulo the value by the number of stops remaining.
Exit at the stop determined in step 7.
Board the next public transit vehicle that arrives.
repeat step 7.
When you exit at the stop draw another card.
Ask someone where the nearest internet cafe is. If they don't know or are unhelpful continue asking until you have asked as many people as are indicated by the card drawn in step 11.
If you asked the number of people indicated by the card drawn in step 10 and dont recieve a satisfactory answer go back to step 9.
Walk to the internet cafe.
When you reach the internet cafe draw a card from the deck.
Look for someone who is leaving, offer them cash from the reaminder of their time.
If you don't see anyone leaving wait the number of minutes represented by the card drawn in step 14.
If you wait the number of minutes and do not spot someone leaving, pay for your own session.
Don't use any existing accounts. Don't chat with or email any aquaintences. Don't use any personally identifing information. Use the deck of card to generate usernames and passwords. Use the internet cafe's address and phone number for registration information.
Go home. Do not take anything physical back from the internet cafe. Never reuse the accounts, usernames, or passwords from your session at the internet cafe.


If TCP is more "secure" than UDP, how would a practical UDP "attack" look, for example during the initiation of a MS RDP connection?

UDP is deemed "less secure" due to the fact that it is stateless. When you send a UDP packet, you have no guarantee it will arrive. You also have no guarantee the person sending you the packet is who they say they are. However you are guaranteed that the packet will be routed to the receiver, or lost.

The MS-RDP protocol from my knowledge uses TCP, though there was an option to also use UDP alongside. Authorization itself is performed over TCP. Once access has been granted, UDP traffic will be allowed. Authorization also includes exchanging a key for symmetric encryption, ensuring data confidentiality.

If you want to know how a UDP attack looks, take a look at DNS Reflection Attacks. Because UDP is stateless, it's trivial to modify the source IP address. An attacker can send a small packet to a DNS server, causing the server to send back a response that's much larger than the request. However since the request is forged, the server actually sends the packet to the target system. Do this repeatedly, and you've launched a denial of service attack.


My Laptop has outgoing UDP packets on high numbered ports several times a second

Those UDP packets all seem to go to a public DNS server. Considering the destination port is 53, it is highly likely you are doing DNS queries and not something malicious.


What can I do to prevent BGP hijacking as an admin of some OVH's VPS?

Am I able to do anything to prevent BGP hijacking in the future?

As a client of OVH, you cannot prevent BGP hijacking -- this is more the responsibility of OVH's network administrators. However, you may be able to mitigate the risk by using appropriate security on your network services. For instance, if you are running a web site on your VPS, you can (and should) use TLS to protect traffic to your site.


Is it theoretically possible to deploy backdoors on ports higher than 65535?

No, the port number field in a TCP header is technically limited to 2 bytes. (giving you 2^16=65536 possible ports)

If you alter the protocol by reserving more bits for higher ports, you're violating the specification for TCP segments and wouldn't be understood by a client. In other words, you're not speaking TCP anymore and the term "port" as in "TCP source/destination port" wouldn't apply. The same limitation exists for UDP ports.

That said, a backdoor could instead communicate over a different protocol than TCP or UDP to obscure its communication. For example, icmpsh is a reverse shell that uses ICMP only. Ultimately, you can also implement your own custom transport-layer protocol using raw sockets that can have its own notion of ports with a greater range than 0-65535.


I would suggest that you look into the direction of Trusted Computing. It won't "defend" you, but it might help you ensure that you are booting in a known/secure environment.

There is a load of information available here, just search for TXT and trusted computing.

But for starters, you can ensure this by using a platform with a TPM and Intel TXT, then go a step further by protecting yourself from evil-maid attacks using something like
tboot.

You can also run chipsec on your platform, to run an assessment of your platform. Chipsec is well presented in those 2 presentations:

Platform Security Assessmentwith CHIPSEC
CHIPSEC Platform Security Assessment Framework


Can an iPhone be accessed via a compromised router?

No, compromising the router does not give you access to devices connected to the router. The attacker may attempt to exploit vulnerabilities in the connected devices to compromise the devices too, but if your devices are up to date, this would be very unlikely to succeed (unless you are a high value target for a sophisticated state-level attacker.)

Can someone use my ip address?

In the case of a Wifi router, yes they may be able to use your routers IP (which would be the same as your iPhone's public IP when your iPhone is connected to that Wifi), but that does not mean they will be able to access your iPhone or any accounts you are logged in to.


How effective is iPhone 3GS and 4 device-at-rest encryption?

If you write the application, then you have various options for protecting the files stored on the device. I gave a presentation on this at Voices That Matter this year, but to summarise:

NSFileProtection API lets you use the same device key as the filesystem encryption, but ensure that the files are protected when the device is locked by additionally deriving a second key from the user's passcode;
CommonCrypto and OpenSSL are a bit harder to use, but still fairly straightforward, you control the encryption and can use the keychain for key management;
writing your own encryption implementation would be a bad choice.


How to hide or secure django admin page?

I have heard about IP whitelisting but IP's can be faked

In the real world, it's impossible: there's no way to establish a 2-way communication over faked IP. It's like writing a letter to someone, fake your own address, and expect to hear anything back. The person will receive the letter, and answer to the address you faked, not to you. IP spoofing works exactly the same.

The downside of the whitelist is that you must have a static IP. If your IP changes, you are locked out.

This answer on StackOverflow shows you how you whitelist direct on Django. the idea is to create a Middleware or a Decorator to take care of the whitelist for you. If you are hosting Django behind a reverse proxy (HAproxy, Nginx, Apache, et al), you can use the reverse proxy configuration files for that.

  and also someone suggested that just don't publish it.

You have to publish, or you won't have the admin page. You may choose to keep the admin page unpublished until you need to access the admin page, and them you publish it, do the job you need, and unpublish again. Cumbersome, but works.


How to securely send a password from one app to another app?

From my understanding, this is your threat model: You have two programs, one will execute the other. The first program must pass some secret to the second program. An adversary must not be able to record, intercept, or modify this secret. Both processes trust each other and run on the same system.

The answer depends on whether or not the executable is writable by an adversary. If it is kept in a privileged system path or has at least the same level of integrity as the parent executable, you can be sure that you can trust it not to have been tampered with. When both processes are trusted, the simplest way of sending data between two processes is a pipe, such as stdin. It would also be possible to use shared memory, which is a region of memory a parent process can create that will be shared by its child, allowing for more efficient communication than over a pipe. Unauthorized parties will not be able to intercept or modify the contents of the communication, unless they are able to:

Modify either the parent or child executables directly.
Trick your program into running the wrong executable, e.g. by abusing PATH.
Run as the same user as your program, making it possible to compromise them.
Modify the environment (e.g. LD_PRELOAD) of either the parent or the child.

I would suggest not using an environmental variable. The environment is not meant to be secret and often other users are able to view the environment of various processes on the system. On Linux for example, the environment of any process can be obtained by reading the /proc/<pid>/environ file.


Nikto: this might be interesting... file redirects

Looking at the relevant section of source code:

# request by hostname
my ($res, $content, $error, $request, $response) = nfetch($mark, "/$file", "HEAD", "", "", "", "sitefiles");

if (($res == 200) && (!is_404("/$file", $content, $res, $response->{'location'})) &&
  ($content !~ /<html/i) && ($response->{'content-type'} ne 'text/html')) {
    add_vulnerability($mark, "/$file: Potentially interesting archive/cert file found.", 740001, 0, "HEAD", "/$file", $request, $response);
}

# request by ip
($res, $content, $error, $request, $response) = nfetch($mark, "/$file", "HEAD", "", "", \%flags, "sitefiles");
if (($res == 200) && (!is_404("/$file", $content, $res, $response->{'location'})) &&
  ($content !~ /<html/i) && ($response->{'content-type'} ne 'text/html')) {
    add_vulnerability($mark, "/$file: Potentially interesting archive/cert file found. (NOTE: requested by IP address).", 740002, 0, "HEAD", "/file", $request, $response);
}

We can see that a file is marked as "potentially interesting" if a HTTP HEAD request

returns 200 OK
doesn't return 404 Not Found
returns content without HTML
returns a Content-Type header without a value of text/html


How can you bind a public key to a certificate if the public key depends on the choice of algorithms?

Can the same public key be used with RSA, Elliptic Curve, or other asymmetric encryptions algorithms?

No. The algorithm is inherent in the key.

If not, how is a public key bound to a X.509 Certificate?

It is not bound to the certificate, but it is part of the certificate.

Presumably, you'd have to know the algorithmic choice before determine a public key, and the choice of algorithms is only settled during the handshake.

If the client only offers ciphers1 which require RSA based authentication and the server only has a ECC certificate then the handshake will simply fail, since there are no shared ciphers supported by both sides.
Typically the client shows support for both RSA and ECC certificates in the ciphers though, so that a shared cipher can be found no matter what kind of certificate the server has. And in some cases servers have also both types of certificates.

1 This is a bit simplified. With TLS 1.3 the algorithm for the certificate is no longer in the cipher suite. But there is a signature_algorithms_cert extension. And even this statement is still simplified since there is also a signature_algorithms extension. See RFC 8446 section 4.2.3 for more.


Firewall Showing 1,000's Of Strange GET Parameters Being Sent To Login Page?

This is almost certainly not a DDoS attack. The 1.10.188.0/24 block is a residential IP block in Thailand. A large number of the IP addresses in that range are known for forum spam. You can read a report for one of the IPs in your logs here.

The weird parameters look like cache busters. By putting random words on the end it makes the request unique and prevents an old (cached) result from being returned. A lot of sites and tools use cache-busting for various things. My guess is that they're hitting sites all over the internet to look for forums and other chat features that they can then send spam messages to.


IPV6 Cryptographically Generated Address implementation

http://www.thc.org/thc-ipv6/   a whole suite if ipv6 utilities, but sendpees6 has great examples of how to do CGA against SEND.


Rasberry Pi with TRESOR immune to cold boot and DMA attacks?

The TRESOR kernel patch is for x86 processors, as it uses the x86 debug registers to store private key information (at the cost of disabling hardware debugging). The Raspberry Pi is based on ARM architecture, which is completely different.

I'm not sure you actually gain anything from running TRESOR on a Raspberry Pi in any case - even if it was supported - because the memory on a Pi is soldered to the board. It's not user-replaceable.

Frankly, if you don't trust locks, there isn't much point in installing anything of interest on the site itself: You'd be better off setting up a router, and having the (internet-enabled - maybe streamed via your Pi?) cameras stream content to a server hosted on the internet somewhere. Maybe an Amazon instance, maybe something else in the cloud: How you want to do that is up to you. At the end of the day, TRESOR or not, if someone got in and simply stole your Pi and hard disk, you'd never know who did it, because they'd be holding the only digital evidence. But if that same someone came in and unplugged your router - and got caught on camera in the process, you'd at least have some recorded evidence that you could use.

(Assuming they didn't trip the power breaker for your apartment, first...)

You need to decide what you want, here: TRESOR solves all the wrong problems. If you still want to pursue defence against cold-boot attacks, despite what has been said here, you could take a look at ARMORED, which you could simply view as a version of TRESOR for ARM architectures.


How does the attacker to ransomware get the password?

The attacker can use a form of public key cryptography.  For each victim, the attacker creates a public/private key pair.  The victim's files are encrypted using the public key, but need the private key to decrypt them again.

The private key is only disclosed to the victim once the ransom is paid.


How I can prove that SSH attacks are not from my application?

Linode uses Xen, which means that you not only have an app; you have a whole operating system, complete with kernel and base libraries. The attack comes from your system, so it is completely in your jurisdiction. The attacker entered your system in some way, but once there, if he is at least half competent, he used a rootkit to transform his break-in into a permanent installation. The downside of it is that a rootkitted system will not show up from the inside of the system: the kernel would have been infected and will not show the attack process from the attackers.

(I am using here the assumption that once the attacker entered, he could escalate his rights into root level -- that's the prudent assumption, because operating systems are rarely rock solid against local attackers.)

This implies that your system should be wiped out and reinstalled from scratch; it has been compromised and can no longer be trusted. At that point, you would have two goals:

Understand how the attacker came in, so that he won't do it again on the newly reinstalled system.
Convince the Linode people that you are a victim, not an accomplice.

For the first point, this is a matter of analysis of all the logs and other traces that can be found in your system. So before scraping it, take a full copy of it (preferably, a byte-by-byte copy of its virtual hard disk) for ulterior analysis. But remember that if the attacker is reasonably good, he covered his tracks (that's what rootkits are for). Also, some auditing of your application code would be in order: the attacker entered in some way through one of the externally accessible services of your server, which includes your application. Another possibility is that the attacker guessed your SSH account password (after all, you know that this attacker does run brute-force attacks on SSH logins): on your new system, use a new, bigger, more random password (don't type it on your current system ! It is compromised, thus possibly grabbing password changes on-the-fly).

For the second point, this is a matter of trust and human relationships. You cannot prove that you are not the attacker; but the Linode people know that hijacked systems are an unfortunately common reality. Just exercise due diligence, such as reinstalling the system from scratch: going through that tedious task will go a long way towards establishing your good faith in that matter.


How is using acces() opening a security hole?

It is a race condition. You do the access(), then you do the open(). In the small time between the two calls, the file may have changed. Typically, the file is, say, /tmp/foo. Initially, the file is owned by some user (who is the bad guy of the story), and the target is some root-powered application. The application does the access(), sees that the file really belongs to the user, and thus thinks: "that's fine, it's his file, I can process it on his behalf". Then the bad guy quickly replaces the file with a symbolic link to /etc/shadow. The application has already taken the decision to open /tmp/foo, but when it does, it really opens and processes /etc/shadow.


What is the value in asking for a second password for sensitive operations?

Agreed. Definitely not two factor.

The three factor classes are something you know (a password), something you have (a security token of some sort) or something you are (iris pattern, fingerprint etc).

Whether a second password is of any use depends on your application and environment.

In many ways the 2nd password may be less secure from a social aspect since it is less often used so more likely to be written down. How less secure would depend on whether an potential attacker is likely to be hanging around your users.

If you are worried about a brute force attack then having two passwords would help, but no more than insisting the first was as long as the combined password lengths. Brute force can easily be detected and prevented in your application.

It might offer limited protection from sniffing if used infrequently enough, since the sniffer might not have been running long enough to see both passwords. Although if you are using SSL then it implies either a man-in-the-middle attack, or a compromise of either the users or servers environment. Either way, you have problems.

Asking for re-entry of the original password does ensure that the person who is about to perform the high security function is still the same as the one who logged on. Useful in some circumstances.

Finally, it may give the perception of greater security, which may be of marketing value in some circumstances.

Overall though, the chances are that any increase in security is marginal.


Should hashing hashed hashes colide or not?

Since hash functions have a much larger input space than output space, collisions are a normal feature, and it is expected that every possible output corresponds to a lot of matching inputs.

As a rule, collisions are not a problem for password hashing. The previous paragraph means that, for every hash output (in particular the one stored in the server database) then there are many matching passwords which are all equivalent. However:

to find any single password which matches the stored output, you have to break preimage resistance of the hash function;
to find a second password which yields the same hash than a known password, you have to break second preimage resistance of the hash function.

A "cryptographically secure" hash function with an output of n bits ought to offer resistance 2n to both kind of attacks, so no real problem here. Known a collision in abstracto does not give much power to any attacker: the attacker can use a given password, and he has a "spare" with the same effect; so what ?

As for the reduction of space when iterating the function, see this previous answer. Summary: space reduction does occur, but not below an inner space of size 2n/2, which moreover:

requires a lot of effort to be actually reached;
cannot be efficiently characterized (you cannot easily know if a given value is part of that inner space or not).

Use SHA-256 and be happy.


Is it safe to have the salt equal to IV?

There is no known issue with reusing the salt used in PBKDF2 for the IV of CBC encryption, and it would be mildly surprising if it did have an impact because the salt enters as input to hash functions, and the output is used as key for the block cipher. Thus, there are "two layers" between the salt and the IV. However, surprises do happen sometimes. Reuse of any data element for two roles is, as a basic rule, potentially dangerous.

Since PBKDF2 is a Key Derivation Function which can produce an output of arbitrary length, it seems safer to simply make it generate the key and the IV. That's what is usually done in these matters.

Alternatively, if the key obtained from the password and salt will be used for only one file ever, then you could use a fixed, conventional IV (trouble with IV in CBC begins at the second usage of the key, so it tolerates an all-zero IV if and only if the key is used only once). It would still be better to replace CBC with an Authenticated Encryption mode like EAX or GCM, which has fewer constraints on IV (with EAX or GCM, it is "obvious" that a conventional IV is not a problem, as long as the key is used once) and will give you integrity on top of confidentiality.


How to prevent a click from opening another tab?

This is called a "popunder."  They're essentially very rude pop-ups.  Some would go so far as to call them malicious.
To get around them, try this:

Chrome: Right click the link and choose "Copy link address" from the shortcut menu.
IE: Right click the link, choose Properties, and copy the link address.

Open notepad and paste your clipboard there

Notepad should now contain the URL you want.  Visually inspect just to be sure.

Cut and paste the URL from notepad into your browser's address bar.


Is there any difference between HTTP and HTTPS when using my home / own internet connection

TLS provides three things:

Confidentiality: that nobody can see the traffic between you and facebook.com (including the guy at the next table at Starbucks, your ISP, some sketchy network equipment in the datacentre COUGH NSA, nobody).
Integrity: that nobody is modifying the messages as they travel between you and facebook.com (this is separate from Confidentiality because some kinds of attacks allow you to modify the message in a malicious way even if you don't know what the messages are).
Authentication: that you are talking to the authentic facebook.com server, not a spoofed version of it.

  The basic idea what I got from them is, when using https all things are encrypted in client side and then sent it to the server. (Please correct me if I am wrong)

That covers the confidentiality and integrity parts, but you're missing the authentication part:

  To prove that you're not talking to a spoofed web server.

Say I set up a phishing version of Facebook and I somehow hack into your home router (easy) or ISP (harder) so that when you type facebook.com it resolves to my IP address instead of the real one. I've created an exact copy of the login screen you expect and you'll enter your username and password. Muahaha! Now I have your username and password.

How does HTTPS prevent this? Answer: with Certificates:

If we open up the certificate in my browser's Dev Tools > Security, we'll see this:

DigiCert is what's called a Publicly-trusted Certificate Authority (CA). In fact, DigiCert is one of the CAs that your browser inherently trusts because its "root certificate" is embedded into your browser's source code. You can see the full list of trusted root CAs by digging around in browser Settings and looking for "Certificates" or "Trusted Roots" or something.

So, your browser inherently trusts DigiCert, and, through this certificate, DigiCert has certified that the server you are talking to is the real facebook.com (because it has the private key that matches the certificate). You get the green padlock and you know that everything is good.

Just for fun, let's make a fake facebook.com. I added this line to my hosts file so that any time I type facebook.com it will redirect to google.com's IP address:

209.85.147.138  facebook.com

Google, what'cha doing trying to steal my facebook password?? Thank goodness HTTPS is here to protect me! My browser is super unhappy because the certificate it was presented (for google.com) doesn't match the URL it requested (facebook.com). Thanks HTTPS!


Can I conceal which account in my database is the admin account, so an attacker won't know which hash to crack first?

I would say this is a bit too much trouble considering what you get out of it. I think when the attacker has access to the database you have way bigger problems. Obfuscating the admin status of a user will just cost the attacker some extra time, but an APT (Advanced Persistent Threat) would probably not be deterred by this fact.


What software can be used to read data from smart cards?

In the past, i have used CardPeek for this. It is easily extensible through LUA and can therefore adapt to unknown cards. It presents the "files" on the card via a TreeView and offers annotations on "known" cards for the values.

It also has debugging facilities.


Can we implement custom algorithms to encode and decode wifi password hashes between Windows 10 and our Router?

Don't create your own custom algorithms. This is a trap that novices fall for again and again and again.

If you do, you will fail, because you are not an expert. Good algorithms are designed by people who spent decades on this very material, and the results again are checked by hundreds of cryptoanalysts, trying to find any imaginable flaw.

Your student, without trying to be personal, does not have this expertise. They are likely not even close. As a result, using your own "custom algorithm" will lead you to getting your connection cracked and highjacked, if anyone would seriously try.

How can we make our Wi-Fi secure?

Use a long passphrase! If brute force is your only worry, then use a long password that make brute force infeasible.

Use a password like .;{mr%chKzc<Z44aZ&+NV&uW!PuA5!CkJLA8*=c546/7'>,;{3@2w4x]9N}f?Da and you will be 100% safe.


Why is my Windows desktop using a DNS Server on localhost?

First, no, this is not default Windows behavior.   Windows client operating systems do not ship with a DNS server.   (Windows Server-based operating systems do, but not desktop/client OSes.)

Second, yes, you probably want to find out what service is listening on that port and take a much closer look at it.  Step one is to run netstat -a -b from a command prompt or Powershell.  This will list all of the current open connections and listening ports, and the applications associated with them.  This should allow you to figure out which application or service is listening on UDP 53.

The fact that its running its own DNS server is not necessarily an indication of malware, but it certainly could be malware, so I wouldn't ignore it and would want to investigate it to understand it better.


ISO 27001, Skype, online CRM... compatible?

Whoever has said that you cannot use some specific technology because of ISO27001 probably has some other vested interest - possibly even just laziness. The standard does not mandate what you can and cannot do. It effectively defines the way you need to manage risk and how you need to demonstrate that you are managing risks.

There are many organisations who are compliant and who use Office 365 or even Google Work. Even more that have all manner of external communications from Skype to Slack, etc.

What matters is having a robust process for identifying and acknowledging the risks and mitigating them.

A specific example may help. Though not directly related to ISO27001, there are a number of doctors in the UK who are holding patient consultations over Skype. That requires certified risk management well beyond that normally expected from ISO27001 (think the UK equivalent of the US's HIPPA).


How to protect user privacy when sharing photos?

To answer this question, it is necessary to know what information is stored in the photo. Different cameras and phones collect various metadata fields. These fields are collectively known as "EXIF" data.

There are quite a few tools that are capable of reading and parsing EXIF data. An incomplete list is available here:
http://www.forensicswiki.org/wiki/Document_Metadata_Extraction

In general, any personally identifiable information is a good idea to strip from the photo.

Once you have a list of fields you want to strip, you can select an EXIF editor from the following list and remove the desired fields:
http://en.wikipedia.org/wiki/Comparison_of_metadata_editors


Is booting from a freshly downloaded linux CD safe from trojans?

Interesting range of questions here, which you may need to address separately.

Is booting from a freshly downloaded Linux CD safe?

Relatively safe, as long as you download from reputable source and check the hash you can be confident it hasn't been tampered with in transit. There is a small chance the source may have been tampered with, so you should be aware that you can't guarantee 100% security.

Can malware jump hosts via BIOS?

Theoretically yes - but I don't know of any in the wild that does this...yet. You'll be pretty safe here

How can I ensure the BIOS is clean

Not easily - a good BIOS rootkit could subvert updates and overwrites, so this will be very difficult to do.

Dual boot systems

What do you mean by this? Dual boot can be effective at separating the operating systems and is possibly preferable to running a CD boot each time you want to use Linux. Depends on the risk profile.

Back to your stated use - you want to do this to store Bitcoin on your computer. If you use your Windows OS to mine/trade bitcoins the added security of booting into Linux to store these coins is minimal - your Windows OS caches so much data anyway. So I wouldn't bother.


With either rotary or touch tone dialing, if you can hear it then you know what was entered. The ticks/tones are designed to be unambiguous to the recipient.

So, any listener can recover the digits easily. Modern attackers will capture and analyze the audio, and the tones were designed to be distinctive to equipment from the 1970s/80s. Some old school phreakers can do it by ear.

All of the phone networks---POTS (landline), VoIP (internet), and SS7 (cellular)---networks have serious vulnerabilities. (Note there is a category link on that summary page.)

These security issues are on top of the fact that law enforcement, spy agencies, and corrupt employees/officials can tap the phone lines.

There is little security, and a lot of it is broken. Properly encrypted email is far more secure than standard phone calls.

As a general rule, phone- and SMS-based security processes are inadequate. They provide the appearance of security, but they will stop only low-effort or unskilled attackers (which, honestly, is the largest group of would-be attackers).

If someone targets you, they can get those credentials relatively easily. In this case, the biggest risk factor is the likelihood that you will be targeted. For most people, that risk is quite low.


An alternate approach and a legitimate one is to simply use a random Class 4 UUID1.

This way you detach your keys from any changes in material circumstances and any shifts in your privacy attitude in your personal or professional life.

If you intend to use key servers so that people may contact you securely from the onset (instead of sending a signed "hello, we should have a private conversation" email and harvesting the public key in the reply) then put in the least amount of information necessary to locate you in a directory. This information has become public and may of course change.

Using a random ID approach has several advantages:

You are not disclosing information in advance of communication. Information disclosure occurs progressively as you know the other person better. Which reflects real life.
You needn't rely on public key servers if you don't want to.
Verification that a key is controlled by a specific real person or organisation can be kept separate from otherwise pseudonymous communication. For instance you could disclose at your discretion a named photo signed by a classical key signing party or disclose a CA-signed x509 identity certificate with your GPG UUID in a custom field and cross-signed by your GPG key.
It encourages people to recognise just how weak the verification process underlying secure emails is2 and adjust their expectations of confidential communication accordingly.

To be honest, most email communication is not and will not be encrypted due to a lack of popular interest and support for it (the network effect). Asymmetric key pairs for unsolicited yet secure contact with people you don't know is a nice to have feature most people will never use; and your friendly neighbourhood shadow agency will simply break into your house or mobile phone instead. So don't put a lot of effort or personal information into one of these keys.

Although some OpenPGP tool-belts have implemented presumptive de facto behaviour that may choke on keys missing certain metadata; despite said tools not being seamless in the first place.
Public keys are not inherently linked to a real individual or organisation. The verification kludge that Netscape concocted in the early 90s has proven quite inadequate from a security standpoint. GnuPG/PGP's optional web of trust is both less prevalent and more honest than S/MIME certificates. For both x509 and OpenPGP-compatible keys,  underlying trust is being automagically bootstrapped from the void; PGP is simply more honest that this is happening.


Any threats from isolated subdomain (controlled by hacker)?

Based on the few details of this setup and some guess work what you might use this setup for the following problems come to mind:

with local privilege escalation exploit one might break out of the chroot and affect other users on this system.
if used in a web context it is possible to set/override cookies into the others domain and thus change the behavior of the application
similar other restrictions on the main site (like content security policy, CORS...) can be too lax in include the subdomain which might be used in attacks.
depending on the CA and the control the user has over the domain (can change web sites, email...) it might be possible that the user can get a SSL certificate for the subdomain and also for the upper domain too.


How can I extract the MD5 hash of a password protected MS Office Word 2000 document?

You link the word97 specification for your 2000 document.  I'm not sure if the file format changed, but luckily the encryption is the same.
I don't think you need the md5 hash (if there is one), you just want to break the encryption.  It looks like there are word 97/2000 decryptors on the web (paid or freeware).  My basic google search indicated that it's easier to break the proprietary hash + encryption (partially rc4) than to brute-force the password.
I wasn't going to link the page, but it wasn't hard to find.

Initially a unicode password is taken and some bytes appended, this password is passed through a varient of the standard md5 hash algorithm.
The non standard hash is tricky, and Im far from sure what benefit over standard md5 the modified md5 hash has.


As with all things in security, using HTTPS is a trade-off.  You're trading some performance and potentially customer inconvenienace for improved security and other possible benefits (for example google boosting the ratings of SSL enabled sites).  Only you can answer whether that's worth it, as only you know what your site does and whether the trade-off is worth it.  As a rule of thumb, I'd say that if you're processing any personal or sensitive data for your users it's likely worth it. If you run a purely static brochureware site it's likely not. One thing is, if you do do HTTPS (e.g. because you have a logged in section) do it all over the site, not just in places.
In the general case it wouldn't be possible for attackers to inject code into your site,  but the full picture could be more complex than that, depending on what your site does and who is likely to attack it. Safe to say that in most cases it makes it a lot more difficult for this to occur.
HTTPS generally does not protect against CSRF attacks.  If an attacker can cause a logged-in user to take an action on your site, the fact that the action is taken over an encrypted connection does not, in and of itself, make that any different.


Can a hard drive be destroyed by drowning?

Special firms either degauss, destroy or melt the harddrives.

Harddrives are magnetic data. Magnetism can be destroyed by either:

Degaussing (changing the magnetism)
Heating the drive (melting) (which destroys/changes the magnetism)
Hammering (shock) (shock damages magnetism somewhat, but the denting of the drive makes it very difficult to read the surface, as metal deforms, the surface area changes as well thus making it even more difficult to determine what is and isn't a sector)
Drilling (removes sectors altogether, physically changes the layout of the drive like hammering, generates a large localised amount of heat as well)
shooting (same as hammering, but more extreme)
Chemical corrosion (if the magnetic substrate is removed from the platters altogether, there's nothing left to recover)
Shredding, there's plenty of services that offer to shred your harddrive which leaves you with nothing but metal scraps, nothing to recover there.

So, Would simply submerging the drive render it un-usable? No. Probably not to an experienced forensics or recovery team. What WILL kill the drive is corrosion of the platters, so it depends on what you add to the water, how long it stays in there, what the platters are made out of and how good the people trying to recover the data are.


'Continue experiences on this device' group policy

This policy setting determines whether the Windows device is allowed to participate in cross-device experiences (continue experiences).
If you enable this policy setting, the Windows device is discoverable by other Windows devices that belong to the same user, and can participate in cross-device experiences.
If you disable this policy setting, the Windows device is not discoverable by other devices, and cannot participate in cross-device experiences.
If you do not configure this policy setting, the default behavior depends on the Windows edition. Changes to this policy take effect on reboot.

https://getadmx.com/?Category=Windows_10_2016&Policy=Microsoft.Policies.GroupPolicy::EnableCDP
This is probably the description listed from the group policy editor description. Cross device experience is a network service that lets users continue where they left of on another device. It may (probably) have security problems, and it can have security implications with regards to different devices for different tasks, so it may be desirable to disable in some scenarios, whilst it may be unproblematic in other scenarios.
If you don't set it, the default value will depend on the windows edition.


What's a secure way to prompt for a password and erase the cached password afterwards in Linux?

I don't think you will be able to guarantee that.

So, let's assume you have a command that takes the password in a prompt, eg.

  echo mypassword | cryptsetup luksOpen /dev/disk volume`

And want to ask for the password once and open several volumes:

#!/bin/sh
set -e
read -p "What's the password? " password || exit 1
for disk in disk1 disk2 disk3; do
   FOLDER=/media/$USER/$disk
   echo "$password" | cryptsetup luksOpen /dev/$disk $disk && \
   mkdir -p "$FOLDER" && \
   mount /dev/mapper/$disk "$FOLDER/$disk"
done
password="xxxxxxxxxxxxxxxxxxxxxx"

This shell script would do. Except that, after bash finishes, and the memory is returned to the system, we have no guarantee that the password itself is not still in memory somewhere (no, despite that last statement your shell may not overwrite the location where it was saved).

So, we could rewrite this in C, and manually ensure that such location is overwriten, using something like memset_s (yes, a normal memset wouldn't do).

Still, there could be copies of the plaintext password in the stdio buffers, the ones used by cryptsetup, etc. The kernel will not give such pages to other programs without first zeroing them, but if a forensic investigator came freezing your memory slots with nitrogen and dumping it contents, it could still be there.

Moreover, the actual disk key (decrypted from the passphrase) will be in memory, for as long as you have the volumes mounted. So, it is probably not worth insisting on ensuring that much, and just letting the program finish would be acceptable.

I would suggest encrypting the main disk partition (and swap, of course), and have keyfiles for each of the other disks on there (they can be readable just for root). Thus, you only need to enter one password (at boot time) and will be able to decrypt all disks. There are no encrypted passwords laying out when the system is powered down, and if an attacker got root your system so they would be able to steal your keyfiles, he could access the files directly as well (and do too many other nasty things), so it doesn't make things much more insecure.

The main scenario for that I can think is where repeated access is obtained, eg. your encrypted disks are cloned, and later (after you shreded some secrets from them), they obtain your passphrase/keyfiles, thus being able to decrypt their earlier copy. They could probably do that as well by extracting the in-memory disk keys, but the existence of the keyfiles make things simpler. (In order to avoid this, change your passwords and keyfiles and rekey the disk after removing the Coke secret formula)

Hope this helps


Abilities of my ISP to stop me from browsing

Yes, ISP's have the ability to arbitrarily block or throttle traffic based on the source of the traffic, or other factors.  This is what net neutrality aims to prevent.  See https://en.wikipedia.org/wiki/Net_neutrality.


Obtaining an S/MIME certificate without disclosing my private key to the TTP

It's not standard for a commericial CA to insist on making your private keys.  For reasons you mention.

Here's a link pointing to a collection of CA providers that suggests (and rightfully so) that the typical thing is for your browser to create the key pair and then send the Certificate signing request to the CA.  In my experience with high end Verisign Certificates, that is true.  I never tried the free/cheap solutions.

Keep in mind, even when the CA walks you through a browser based request, you may very well have the private key stored purely on the browser - CA companies spend a certain amount of effort on browser compatibility testing to make that possible.  Don't assume that the server is generating the key just because you are using a browser.  Unless it provides "key escrow" my experience has been that this is unlikely.

For the most part, my experience with CA companies has been that they REALLY don't want to take in errant form factors - if you want to send a homemade request for certificate siganture, you are likely to need to find a service that costs more... the reason is pure cost - there's usually a lot more hand holding involved in this approach as the ways to mess this up are numerous and a "generic" certificate request often has to be messed with to meet the security policy and settings required by the CA.

If you absolutely must generate certs with OpenSSL, I'd say look for server provisioning options that let you configure it to look like an S/MIME certificate.  Prepare to pay server cert costs.

If not, double check the process and verify that keys are generated on the browser.


What security risks are associated with DLP Systems?

The most predominant issues with DLP I currently see are in regards to what it can actually retrieve. Often this already omits encrypted connections such as HTTPS (unless SSL certificates are used to implement a MiTM).

Furthermore there are some legal issues in most European countries regarding privacy and proportionality of collecting data which is one of the biggest reasons DLPs are not really selling over there.

There are some strict guidelines regarding data retrieval and processing in the EU:

Notice—data subjects should be given notice when their data is being
collected;
Purpose—data should only be used for the purpose stated and not for
any other purposes;
Consent—data should not be disclosed without the data subject’s
consent;
Security—collected data should be kept secure from any potential
abuses;
Disclosure—data subjects should be informed as to who is collecting
their data;
Access—data subjects should be allowed to access their data and make
corrections to any inaccurate data; and
Accountability—data subjects should have a method available to them
to hold data collectors accountable for following the above
principles.

In comparison to the US for instance, if a European employee has a folder on his computer titled "personal", even on a company machine, the data within this folder may not be accessed. The definition of personal has also been kept quite broad allowing for wide interpretation. And personal data is not allowed to be processed unless certain conditions are met:

Transparency (subjects should always be notified what data is being processed)
Legitimate purpose
Proportionality (When sensitive personal data (can be: religious beliefs, political opinions, health, sexual orientation, race, membership of past organisations) are being processed, extra restrictions apply.)
The data itself can also not be sent to other countries outside of
the European Union, unless certain conditions are met

Violating (even accidentally ) any of the above rules will make you legally liable and can cause a lot of hurt to your company. So a machine collecting almost everything which passes over your network (and which decrypts SSL streams) is a real risk if something goes wrong with the data it collected or if someone decides to take a peak in it, as your company will be held responsible for it.


This kind of attack where spam links are inserted into page content will usually target a particular technology whether that is the site platform eg. Wordpress or a plugin used on the site for instance an image gallery or file upload script. By targeting a specific vulnerability in a widely used script an attacker can compromise enough websites to make the attack worthwhile.

Rebuilding the site from a known clean backup is the only way you can really be sure that you have repaired all of the damage. Then you will need to identify how the site was compromised in the first place otherwise it will almost certainly happen again. The most likely culprit will be scripts that allow users to upload files as if these could potentially be exploited to allow a malicious script to be uploaded and run.

Another possibility, if the website has been hosted on a server with one or more other sites , is that one of those sites was compromised and that giving access to the server and therefore your site. Hosting the site with a shared hosting company isn't necessarily going to protect you from that vector. Even some of the really big shared hosting companies can be pretty sloppy when it comes from protecting your site from others hosted on the same server.


Can hand/finger movements be determined via changes in WiFi signal strength?

The advice, while based on the fact that 2.4 GHz WiFi behaves like radar (in fact, their frequencies are similar), does not mention that there are other, easier ways for a local physical attacker to detect the actual keystrokes being entered. An attacker close enough to pull this off could use the simpler, easier, and more accurate technique called acoustic keyboard eavesdropping. This attack involves using a very sensitive microphone to pick up the unique sounds made by each key on a keyboard as it is hit and using that signal to reconstruct, with high accuracy, what keys were actually pressed.

If they could not do that, then they could use Van Eck phreaking, a technique often referred to by the codename TEMPEST, to eavesdrop on the electromagnetic signals emanating from the keyboard, usually signals coming from the microcontroller or cable from many tens of meters away. This technique can be done on both PS2 and USB keyboards. There are keyboards immune to this, but they are expensive and specialty devices that are not easy for a consumer to obtain.

However, it's important to point out that 2.4 GHz WiFi, even when used as radar, has very poor spacial resolution. After all, the wavelength is 12.5 cm. This means it would take a lot of clever tricks to use it to analyze something as small as a finger. Even if that could not be pulled off, the simple fact is that an attacker near enough to try such an attack has better ways to get your keystrokes.


Can one sidestep Meltdown/Spectre vulnerabilities by not installing new software on a server?

No.
Meltdown and Spectre make any vulnerabilities ten times worse. If an existing program (which you'd stop updating if you tried this) had a known vulnerability which enabled any sort of remote code execution (even as nobody) then an attacker could use Meltdown to escalate to root permissions. Patch your systems.


Store basic oAuth for a session on a website

Maybe you can try the sessionStorage API of the browser to store base64 auth string. Like in some banking websites, you can prompt the user to enter the auth string once they logged in, encrypt the string using the public key of your server and store it in sessionStorage. With each API call you can pass along this encrypted string and decrypt it at your server to perform whatever logic you want.

Once the user is logged out and the browser closed, the value stored in sessionStorage will be removed. Till then the value will be present in your browser storage.


Password and Login verse very long string (token)

If you were to judge purely based on character size and wanted to compare a 24 character username and 24 character password system vs a 128 character token system, I would say that the search space would be larger in the token based system.

Obviously, to brute-force a username/password combination, the user needs to find a pair in two n^24 search spaces while in the there are several elements in the n^128 sized token search space that will be valid tokens. As a result, it can happen that your brute-force system does find a token before it can find a valid username/password pair. But finding all valid username/password pairs will take less time than finding all valid tokens.


What mechanism does Firefox use to remember the in-session logins, after entering the Master Password?

The password database isn't encrypted directly with your master password, instead a hash of the master password is computed and that hash is used to encrypt/decrypt the password database.

After you typed your master password, Firefox doesn't store the plaintext password anymore and instead simply use the hashed password to access the file.


Web App Scans scans through the network firewall?

Some webappsec scanners are actually slower than one user using one XP-based web browser.

If Burp Suite Pro Intruder (or Scanner or Spider) is tweaked to over 100 threads, say 175 threads, then things start to fall down, but usually the memory of the target servers before load balancers or firewalls in-between. The max used to be 175 threads but changed to 999 threads in 2014.

Some software-based firewalls will fall under the load of an extremely-cruelly tweaked webappsec scanner, but not appliances or hardware-based ones. For example, a Palo PA-3020 will still push traffic to destinations if you had 20 or even 30 penetration testers using webappsec scanners. However, a Palo VM-100 might only fall to 2 or 3 penetration testers because it's mostly software-based.

WebInspect, AppScan, and Acunetix are nicer than Burp Suite Pro Intruder's maximum configuration (e.g., WebInspect only allows a max of 80 concurrent threads). Even when I tweaked these other scanners to max threads supported by their configuration, the worst that has ever happened was that a web server or two would lock up. Never had a WAF, IPS, or load balancer lock up in that same way. Pretend this has happened to me ten times in my life and that half of the time one web server locked up and the other half of the time two web servers locked up. Every time, no matter how many web servers locked up -- the root cause of failure was due to the web server only having 256M, 512M, or 768M of vDRAM. In every instance these were guest OSes of a server-virtualization based hypervisor or a shared-hosting environment. It was simple enough to ask the far-end IT System Administrator to shutdown the server, give it some more vDRAM (usually 1G was enough), and start it back up.

Usually the best way to determine if there is a problem is to host your pen-test infrastructure (your attacking hosts) with a gateway running Linux. Then, you can leverage ntop or tcptrace to look for retransmissions. If you're not getting any retransmissions, or a very-small amount, then no harm, no foul. Sometimes you will see tools abbreviate retransmissions as retrans, rexmit, or rexmt. Check out the book, TCP/IP Illustrated, Volume I: The Protocols, Second Edition for more information about the inter workings of TCP.


When reading PGP or other encrypted emails, is it wise to unplug my computers ethernet in order to use my private key?

I assume we want a deterrent against software-only attacks targeting the passphrase, unauthorized use of the private key to decipher or sign, or unauthorized access to deciphered data (including emails).

It would be effective to:

Disconnect from the internet
Make a full backup
Use PGP/GPG with private key and passphrase
Fully erase the machine (can be combined with 5)
Restore the backup
Reconnect

But without 2/4/5, disconnecting from the internet is only mildly effective. In particular, a software keyloger targeting the passphrase, or malware keeping track of deciphered data, has a fair chance to do its thing then exfiltrate the result after 6.

Problem is, 2/4/5 is a pain.

One reasonable option is to perform 1/3 in a Virtual Machine, and destroy it afterwards (or equivalently, restore a snapshot made before 1).

Booting on a live CD (assumed malware-free) is a nice option, but since there is no Windows live CD AFAIK, this won't accomplish much of what a Windows user want to do if HD storage is encrypted, or data (like emails) in a Windows-only format (Outlook..). The only reason I see to disconnect from the internet on top of that is to prevent exploitation of a vulnerability on the live CD.


How can I secure my api to avoid copying?

The first thing you should do is to ensure that all communication between your app and the server uses HTTPS rather than HTTP. This should protect you from casual packet inspection. To make this setup more secure, you may also consider using certificate pinning to prevent any man-in-the middle attacks involving a forged certificate for your site.

If you are using SSL, the contents of the GET request will be encrypted (though the fact that you are making a connection to your server will be evident). Your real problem is that if you distribute the app to the general public, it can be reverse engineered and any API key you use can be extracted. You can obfuscate the binary, but this cannot totally eliminate the possibility of reverse engineering.

Depending on your app, and the nature of your data, you may want to worry more about authenticating the users of your app, rather than the application itself.


In Buffer overflow exploitation what if JMP ESP address contains bad characters?

Find a different pivot, such as call esp or pop eax; call eax; maybe a blind ret will work. There are several other alternatives to jmp esp, you just have to find one that works for you.

If you control a value in any of the other registers you can usually find a gagdet that will call the registry at an offset f.ex: call [eax+0x16]; and adjust the value in said register to point to jmp esp with the offset applied.


Is this code vulnerable to a CSRF attack?

An attacker cannot set cookies for a CSRF attack.  The only thing the attacker can do is force the victim browser to make a request to the target webserver.  Assuming you've got code server-side which is comparing the "CSRFtokeneditcustomer" field in the form and comparing it to the value in the cookie, you should be safe from CSRF.


Can I calculate the derived key generated by pbkdf2(password || SOME_TEXT) if I know pbkdf2(password)?

PBKDF2 does not (generally?) use two salts (salt and pepper). You need to understand that PBKDF2 is based on a PseudoRandom-Function (PRF) typically HMACSHA1.
It then proceed to compute the derivated key (what you call your hash I suppose) by iterating (gross simplification) :

Uc = PRF(Password, Uc-1)
where U0 = Salt || INT_32_BigEndian(i)

So in the standard PBKDF2 scheme, you can't guess the password by having the derivated key and the salt. However, if you had the derivated key, you don't need the user password as it is the derivated key which is relevant to any subsequent encryptions.
I am afraid you are mistaking PBKDF2 with another function.
You then get a derivated key which is to be used has a key to other encryption function. Are you sure it's PBKDF2, and what is the underlying PRF?


Is it acceptable to share private SSH keys across servers for read-only access to a Git repository?

If your only use-cases are cloning and pulling, the ideal way to share a bitbucket repository is indeed with an access key, previously called a deployment key.

These keys give read-only access to the repository, so an attacker who infiltrates any one of your servers do not get push access to your repository (which could have severe effects), they do however obviously get access to your code, and a key to clone and pull the repository.

It's better practice to use separate access keys per server since sharing the access key would mean switching the access key on all the servers if one server gets infiltrated. In contrast, using one access key per server means if one server gets infiltrated, disabling that one access key removes access to your repository from the possible attacker.


Is it worth reporting a asp.net runtime error?

The best practice for web applications is to not reveal any unwanted information to the outside.

A custom error message should be displayed on any errors. You can let the developers know.

However, these would be just informational findings.


What is the most secure way to create a REST consumer in a MS word/excel (2013) document

A .NET application is more likely to be securable since so much effort goes into the security of it and there are many options.

VBA on the other hand is only designed to provide some level of automation to Office, usable by power users more than developers. It doesn't get updated much and has a rather weaker security model.

Having said that, I'm not sure how much difference you would see in the real world. The main problems with VBA, at least in enterprise type environments, is that the security model is so untrusted, it can be difficult to get IT departments to allow VBA to run at all.

So it is really down to the environment in which you need to run it. You need not just to think about the security but also how it will be delivered to client computers, how it will be maintained, what restrictions will the client PC's be operating under, how many different configurations will you need to support and those kinds of issues. No point in having something secure that can be maintained in the actual end-user environments.

Particularly note the issue in your second link about having not added a reference. Remember that this has to happen on every PC and that references can change with changes and updates on the PC. This makes supporting VBA applications fraught with problems.


Using sqlmap for SQL injection vulnerabilities in Vaadin

Sqlmap does not see any injectable requests.
Vaadin heavily relies on client side JavaScript.
This is very common with current frameworks.
To get a better idea take a look at the W3C's Usage Patterns For Client-Side URL parameters .

You could try to log the request from the browser via the developer tools or use, e.g., ZAP. From there you should be able to identify the right request. I would also recommend to manually validate the SQL injection vulnerability with ZAP. Then you can be sure that you exploit the vulnerability and try sqlmap with that request.

Also, be aware that Vaadin utilizes CSRF tokens that might screw with automated attacks.


As many as you would like. It's basically a question of paying for them. With IPv4 it's expensive, but still trivial. I can probably access a few hundred for a few dollars through a VPN provider.
With IPv6? As many as you would like - for free. I currently have a /48 (2^80 addresses) at my personal disposal...