Certificates and Certificate Authorities with keys smaller than 2048 bits are not a good choice for new deployments. Unless you have a very specific need for this with some very old hardware or software, there is typically very little impact using a 2048-bit or higher key.

If performance is a concern, and especially on embedded/mobile/low power devices, consider using Elliptic-Curve keys instead of RSA. There are some good guides on how to achieve this.

Mozilla has already started plans to warn users of small RSA key lengths in 2015, and warning for CAs using small keys are already popping up in browsers. Warning for the certificates themselves will start appearing in browsers soon. Deploying anything new knowing this is coming up is not advisable.


Is there a standard about storing the password of a bank's website bank-account-management-account in a password vault?

There are different approaches to storing passwords, and it might vary according to your threat model, your affinity with relevant technical tools, and the frequency at which you query the passwords.
There are hardware options, and software options, and in-usage it seems people adopt a combination of both. The standards can vary from using an air-gaped machine, on-device key, and access management protocols, to simply using a software password manager (I assume you mean password manager by the term "password vault").
You could take a look at several sfotware tools that can help you store your sensitive passwords (i.e. bank creds). From the top of my minds, I would recommend KeePass, Password Gorilla, Mozilla Lockwise, or simply your in-browser password manager. Qubes OS handles this in a more use-friendly manner, but it still requires a relatively advanced technical knowledge.
I would recommend this short read on the potential flaws of password managers, here.


Disable 3DES (Triple DES) in thunderbird

If there would be a way to disable DES3 for this purpose in Thunderbird it would probably be a note on the bug report about it, which isn't. But instead of crying about the insecurity of 3DES let's look at how insecure it is in reality when used together with S/MIME.

The prominent attack against 3DES and other 64-bit block ciphers (like Blowfish) which led to treating these ciphers as insecure is Sweet32. This attack is based on the idea that one can decode part of the traffic provided that the content (plain text) of two blocks is the same or that part of the content is known AND that Ci (derived from IV and previous data in CBC is the same.

This condition is not unlikely with HTTPS traffic because of the properties of the HTTP protocol: a new request and response header will always cause a new encryption block to be started and the request and response will often be the same if the same resource is requested. Thus the weakness in the short block size combined with the properties of HTTP made it practically possible to extracts some secrets (like session cookies) out of the traffic. In experiments this was reached after about 600 GB of traffic but if we deal only with repeating always the same block of data it might be possible with 32 GB. Note that these 600 GB must be done inside the same TLS session, i.e. the same key must be used for all of this traffic.

From this can be seen that this attacks works only if the same key is used for a very large amount of data where a major part of the data repeats again and again so that in a large part of the input data the plain text content of the 64-bit blocks is the same. While such conditions can be created with HTTPS traffic it is highly unlikely to get this condition with mails: While one could imagine mails where the content of a attachments repeats again and again it is unlikely that enough input data for the attack are available since the size of emails is usually only a few MB and not lots of GB as needed for the attack.


You should place the below script in the ROOT directory of the PLUGIN (i.e. the one that contains the file 'PageProtectionPlus.php'.

The script takes one argument - a filename which contains your 'Cryptogramme', i.e. the block of text you provided above.

The script is anything but fast, but in my tests has been able to Encrypt and Decrypt text.

<?php
    require_once("Encryption.php");
    $cg = file_get_contents($argv[1]);
    $e = new Encryption();
    echo $me->Decrypt($cg);

Usage: php ppp-decrypt <filename>

Make sure the path in LocalSettings.php (which defines where your PPP keys are stored) is valid, and contains your keys. If the LocalSettings.php file does not exist in the root of the PPP plugin, you'll need to create it. Below is an example of what it should contain.

<?php

$wgCachePages   = false;
$wgCacheEpoch   = 'date +%Y%m%d%H%M%S';
$wgPEMsize      = 1024;                 //default key size
$wgPEMlite_size = 512;                  //lite key size
$wgPEMdir       = '/home/user/keys';  //storage for keys
$wgPEMfile      = 'default.pem';        //default key's filename
$wgPEMlite_file = 'lite.pem';           //lite key's filename

$wgPEMold       = 'private.pem';        //old key's pathname (optional)
                                        //if you've been using PageProtection

I'm also sure this is possible with openssl, but it looks like the PPP plugin does various other things with the encrypted key / data, so it was just easier to utilize their existing framework.

Make sure you backup your keys (the .pem files), as on occasion PPP looks like it clears out the key directory.

You may also need to install a few PHP packages, as below.

pear install Crypt_RSA-1.2.1
pear install Crypt_Blowfish-1.1.0RC2
apt-get install php5-mcrypt

Let me know how you get on :)


I can move pictures from my stock photos app to the photo vault while on airplane mode so I don’t believe they are being uploaded anywhere else.

If you're not transfering your photos through your school's Wifi, they can't see something. Just be sure, this app doesn't do any background connections with their "cloud".

The question you actually need to consider -to prevent sniffing when transfering- is if this old photo vault app transfer the photos through HTTPS protocol. As the link didn't provide any usefull information about the security they're using, you can achieve that with one of most well known programs that analyze packets (eg. Wireshark). If it's using https; you're -propably- safe from sniffing.
(except all the other factors; where are they storing the photos, who got access, what kind of encryption etc.)

Your school can -and should- log the transfers and see where the connections are going or coming.


Is there any 'Open Enrypted File Container' Format?

Archives and emails come to mind.

Archive formats: both Zip and 7Zip are open standards that support encryption (though how well they do encryption is up for debate).

Email formats: S/MIME, aka Cryptographic Message Syntax, aka PKCS#7 is an open standard for a container format that supports cryptographic signing and encryption (both symmetric encryption like AES, and public-key encryption like RSA). S/MIME is widely supported by email clients such as Outlook, Thunderbird, and probably many others.

OpenPGP Message Format is another such container format designed for email which supports the same crypto operations as S/MIME. In addition, many people use PGP for encrypting files on disk. In fact all software distributed through a linux package manager uses the PGP format for its crypto wrapper. The most common tool for reading / writing PGP files is called GnuPG aka GPG, but others tools exist as well.

TL;DR: Yes, there are many such Open 'Encrypted File Container formats' which can be understood by many different tools. The ones that come to mind are zip-like things, and email-like things, but I'm sure there are more examples.


Recent "attack" to my server that might be using shellshock exploit

The string provided does appear to be an attempt to exploit the Shellshock vulnerability.  With cgi disabled your attack surface should be reduced.

With regards to countermeasures, patching to address the issue would be the most effective approach. The following links provides guidance on assessing whether your installation is vulnerable, as well as steps to apply the necessary patch to address the issue:

https://about.gitlab.com/2014/09/24/gitlab-shell-and-bash-cve-2014-6271/

https://about.gitlab.com/2014/09/25/gitlab-shell-and-bash-cve-2014-7169/


How does Shodan crawl internet-connected devices?

There are only about four billions of possible IPv4 addresses, so trying them all is feasible, with enough bandwidth. There are available tools for that.

Shodan themselves document in their FAQ that they use some custom code:

  A home-grown, distributed port scanner was developed for this project.

"Distributed" here means that connections are made from several machines, which seems not an issue since Internet-wide scanning is, by definition, an embarrassingly parallel problem.

A related case is the so-called Internet Census 2012 in which some unknown people repeatedly scanned for some vulnerable hosts (typically home routers still configured to accept default admin credentials) and temporarily hijacked the said systems to enlist them in a whole Internet scan on "most common ports" -- that's a case of a self-replicating botnet. They say that they reached 420000 clients under their control. For a complete Internet scan, each client only has 10000 IP addresses to try, so this can be done quite discreetly (say, 3 probed IP per second for an hour).


Google has your answer:
http://support.google.com/websearch/bin/answer.py?hl=en&answer=186669

You can use Lock SafeSearch or use the NoSSLSearch option.

*Edit*

I think your best option after reading your comments is a proxy on the firewalls to re-direct the requests to HTTP. Squid can do this, but it might be more advanced than you want. Here is a tutorial to do what you want.

Tinyproxy is a simpler alternative, although I have never used it.


How to crack a password given its hash and its salt using a more efficient method than brute force?

Without any more information, you can not reduce the search space. Since you don't have any prior information about the password, you can't rule out any possible password from the search space.
If your hash function (which you don't specify) has some vulnerabilities, you may be able to learn something about the password before starting the brute force attempt (starts with 'a', contains 'b' and so on...). Thus reducing the search space.
Something else that may answer your need for faster password cracking is Rainbow Tables which are a precomputation you perform given the salt, to be able to find the password faster later. Rainbow Tables are used as a lookup table for a given hash.
Say we have hash('four','ss') = ss1C5xfz6Nggg, and we know the salt ss. We will perform the following precomputation:

The actual Rainbow Table must be sorted according to the hash values, to enable fast lookup. This way, when given the hash of the password, ss1C5xfz6Nggg, we only need to lookup the hash in the Rainbow Table and our password is stored right next to it. Thus making the cracking process much faster (At the cost of precomputation time, of course).
Edit: Sjeord's comment is correct, so I must point out that:

Rainbow tables, despite their recent popularity as a subject of blog posts, have not aged gracefully. CUDA/OpenCL implementations of password crackers can leverage the massive amount of parallelism available in GPUs, peaking at billions of candidate passwords a second. You can literally test all lowercase, alphabetic passwords which are ≤7 characters in less than 2 seconds. And you can now rent the hardware which makes this possible to the tune of less than $3/hour. For about $300/hour, you could crack around 500,000,000,000 candidate passwords a second.

Source


SNORT rule for detecting/preventing unauthorized VPN or encrypted traffic

In the case of TLS the answer is yes. (IPSEC?) The screenshot below shows a TLS exchange being caught by Wireshark. I don't know if Snort can do this directly.

DISCUSSION
I'll assume that you're within the same security boundary as the server. If you weren't, then simply tunnelling one protocol (eg. TLSxx on TCP) within another (eg. OpenVPN on UDP) will be enough to mask any connection establishment, such that you will be reliant on statistical analysis to try and determine what the specific network activity is.
Generally speaking, however, it really depends on the exploit.
If the attacker compromises a public-facing host, and manages to open a privileged port on this host, then you could capture this activity either on the host, or on the host's network, preferably both!
But what if the adversary modified (or worse: installed!) some upstream edge router to redirect packets to a different internal host, and then, instead of this new host listening for expected protocols (eg. HTTPS), the conditional host was now listening for some other protocol (eg. SSH)? I might configure HAProxy with a layer-4 reverse proxy that chooses between TLS, or SSH on a different internal host only when the client IP is specifically w.x.y.z or port 0FF0, etc.
Here's an example of configuring HAProxy to respond differently, depending on the protocol (HTTPS vs SSH) of the client Lim '16
Here's another interesting example showing discretionary back-ends depending on the contents of the TLS-SNI hostname Gornstein '17
HAProxy documenation on acl directives
(Yes, this example shows picking the SSH backend depending on the first 7 bytes, which your monitoring would also pick up on, but the protocol could just as easily be hand-rolled to use- or hardened with- a pre-shared key, eg. WireGuard or ZeroTier. In these cases the protocol is designed to mask the exchange of keys; IMHO the direction newer privacy-oriented protocols are trending toward.)
Now you might only see data flowing over the socket (encrypted, of course!) and never actually register any protocol. Any monitoring performed on host X will not even see the packets associated with the malicious activity. Monitoring on the network will see activity from host Y, but it might be mistaken for some other protocol.


Are OpenJDK and non-Windows systems vulnerable to the Sept. 25th 2012 Java vulnerability?

It's been less than 24 hours, and it doesn't seem to have a CVE entry yet, so it's difficult to say. The details are pretty sparse.

All I can give you is my best guess:

Any initial exploits will work on Oracle Java SE only.
A variant of the vulnerability may affect OpenJDK, but it's unlikely to have the exact same problem. This is because it's an entirely different codebase. We may see problems later on with OpenJDK though.
It'll be cross-platform, since the constraint violation is in the JVM, not in anything Windows-specific. It may even work on non-x86 machines, e.g. ARM / PPC.


Why if a server response contain both Public: TRACE and Allow: TRACE then responds with 405 NOT allowed?

It looks like a false positive, according to the documentation (https://nmap.org/nsedoc/scripts/http-methods.html) this script works by sending an OPTIONS:

Finds out what options are supported by an HTTP server by sending an OPTIONS request. Lists potentially risky methods. It tests those methods not mentioned in the OPTIONS headers individually and sees if they are implemented. Any output other than 501/405 suggests that the method is if not in the range 400 to 600.

The methods listed in response to the OPTIONS request may not actually be supported or may be handled as a GET method. If OPTIONS request returns TRACE, nmap script does not verify this, just prints as a supported method.
You should manually verify every potentially risky method (PUT, DELETE, CONNECT, TRACE) which is returned by OPTIONS request. If response is 405 Not Allowed than method is not supported and there is no security risk.


I don't think that the development itself is so much of a problem if done alone, offline and with proper disc encryption and if the software never gets distributed.

But, if you need help in development you need to communicate with others or at least get information from the internet. It might for example be that the developer forums you visit are compromised and use of these forums will compromise your system too, like in Apple, Facebook employees hacked via website malware, Java vulnerability or in FBI using an exploit to attack Tor users.

Even if not compromised the forums might log your visits, store the questions you've asked and the posts you've visited etc, which might be used to construct a picture of what you are working on and might later be used as evidence against you. And just visiting such sites via Tor does not make you fully anonymous - all what it does is hiding your IP address.

And then you likely need to somehow distribute the software to others. If done as binary for easy install then these binaries often include traces from the developer environment and process, like language used on the system, time the software was compiled, specific versions of software libraries used in your code, software versions used for compilation, debug information, ... . While none of this by itself will make it possible to find you and can help to narrow down the potential suspects and might later be used as evidence. Distributing as source code might even be worse since it can be more easily aligned with code snippets you might have asked about on the internet.

Also, I hope that would not blindly install arbitrary software you'll find on the internet and this kind of security you should expect from others too. So you somehow need to establish some reputation so that others will trust that the software does what it claims and does no harm. Building such reputation commonly involves that you need to communicate with others and trust others too - which makes your vulnerable if there is somebody you should not actually trust. For example government agencies are regularly able to infiltrate closed forums in the dark net even though the administrators of such forums try very hard to screen new members.

In summary: it is far from trivial and there is no simple tutorial to follow. The threat model is specific for where you live, what kind of software you develop, what your developments tools are, how do you want to distribute the software, how hard somebody would try to find you ...


You can ask your hosting provider to reject messages using the worst TLDs. You can have a list of the 10 worst ones on The World's Most Abused TLDs page at Spamhaus. FYI, I've already receive much spam from the .stream TLD too, and also from the .top one. I suppose that this is safe as users should avoid TLDs with a bad reputation anyway.

Otherwise you can change to a better hosting provider, with better spam filtering.

There's no way to find the spammers, and that's probably why they use such TLDs, which provide them some protection, as mentioned on the cited page above.


What is packet drop, packet loss and how Packet drop attack works?

These terms are a bit more general that that, which may be the cause of the confusion.

When Alice sends Bob a message over a packet switched network, like the Internet, then it is broken into a number of individual packets, which are sent one at a time. Each packet travels from router to router, eventually ending up at Bob's computer, where the message is reassembled.

If one of the packets fails to get from Alice to Bob for some reason, we say it is lost. (One of the reasons why you use packet switching is that if you lose a packet, you can just ask for it again, rather than needing the whole message to be retransmitted.)

It might get lost by accident, but packets can also be lost because a router receives it and specifically decides not to pass it on to the next hop. This deliberate loss of a packet is called dropping. (There are legitimate reasons for dropping a packet: for example if the router is overloaded, or if the router believes the packet is part of a DOS attack.)

A packet-drop-attack, then, is a denial of service attack where the attacker takes control of one of the routers between Alice and Bob and tells it to deliberately drop some or all of the packets in the message.


Why does one need a high level of privacy/anonymity for legal activities?

One real world example - when you are naked in your shower, not doing anything wrong, would you like it if everyone came by and took pictures? Or televised your shower for the world? Probably not.

Another example - if I send a love letter, or write a will dividing up my savings, should that be published on the front page of the national papers? Again - no.

If I am carrying out my own business, the expectation should be that I have privacy, except where I have consciously and deliberately waived it. This was the case before technology became pervasive - it should still be the case. In the old days law enforcement needed a warrant before they could access your property or communications, because the assumption has to be innocent until proven guilty. This has been eroded as technology has developed.

If I encrypt all my emails to my friends, the expectation should not be that I am a criminal for doing it, just that I want privacy, like leaving a room to take a private phone call. I could be planning a surprise birthday party, or applying for a new job, or possibly just enjoy using PGP - it doesn't really matter - it's my business.

From the EFF's privacy page:

  Privacy rights are enshrined in our Constitution for a reason — a
  thriving democracy requires respect for individuals' autonomy as well
  as anonymous speech and association. These rights must be balanced
  against legitimate concerns like law enforcement, but checks must be
  put in place to prevent abuse of government powers.

Admittedly, I don't live in the US, but those constitutional rights sound good to me.


Are there any customizable vulnerability notification services?

2020 update: CVE Details has silently stopped being updated.

CVE Details allows you to "generate a custom RSS feed or an embedable vulnerability list widget or a json API call url", filterable on a large range of fields including product.


Storing product keys on same server as shop?

I guess your question is more a case of seeking confirmation that your proposed solution (see quote below) is the best or only option.

  Could I restrict possible damage in case of intrusion in the shop
  system by storing the product keys including the automation script on
  another server with another database?

If that's your question the answer would be: yes.

The second server holding all your assets should not allow inbound traffic, only outbound. This way there is only traffic originating from a secure zone to a untrusted zone and not the other way around.

If you look at the picture on the Dutch NORA Zonering webpage. Your customer would be in the "white" zone, your shop in the "green" dmz zone, your second server in the "yellow" zone and your assets (DB) in the "red" zone. All communication is filtered. Only the yellow zone has access to green (cron), red (DB) and white (e-mail to customer). Google translate does a decent translation by the way.

In your case you may put your assets in the yellow zone as well, if there is no direct access from the white or green zone. You might even use a workstation as these normally only are allowed outbound traffic. But when using for normal web browsing as well so called drive-by-malware would be an issue.

In general from most to least secure traffic:

no communication;
only outbound or originating from the inside (that's what you propose);
inbound allowed via a semi-secure zone which filters;
inbound and unfiltered.

Another relevant source:
Public DMZ network architecture


What would be the valid approach while handling short links

To mitigate drive by exploit attacks:

Disable plugins or set to click to run
Disable JS for unknown sites
Use a sandbox/VM
Use exploit mitigation software such as MBAE, EMET or Palo Alto Traps
Use a traffic analysis tool
Block advertisements (optional)

To mitigate phishing attacks:

Check site URL matches what you expect
Check for a undepreciated TLS version
Check certificate matches what you expect
Check cipher suite is secure
Use your common sense before entering information

You can also use a browser extension to pause loading before a redirect, so you know where the redirect leads.


How exploitable is a QR code in a login system?

Instead of uploading user info to QR code try to upload a malicious script to bypass the login. If you found the uploads directory, you can run your script and get more access.


Secure data transfer to internal network

SMB is fine in general as long as you're using SMBv2 with SMBv1 disabled, although in this scenario I wouldn't use SMB because it involves opening port 445 on a Windows box into the DMZ, and that offers up quite a large attack surface.

I'd personally use SCP. There are tools for it on almost every OS in existence, it's based on SSH, it's standardised, it's fast, and you can secure it with an SSH key rather than a password. You could also use rsync over stunnel, but that's a bit more complex. In both cases you can easily set up a firewall rule for TCP connections from the DMZ host IP on any port, to the internal host on port 22 (or whatever you've got your stunnel port set as).


Vega shows SQL injection vulnerablity but sqlmap says no

If the application is querying a database for appname, then most likely you have a SQL injection. To test the url with sqlmap run the command:

sqlmap -u "app.php?app=appname" -p "app"

Here is a quick cheat sheet to protect yourself from SQL injection.


Although that kill processes command airmon-ng check kill may solve the problem, don't use it because you'll stop many functionalities including the network-manager application.

Instead, use the following commands when starting monitor mode:

#> airmon-ng start wlan0
#> ifconfig wlan0mon down
#> iwconfig wlan0mon mode monitor
#> ifconfig wlan0mon up


Is industry experience the only way to a CREST certification?

You can pass the CREST exam on skill and knowledge alone. It is however very unlikely that someone without practical experience will be able to do so in the limited time allocated for the exam.


Official recommendations for antivirus on Windows servers

There no official "recommendation" that you can get. What you can do is understand your security needs, and compare products to match your requirements, performance  and budget.

Personally I use this for my Windows Servers:

https://www.eset.com/uk/business/server-antivirus/file-security-windows/

Read about it, understand the features and see if they match your requirements.


A time-based SQL injection is not different from an ordinary SQL injection and neither is fixing it. They vary in how hard they are to attack but the defense remains pretty much the same. It also should not be relevant for the fixing method in which component you found it.

That's because the clean way to deal with SQL injections is almost always using parametrized queries (prepared statements). If you are auditing the source code, it would be best if instead of just flagging the SQL queries that you think are exploitable, you would rewrite all raw SQL queries to proper prepared statements. That makes the next audit much easier and you don't have to spend time thinking about escaping patterns and evasion techniques.


Rephrasing your questions a little:

  Is it possible to alter the data of the game and replace it with
  malware without Steam's servers noticing?

It is possible.

  Is it likely?

No, for the reasons listed in the "other ways" section.

  Can time delay be used to detect tampering?

No. Networks are unreliable, so this would create too many false positives.  Also, in order for this Man-in-the-Middle attack to work at all to replace a specific game, the attack needs to be prepared beforehand.  In the extremely unlikely chance that it's attempted, you would probably get the maliciously doctored game faster than you'd get an original copy.

  Other ways to prevent this attack?

Use TLS (SSL) to encrypt the data as it is being sent to you. An attack would have had to have already compromised your computer to be able to decrypt and change the data while it's being sent to you.
Verify the file's integrity; that it is the right size and the right hash can be calculated from it.

Steam already does both of these things, and can be directed to re-check the files after installation as well.  The way to beat the file integrity check is, again, to already have malware on your computer that is showing you intentionally incorrect data.

Essentially, unless you're a target of a State-Level Actor (CIA, MI6, etc.), someone did not swap your game with malware while you were downloading it.  You would know if you were already such a target.


What information can a website see if I am using a remote computer?

It all depends on how you are accessing the remote computer. If you are running a remote desktop program, then all web browsing is being initiated by the remote computer, and the target website only knows about the Australian computer.

If you are running a VPN or a proxy on the remote computer, and the web browsing is initiated from Canada, then it is possible that the origin computer might leak data to the target. (Search for VPN/proxy privacy leakage on this site and others)


How can I log access and usage of a MySQL database?

If you are trying to track access to data from your MySQL database for HIPAA and the PCI Data Security Standard then you want MySQL Enterprise Audit plugin and there is also a MariaDB Audit plugin.


Are RSA 2048, ECDSA, and the SHA uncrackable in the sense that AES-256 is uncrackable?

RSA-2048, ECDSA (on a 256-bit curve), SHA-1, SHA-256 and AES-256 are all "equally" uncrackable in that they are all in the wide category of "we don't know how to break them with existing or foreseeable technology".

(SHA-1 resistance to collisions, but not to preimages, is not in that category. That one we know how to break -- it would be quite expensive, but not beyond our collective reach.)

We can make some asymptotic estimates that state that if computers are allowed to increase in power in arbitrary amounts (but there are good reasons why this will probably not happen), then RSA-2048 will fall first (approximately 2112 resistance), then ECDSA with P-256 (2128), then SHA-1 (2160), then SHA-256 and AES-256 (2256). But such comparisons are quite meaningless, since they rely on an hypothesis which does not seem wholly compatible with laws of physics as we know them.

Quantum computers, if they can ever be built, will make short work of RSA and ECDSA. They will only weaken SHA-* and AES, down to levels which will still be somewhere between "fiendishly hard to break" and "unbreakable".

Prospective on technology evolution for 150 years are pure guesswork. Nobody really knows what the World will look like 100 years from now. Personally I do not make prophecies beyond 40 years.


XSS - Setting Values and Attributes w/ jQuery

You definitely don't have to worry about setting the action on your form.
This is because it isn't being set from user input.  The issue isn't setting it, but setting it based on user input and therefore potentially setting it to a dangerous value.  If you control what it is set to then an attacker can't inject anything, and therefore there is no avenue for XSS.
Also, I'm not sure if the form action has the same potential issues as a link href does.  I've never tried setting something like <form action="javascript:alert(1)"> but I'm 95% sure that it won't work.
The way you set the input value is fine too
It is unclear if the value you are setting the input to is controllable by a user (and therefore an XSS vector).  It depends on where the id data in this comes from, and whether or not it comes from a user.  However it shouldn't matter.  You can still set values safely, even when they contain user input, by using the proper JavaScript methods.  As a slightly different example this is perfectly safe:
element.text = [USER_INPUT];

While this is not:
element.innerHTML = [USER_INPUT];

In the case of the former, you are explicitly telling Javascript that you want to take some data and set it as the "text" for element.  As a result the browser will treat your content as plain text - never JavaScript.  The latter tells the browser that you want to take the input and treat it as HTML.  Since HTML can contain JavaScript, this would be an XSS vector.
In your case you are using the val method in jQuery.  Whether or not this is safe from XSS depends on the underlying method jQuery uses to set the input value.  I haven't looked in a while, but I'm 95% sure that jQuery just sets the input.val property.  Doing this is safe, and can't trigger any JavaScript, so you're fine even if id contains user input.


Is it possible to acquire an SSH authorized RSA private key just by having access to the server?

When authenticating using a key, the actual private key is never transmitted; only some data supplied by the server is signed using the key to prove you have it. SSH'ing to a rogue server using keys doesn't compromise the key forever. It may allow the attacker to use the key while you're connected if you have SSH agent forwarding configured, but once you disconnect the attacker can't use the key anymore.

Note that if you suspect the machine to be compromised, you still should follow the standard procedure just to be safe. Not because of your new key (it's safe) but because of other sensitive data the server may be handling. The fact that you deleted the old key from .ssh/authorized_keys doesn't mean you're not already running a compromised sshd with the attacker's key hardcoded in it.


Two views:

Corporate:

Whether you have control over all the machines, or at least the central auth server, you're better off with SSO. One place to hire employees, one place to terminate them, one set of credentials they have to worry about. Individual server compromises shouldn't leak credentials. Users are less likely to get annoyed, forget passwords, and use horrid patterns of passwords especially when the 7 different computers they have to access start hitting their password change periods at staggered points.

In a company environment, you want one point of authentication.

The Wild Internet

Spoofing / phishing is a bigger concern. Privacy becomes a concern. A third party knows everywhere you log in. Compromise of that 3rd party compromises all your accounts. The benefits of one identity, one login have to be weighed against all those. When you get duped into a fake login page from your web forum and it links to your email, and hence your bank, things may get ugly.

For the ServerFault guys, there's no question that they want that on their network. For the world at large, there's a big bit of trade-off to be had.

Edit to address commments

Submitting one's login credentials to a 3rd party service is the antithesis of single sign on.
In some cases, it does make sense to provide users with multiple accounts. Many wise system administrators have their normal operations accounts and their elevated privilege accounts. At the same time, this is still an SSO system. It is often the case that a central authentication server handles the multiple accounts.
In regards to password sharing, I consider that a poor argument against SSO. In any case where access to something should be shared, it should be done with different credentials. While we have to accept that there are some systems out there that need sharing and do not implement the ability to assign rights, this should be addressed by altering the system whenever possible.


Why should I bother having a firewall on servers?

Additional security usually decreases functionality, so it is for you to establish the risk and see if the benefits of a local firewall outweigh the limited functionality.
  The purpose of a firewall is to block based on a port but also based on the source IP.  A server local firewall adds a layer of security that seems redundant to you, but if another layer of security fails, it could prevent malicious activity.

Scenarios this could help you with:

If you want to limit who can ping or make console connections to the server, based on console port and a limited number of accepted IPs
If new software is installed and starts listening on a new port, firewall will prevent connections to this service unless a matching firewall rule is also added
If the server was scanned for services from the outside or inside the network, a local firewall could reduce the results and focus an upcoming attack somewhere else
If you did have a vulnerability so severe as to want to block web traffic to the server, you could be better prepared for this if the firewall is pre-installed and working


CSRF protection with custom headers (and without validating token)

Security is about defence in depth. Simply checking the value is sufficient at the moment, but future technologies and attacks may be leveraged to break your protection. Testing for the presence of a token achieves the absolute minimum defence necessary to deal with current attacks. Adding the random token improves the security against potential future attack vectors. Using a per-request token also helps limit the damage done by an XSS vulnerability, since the attacker needs a way to steal a new token for every request they make.

This is the same reasoning used in modern cryptographic algorithms, where n rounds are considered a minimum for safety, but 2n+1 rounds (for example) are chosen in the official implementation to ensure a decent security margin.

Further reading:

CSRF with JSON POST
Why refresh CSRF token per form request?


ECDH_SHA2_NISTP256 (KEX) Algorithm in SSH - Vulnerabilities?

They're probably referring to NISTP256 in the algorithm.  The constants for this elliptical curve were created by the NSA, and there is some speculation that the NSA may have been specially chosen these constants to create a backdoor for themselves for this curve.  See the links below for more info:

https://crypto.stackexchange.com/questions/52983/why-is-there-the-option-to-use-nist-p-256-in-gnupg

https://www.wired.com/2013/09/nsa-backdoor/

https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929

Notwithstanding, NISTP256 is defined as:

 y^2 = x^3-3x+41058363725152142129326129780047268409114441015993725554835256314039467401291

As far as I know, the NSA has never explained how they came up with the long constant (41058...) above.

By contrast, secp256k1 (used in Bitcoin) is defined very compactly like so:

 y^2 = x^3+0x+7


Do Flash memory (SSD) architecture impacts encryption techniques?

The whole idea of encryption is that it is meant to bring you confidentiality regardless of how the physical media is managed. Details about how a bit is "erased" (or fails to be erased) is relevant to security; encryption is about getting said security without having to bother with those details.

It turns out that data on a SSD is a fickle thing and it is hard work to track out all the places where it goes; see this question for details. This just emphases that encryption is the only sure method to keep the data confidential.

Disk encryption on a SSD is not different to disk encryption on a "classical" magnetic disk. Their interface is identical: accesses by indexed 512-byte sectors. This does not make SSD encryption simple, only not harder. Disk encryption is by itself a complex problem: it must handle random access (both for reading and writing), be fast (disks have a huge bandwidth), be integrated in the operating system, and should resist active attackers who can shut down the machine, swap some sectors, and power it on again.


What is the SPF domain value based on in DMARC aggregate reports?

Why are these other domains showing up in that field, and where are they from?

Within the <auth_results> section of the DMARC report all authentication results are listed, no matter if they get used to compute the DMARC result or not. From the DMARC FAQ: I need to implement aggregate reports, what do they look like?:

  Please note that the SPF and DKIM results in the auth_results are raw results, regardless of Identifier Alignment; the results of the DMARC evaluation with Identifier Alignment are in the policy_evaluated section.

As for the envelope_from:

  I've also noticed that most reports don't specify an envelope from in the indicators. Why? It seems to be required by the schema in the RFC ...

These reports do conform to an older draft only, like draft-dmarc-base-00
rev.02 from 2012. There is no envelope_from in this version yet. It was only added later in draft-kucherawy-dmarc-base-00 in 2013. I do not know why the reporting tools did not get updated but even Google is sending such older reports.

Even the example shown in the official DMARC Wiki uses the older report format although it acknowledges that the example "may be out of date by this time". Given that even the official examples on how to write a DMARC report are out of date one probably cannot expect from the vendors to be better than this.


What is the difference when scanning external IP's from my LAN vs cloud/external scanner?

It depends most on how your network is configured, or if the target employs geoblocking or not.

If your firewall allows the sending of arbitrary packets, even malformed ones, and the target does not care if you are in Ireland or Argentina, a cloud-based scanner works the same as using your own IP.

On the other hand, if your firewall "sanitizes" packets, discarding malformed ones, or your target drops packets depending on your location, it can be worth pay for a cloud scanner. How a target handles malformed packets are a good indicator of OS used, application running and so on. If your firewall "fixes" the packets, that can mask your results.

Another consideration is technical support. Commercial cloud scanners will usually offer help if you run into problems, and help interpret results. If you are skilled enough to do a scan without assistance, that may be unnecessary.


At the most basic level: no. Any site can choose to host any content, and have differing levels of sanitation of user generated content, and various levels of security. Even Google has services that could be used for phishing, no matter how challenging it may be to actually do so. Even if a site does not allow it, there are attacks, like DNS poisoning, SQL injection, escalation attacks, and so on, that might leave a normally secure site in a malicious state. Even NASA's own website was once hacked, and could have done a lot of damage if the attackers had intended to do so.


Making S3 objects viewable only for logged in users

Would it be possible to grant the user an IAM role? If so, you can scope the roles so that each user can only see objects that begin with their prefix, e.g. username/*.
Each user's IAM role will grant them only access to objects whose keys begin with the specified prefix.
The other option would be to use lambda functions to generate pre-signed urls for the user on a per request basis (with very short lived time), hence removing the need for logout, (i.e user request a file, and gets redirected by lambda to the pre-signed url per request).
To the point though, there isn't a 'right' way of doing this as far as I know, and there might be many other options I'm not aware of either.


There is benefit to using a full-cycle platform that allows SIEM Engineering (e.g., Splunk ES) and Security Automation (e.g., Splunk Phantom), but these can also be performed using open-source platforms (e.g., HELK for SIEM engineering and Rundeck for Security Automation).

There are many benefits to ATT&CK detection, which may be platform-dependent. For example, Microsoft Sysmon is great for Windows and Windows Server, but no use on Linux or macOS. osquery has many configurations for all 3, but ATT&CK coverage tends to be Windows-only as well. auditd is Linux-only. xnumon is macOS-only, but there's a lot going on there, which even this forum has covered.

It sounds like what you are asking for in this question is not only going to be OS-dependent, but also perhaps Web Server or even Application Dependent. However, there are some standards, such as the NCSA Common Web Server Log format, and loose guidelines.

After-the Fact, there isn't much you can do, but I have seen a few articles cover tools such as apache-scalp. For Apache httpd web server, the access log file(s) are usually in /var/log/apache2/access.log, but can be anywhere (even the config can be anywhere). For Windows Server IIS web server, the log files are usually in \WINDOWS\system32\LogFiles\W3SVC1, but again, can be configured elsewhere. Most databases and other integration points for web applications do not log by default, or their logs are uninteresting for security purposes (but this is not always the case).

If you can install tools or run Python scripts, etc, then you may be off to a good start. If not, then you may be able to bring the logs elsewhere, but then you end up right back at the original Not-Using Splunk problem that brought you here in the first place. Microsoft has a more-official tool for web server / web app log analysis named LogParser which can do cool things, such as:

  logparser.exe -i:iisw3c -o:Datagrid -rtp:100 "select date, time, c-ip, cs-uri-stem, cs-uri-query, time-taken, sc-status from C:wwwlogsW3SVCmyserver*.log where cs-uri-query like '%UNION%'"

Apache, Nginx, and IIS web servers tend to only log HTTP GET requests and their associated server response codes. If you want more, then you'll  need to turn to additional bolt-on utilities and/or configurations.

For example, for Apache, mod_dumpio has been around since 2009, and mod_security and others were added later to support HTTP POSTs and lengthy server response collection.

proxy_pass or fastcgi_pass lines can be configured for the Nginx web server in order to leverage the $request_body variable.

The Advanced Logging Extension for IIS can be added to Microsoft IIS Server to achieve the same, or better.


Why IE/Windows forces you to install self-signed certificates as root CA to make them work?

In X.509, a certificate can be validated if it can be put at the end of a valid chain, where each certificate in the chain has issued the next one, and the chain starts with a trust anchor. The trust anchor is the certificate that you trust "ex nihilo", i.e. not by virtue of the certificate being signed by another, trusted certificate; the trust anchor is trusted by configuration. This configuration is, indeed, putting the certificate in the "root CA" certificate store.

When you put a certificate in the "root CA" store, this does not automatically means that your machine will begin to use this certificate as a CA, i.e. to validate other certificates. This merely means that the certificate is "trusted". Whether this certificate will also be accepted in the role of a CA depends on what is written in it (the Basic Constraints extension).(*)

To initiate trust, you must do "something". A Web browser must not trust transparently any self-signed certificate that it encounters; it would be a gross vulnerability. The user must make an explicit action to allow the self-signed certificate to be trusted for SSL; and, preferably, this action must not be a too easy one-click thing, because otherwise users will do it without even noticing it. Clicking through warning popups, however scary they can be, is a well-entrenched behaviour in human users; and, unfortunately, accepting a self-signed certificate without due manual verification leads to Man-in-the-Middle attacks.

In Windows/IE, the "something" needed to prime the trust system is installation of the self-signed server certificate in the "root CA" store. This requires some not-easy GUI invocations, and that's by design. It MUST NOT be easy.

For other browsers, things may vary, though the core concept is the same. For Firefox, installation of a self-signed SSL certificate is described as a "security exception"; Firefox has its own X.509 subsystem, completely disjoint from the one of the underlying OS. For Chrome, this depends a lot on the OS, the OS version and the browser version.

(*) There are subtleties. Old X.509 certificates, aka "v1", more than 15 years ago, did not support extensions at all, so there was no way to mark a certificate as "good for CA" or "not good for CA". This means that a v1 self-signed certificate, installed in the "root CA" store, will act as a CA, thus be accepted in the role of a CA, for validating other certificates. You should take care, when installing a self-signed certificate, that you do not open that door. Unfortunately, this depends on rather technical details of the certificate, so it is not easy to test for end-users.


How to determine the exploit to gain access to the Vulnerable servers?

I am pretty sure your book will have discussed this as well. Penetration testing is more about gathered information than actually using tools and programs to get the job done. To a certain degree these steps are involved; gather information, analyse situation, prepare strategy, execute. Obviously the last is least important.

Gather information: Who and what is the target? What do we already know? Can we exclude systems, methods, tools? What do we need to gain more info? Who to contact?

Analyse situation: Do we notice strange patterns, files, responses? Do we have a clear image about the internals of the system? Are there obvious problems, weaknesses, exploits?

Prepare strategy: What is the best way to reach our goal with the information that we have? Can we prepare a plan for attack, and a backup plan? How to deal with unexpected situations? Who to contact?

Execute: Execute the plan.

Your book may have different steps, but they at least involve the information gathering part.


Should I enable Google Auth login by default for my users?

oAuth is not an authentication mechanism. It handles authorization to access resources (usually an API).

From RFC 6749:

  The OAuth 2.0 authorization framework enables a third-party
  application to obtain limited access to an HTTP service, either on
  behalf of a resource owner by orchestrating an approval interaction
  between the resource owner and the HTTP service, or by allowing the
  third-party application to obtain access on its own behalf.

It is however also used by some as a way to authenticate users. You must trust that service because it has the keys to your resources (as opposed to allowing you to access their resources, with the agreement of their user - which is what oAuth is for)

Wikipedia points out the differences between oAuth and OpenID (which is an authentication protocol).


Protecting form post values when on https

If you are using HTTPS, there is no reason to encrypt anything in your forms. This is because HTTPS is already encrypting all of your traffic. If you have a properly configured HTTPS connection between your server and the client, there is no way for an attacker to see the data being passed between the two. If this was not the case, encrypting your data client side would only be marginally beneficial, since a determined attacker could intercept your javascript code used for encryption while it is being sent from the server to the client, and replace it with a compromised version.

Generally speaking, there is no reason to encrypt data on the client side, since HTTPS is required to ensure that you have non-compromised encryption code, and if you have HTTPS you don't need any additional encryption.


Config Server Firewall: What Outgoing ports need to be open for wget and apt-get install?

Firebind can test any outbound UDP or TCP port to tell you whether it's blocked or not, and if so, how it's blocked (DROP, RESET, etc.)

http://scanme.firebind.com/applet.html

You can test any of the 65535 UDP or TCP ports, or even the entire range.  They also have a bunch of preconfigured tests for popular apps and games.


Why is Android/Linux able to communicate with the wireless access point after the encryption key is set to zero?

KRACK is a man-in-the-middle attack. That is: the access point is not disturbed, only the station, or the computer connecting to it. For instance, a good reference is [1].

It seems that KRACK was not faithfully presented, even in the specialized media.It is a very clever attack, and some misconceptions have been repeatedly presented: for instance, computers running Microsoft Windows are not safe from it, as it is a failure in the WPA2 specification, not a failure in its Linux kernel implementation.It is true that computers with a Linux kernel were weaker under this attack, but no computer was really safe.

[1]: Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2
  https://papers.mathyvanhoef.com/ccs2017.pdf


Where to store secrets in .NET applications?

The Windows-built-in secret store (analogous to Apple's Keyring) is called Credential Manager. See https://stackoverflow.com/questions/9221245/how-do-i-store-and-retrieve-credentials-from-the-windows-vault-credential-manage for (slightly dated but still usable) instructions on accessing it programmatically.

With that said, all that the Credential Manager does is encrypt your secrets with DPAPI and store them in a structured data store (I'm pretty sure it's in the registry). Since you're encrypting with DPAPI yourself, the Credential Manager buys you very little except possibly a bit of convenience (though DPAPI is very convenient, and so are most storage APIs).

Personally, I recommend encrypting with DPAPI and then storing the secrets in the user's Local AppData folder, in a subdirectory with your program's name (if the secret is machine-wide rather than per-user, you can use the ProgramData directory instead of AppData\Local, but of course this will make it world-readable). It's as secure as any other location reliably available in Windows, easy to delete when uninstalling the program, and easy to access. Using the current user's registry hive under Programs\ProgName is also an option, though. A database is pretty pointless unless your secrets are some kind of interrelated structured data, or you anticipate having a very large number of them. I wouldn't bother with Credential Manager unless the secrets you're storing are actually credentials and/or it's acceptable/important that your users be able to view them using the Credential Manager GUI.

With all that said, a few words of warning:

DPAPI uses a per-user encryption key that is different on every machine. If you copy DPAPI-encrypted data from one machine to another, you won't be able to decrypt it on the second machine.
DPAPI's encryption key is itself encrypted using a key derived from the user's password (among other things). If the user changes their password through the standard process (where the old password is provided), this is fine; the DPAPI key is decrypted and re-encrypted with the new password's derived key. If the password is reset (by an Administrator or via offline modification of the SAM data), the DPAPI key is lost forever. This is probably fine for your use case but is something you should know.
A lot of the stuff mentioned in this answer is Windows-specific, but .NET itself is cross-platform. If you want to be allow Mac, Linux, and other platforms to run your code too, take care to avoid Windows-specific features and functions.


what are the disadvantages of running SSH daemon without root?

The sshd is commonly installed on a system to let users log into this system from remote. To be able to do this at least parts of it would need to run with elevated permissions because otherwise it would not be able to check users against a local password database, access the key information (like authorized_keys file in OpenSSH) for key based authentication and finally being able to login as the specific user.

But, if all you need is to have a sshd running in order to be able to login as a single specific user with key based authentication these problems should not matter. But what matters in this case is that everything is run as the same user account in this situation and thus bugs in any component of the sshd can fully affect this single user. If you compare this with the privilege separation architecture of the OpenSSH server then you will see that it runs critical parts with very low privileges and sandboxed so that a bug in these components have only a low impact. This kind of privilege separation is weakened if everything is run as the same user which means that this setup might provide less security compared to the common setup.


Firefox switches charset encoding, brings up request to install extensin. Is this a "browser virus"?

Three "diagnostic" procedures to try (perhaps not the best thing, safety-wise) are:

Check the same sites with your other browser.
Disable all your extensions, and restart the browser normally.
Restart the browser from the command-line with firefox -ProfileManager, create a new profile, and have the browser start running with the new profile.

If you don't experience the same phenomenon when doing any of the above, it's most likely malicious code in one of the extensions you've installed.

Note that a perfectly benign extension can theoretically become malicious by virtue of an auto-update, if someone had exploited a vulnerability in the extension author's system, at Mozilla, or somewhere along the way. Of course - you might have installed an extension which seemed benign but start acting maliciously only now.


Using SELinux to isolate a binary AV scanner to only doing its job, scanning and detecting

Yes, you could do this with SELinux - but why on earth would you want to?

You're requirements appear to skip over the most likely route for information leakage, and that which launched Kaspersky into the headlines recently and led to major changes in the way software is sourced and integrated. You make no mention of restricting network access. Again SELinux is quite capable of doing this.

  The way i see it, a couple rules

Ah, now we come to the tricky bit.

Not a couple of rules. A lot of rules.

It's relatively simple to do with apparmor. Or without any MAC, you could run it chroot with a read only loop back to the real filesystem (NFS, Fuse, Overlay) in its own network namespace with its own network routes / iptables.


Summary. The best defense against code injection is to prevent it in the first place.  Generally speaking, once malicious code has gotten onto your system, there is no reliable way to detect it.  I know that you were asking about detection, but I recommend that you focus on prevention, not detection.

Prevention. So, how do you prevent code injection?  Generally speaking, through access control, good security hygiene, and secure software development processes.

If you have a web server, don't share it with other people.  It is easy enough to use virtualization to provide isolation between multiple tenants.  For instance, if you buy shared hosting from a commercial shared hosting service, they will use some form of virtualization to isolate their customers from each other.  (This has nothing to do with FTP access vs shell access.  As long as the customers are isolated from each other, it doesn't matter whether the hosting provider provides shell access or FTP access.  They just need to make sure that other customers get access only to their virtual containers, and not to yours.)  Similarly, don't share your passwords or cryptographic keys with others.
Practice good system administration practices, to prevent compromises of your server.  Keep your software fully updated and patched.  Use firewalls to limit access to only those services you want to expose.  Use SSH with public-key authentication for remote login.  If you need to use passwords, make sure you choose long and strong passwords, never share them, and only send them over encrypted channels.
Practice good software development processes.  Avoid introducing security vulnerabilities into software you write.  Entire books have been written about how to go about doing that, so I won't try to explain in detail here; I'll simply flag it as something that's important, to ensure the software is free of security vulnerabilities.


Using specific firefox profile of Tor instead of Torbrowser

One major feature of the Tor browser is that it (mostly) avoids browser fingerprinting. By default they all have the same fonts, screen-size, supported extensions ect. With other browser you can often uniquely identify them, see https://panopticlick.eff.org/ for a demonstration. The fingerprint can then allow that user to be tracked, both when using Tor and when not.


Hosting an "IP Rental" address. Is this common, safe?

Yes, there is significant risk to you. The value of allowing someone else to "rent" access to a DSL connection at your house is so that they can pretend to be you in their online behavior. If it's your name and address on the agreement with the ISP, then typically you're the one responsible for what happens on that connection. Actual legal liability varies by locality, but your exposure it typically pretty significant.

There have been several instances all over the world (Austria, Germany, USA, and others) where individuals have been arrested and charged because of illegal traffic (usually child porn) going through their Internet connection (typically TOR exit nodes).

Whatever this individual is planning, there's a decent chance that it will end up with you in jail.


Are there any hardware encryption solutions for my notebook?

One of your actions should be to talk with HP's support about this, and hear which encryption solutions HP has validated for this need. Full-disk encryption is common for 'business class' notebooks. You can look into:

Laptop 'hardware' level full disk encryption, via a harddrive that has a built-in encryption engine and the laptop's Trusted Platform Module and BIOS. This can offer excellent performance and simple operation, on the flip side, it generally doesn't protect you when doing a 'soft' close such as Windows's Sleep or Hibernate.
Operating system built-in or pre-OS load software full disk encryption such as Microsoft BitLocker, LUKS, Truecrypt boot disk encryption, or PGP's full disk encryption. Wikipedia has a really nice overview of these.

What you want goes a bit against the common solutions in this space:

You can get 'hardware' full disk encryption, but then you only enter the password when booting up from a full power down.
You could use 'software' full disk encryption such as Microsoft BitLocker, but then that's not "hardware" as you want it.
Or you could leave your boot drives un-encrypted, and have a data-only partition that is encrypted via fx Truecrypt, and is automatically un-mounted when you Hibernate. But that's not full disk encryption, and would by default fx not encrypt your browser history and saved form data.


Secure cookies - set them in application or the webserver?

Using the webserver makes sure you don't forget any cookies. Using the application makes sure you can make a cookie without the flags, which may be important especially for httpOnly.

I recommend using both, so that if you need, you can disable the server one and just use the one in application for cookies that need the flag and also create cookies without it. It would be undesirable to have to go trough the code in retrospect looking for all the places cookies are used.

Of course, you may be able to create an exception in the server config as well, but better safe then sorry. Using both is the best option IMO, as there is no reason not to.


Does displaying images on profiles by URL have security implications?

i tried many php scripts like http://attacker.com/omg.php and it doesn't runs the script on my domain ..

The problem here would not be a server side vulnerability but more of a reflective XSS vulnerability that runs on the browser not on the server which is why the php file did not work.

Taken from OWASP (see here):

  Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.

If I attached a file (lets call it script.html) and had Javascript execute there then any one viewing the "image" will run the Javascript on their browser.

For example:

I am a user on your website  and I attach a profile picture with the link http://mymalicouswebsite.com/script.html and in the script.html file I have the following code:

...Some HTML...
<script>
    window.onload = function(){
        //Anything I put here will run on any viewers browser
    }
</script>
...Some HTML...

This can be even worse, the attacker can do the following:

Replace your whole html body with any content he wants (he can load an iframe which is a phishing page)
He can steal users cookies and send it to his page using AJAX
Redirect the user to a drive by where a virus will be downloaded and the user will think its coming from your website

  Now, Is there any Possibility of Attack vector here, If yes, kindly suggest me. And also is CORS or SOP Bypass possible here, I have CSP protection of the domain.

CORS is when an HTTP request comes from a script which is not this case. What you are doing is as if you are loading an iframe.

About CSP: I would have to see your setting that are set to see if an attack can be made...


Does a TLS interception proxy present the user's browser with the end server's certificate?

The certificate sent to the client will be the one generated by the proxy, not by the originating server.  It can't send the end server's certificate because that certificate is specific to the key in use by the end server.  If it changed out the key being sent to the client and didn't change out the certificate, validation would fail because the calculated hash of the public key would not match the hash in the certificate, rendering it invalid.

The browser or TLS client should show the trust path to whatever CA the intercepting proxy is using, whether installed by default (there are actually intermediate certificates for sale for these sorts of MITM setups, if you're a big enough corporation!) or installed by an organization through policy/management.


Is it safe to upload videos in cloud tools like video editors?

If you're asking a technical question, then no. If you upload your data to some website then website has the ability to do whatever it wants. Use offline editors to protect your privacy.

If you're asking a legal question, then it depends on the website's ToS and the laws that are applied to owners of the website. Also this is the wrong place for legal advice and I'm not a lawyer.


Is Drupal's filter_xss enough for filtering HTML?

I'm not sure whether Drupal's filter_xss is safe.  According to the link you provided, Drupal's filter_xss is based upon the kses library for HTML filtering.  To put it bluntly, I don't trust kses or kses-derived filters.

If you look at the code of kses, it is based upon a monster regexp.  That's a crummy architecture for a HTML sanitizer, and I don't trust anything that's built in that way.  If you have to filter arbitrary HTML, the proper way to do it is to parse the HTML and then operate on the parse tree.  (HTML Purifier works that way, and partly as a result, I trust HTML Purifier a lot more.)

Historically, kses has had some security problems.  See, e.g., Vulnerabilities in kses-based HTML filters and HTML Sanitisation: The Devil’s In The Details (And The Vulnerabilities).  I don't know whether those vulnerabilities affect Drupal's version, but they don't inspire confidence.  So, if I needed HTML filtering, and if I were choosing based upon security, I think I'd probably choose HTML Purifier over filter_xss.

I should also back up a little bit.  You didn't say much about the situation you are facing.  Are you sure that HTML filtering is the right tool for your job?  In my experience, it's a lot more common that you need HTML escaping (output encoding) rather than HTML filtering.

If you are including untrusted input into a HTML document, you need to decide what kind of functionality you need:

HTML escaping, aka output encoding. Is the user-provided input "just plain text", with no rich formatting?  If yes, use HTML escaping (also known as output encoding), not filter_xss.  When doing HTML escaping, you want to use context-sensitive escaping, to escape the data in the proper way for the parse context where the untrusted data will be inserted.  To learn more, read the following resources:

OWASP's resources on XSS, including the OWASP XSS overview and the OWASP XSS Prevention Cheat Sheet.  The OWASP ESAPI library has output escaping functions for all HTML parse contexts you are likely to run into.
Filter user input before the database or upon display?
Reducing XSS by way of Automatic Context-Aware Escaping in Template Systems

HTML filtering. Do you want to allow the user-provided input to contain rich HTML formatting?  Do you want to allow the user to enter in nearly-arbitrary HTML, which you want to include verbatim into the output document?  If yes, you need a HTML filter.  In this situation, HTML Purifier is an excellent choice, and probably safer than Drupal's filter_xss.  That's just my personal opinion.

When inserting user-provided input into a HTML document, my experience is that probably 95+% of the time you want HTML escaping, not HTML filtering.  HTML filtering is the exception.  (How often do you expect users to enter in HTML markup?  If you're writing an application for the general population, the answer is: almost never.)  So, are you sure you need a HTML filter anyway?


Is the Java programming language used for penetration testing in practice ? If so, does the same apply to C#?

You can write penetration testing tools in Java or C#.

Armitage is evidence of this. And you can search for vulnerabilities in Java code but not vulnerabilities like buffer overflows or format strings. I don't know the name of these vulnerability types but let's say that if a condition is wrong and with given input it grants you some privileges. Also Java is good because Android has a massive entry in today's technology.


Sqlmap: bypass website security filtering SQL reserved words

I had a similar situation with a test, the applicationn used SQL server, there was a WAF filtering the data input, then I couldn't use reserved words, because the WAF was blocking the reserved words. The solution was double encoding, you just need to apply double encoding to one letter, for example, you want to inject AND, if you encode letter A using URL encoding, you will have something like this: %41ND; the WAF will interpret those characters as A, then it will not work, then you have to apply a second encoding on the %, then you will have something like this: %2541ND; the WAF will interpret the %25 as % and the database will receive the %41ND, it will do a canonicalization process and execute the command AND. I exploited this SQL injection manually, I'm not sure if SQLmap has this bypass technique, I recommend you to review the tamper options, maybe there are something similar.

Good luck.


Can I rely on these GitHub repository files?

Compilation is not a directly verifiable deterministic process across compiler versions, library versions, operating systems, or a number of other different variables. The only way to verify is to perform a diff at the assembly level. There are lots of tools that can do this but you still need to put the manual work in.


Client app auto-updating passwords, no SSO

Your application should be able  to use ADFS or LDAP to send authentication questions to the AD, without your application having to know anything about the users and their passwords. You'd essentially use the AD as a directory server.


Website doesn’t always log me out – Privacy concern or am I overreacting?

You are absolutely right that the website should not behave like this. I'd say this particular issue is fairly low risk. But it makes me wonder: if they have this problem, what other problems do they have? More serious problems like SQL injection could allow an attacker to steal all the users' data.

The response from their support department is not satisfactory. However, I've found that to be a very widespread problem - even with some services I'm generally happy doing business with.

How much of a problem does this present you? I presume you are trusting the site with some personal data, but how much? How would a breach impact on you? With recruitment site, people often worry about their current employer finding out they are on the site. I would usually think it unlikely that your boss would mount a hacking attack on a site to see if any of the team are using it. It's far more likely to be an organised cyber crime gang hoping to use the data for financial gain.

There are some practical steps you can take to defend yourself, such as using a single-purpose email address that you've created only to use with that site. Ultimately you need to decide if the security risks outweigh the benefits to you of being on the site.


Securely storing bank account details in database

The password is hashed with bcrypt, and the public and private keys
  are stored alongside the password hash in the user table.

Storing the private key means a compromise of the database would allow attacker to decrypt the bank information.  You might as well store the bank information in plain text.

Why exactly would the bank information need to be encrypted by the user's key anyways?  Is the user going to request that information "please tell me the bank account I told you about earlier"?


How should clients' passwords be managed?

In an ideal world, you should never use other peoples passwords, and therefore you should have no need to store them. If you need to use a service on behalf of a client, you yourself should have an account at that service and the client should make sure your account has sufficient priveliges for you to do your work. Here you have a clean division or responsibilities - you are responsible for your own account.

In the real world, this is not always possible. You should avoid these situations as much as possible, and only take responsibility for other peoples passwords when you really have to. But let's face it, some times you just have to.

Then a password manager is the best solution. Some advice for how to use it:

Pick a good master password. And when I say good, I mean good.
Consider using an offline password manager, so no files uploaded to any servers anywhere.
2FA (e.g. require a hardware token to decrypt) is also a good idea.
You may want to create separate accounts for each client. Only do this if it is feasible without compromising the quality of the master password.
Finally, be completely transparent with the person who's passwords you are handling. You want to make sure that they know and accept what you are doing. There are probably a ton of legal aspects to this as well, but unfortunately I have no insight into those.


which memory hard hashing algorithm can equalize low-computational and high-computational power devices to utilize blockchain in the IoT?

While memory-limited algorithms are discussed in the altcoin community ("alternative" cryptographic coins based on ideas similar to bitcoins), they do not primarily solve the disparity between a "low-end" general purpose computer (e.g. the RasPi) and a high-end general purpose computer, but they are used to prevent special-purpose hardware that exceed computational power (also computational power per Watt) by multiple orders of magnitude. The idea is that hashing does not need much chip space, and you build a chip that calculates many hashes in parallel by just copy/pasting it many times into one case. On the other hand, memory does need space, and megabytes of memory need lots of space (take a look at current processor die pictures. The vast amount of die space is occupied by caches, not by the calculation engine). For bitcoins, special-purpose bitcoin mining chips (FPGA miners and later ASIC miners) "took over the world" around 2 years ago, because they outperform general-purpose machines. That's the reason coins like DogeCoin use the Scrypt algorithm already mentioned by sukosevato.

The ration between RasPi memory (0.5GB) and an enthusiast's PC (32GB) is likely even greater than the difference in CPU power between those devices, so going memory-limited doesn't help the RasPi to catch up. In fact, if you can not prevent a device that has n times the computational power and n times the memory of a smaller device, to just behave like n of the smaller devices.

So in summary: I don't think you can find a hashing algorithm based on CPU and memory operations that does not give fast (gaming) PCs a big advantage over the Pi (which still has a lot of computing power).

Addressing your second question, sukosevato is right again: There is no way to prevent a device claiming to have a lower computational power than it really has. A fast device pretending to be a slow device can be caught if it systematically takes advantage - if you know the hashing speed of a device, you know how many coins it sucessfully mine in a certain time interval. If it takes advantage of getting "small devices bonus" by needing to solve less difficult hashes, and submitting more solutions than you can realistically find with the small device, the network could try to ban you.

The only reasonable way I see to prevent devices claiming too low computing power is to make showing the increased computing power more advantageous than hiding it. Alas, this directly translates to: The faster device must be able to convert the full speed advantage to profit, otherwise it could try to play slightly unfair and exploit the "slow device bonus".


Can I use `lsof` to reliably determine which local process has connected to my open port?

If you trust the user running lsof and specify the full path (/usr/bin/lsof?), you should be able to trust the output.  If you're aiming for lsof to run as the user who is connecting to your server, it's really difficult to prevent an lsof in their path from running or an alias catching the call first.  Also see 'netstat -A inet -A inet6 -alp'

If you're really paranoid you could check the package manager database (rpm, dpkg, etc) to make sure that the binary hadn't changed since install before calling it (with the full path).


How can I locate and purchase SSL certificates that contain a specific trust chain?

You ask CA to issue a certificate. This certificate will be signed by CA and its signature will be confirmed by its certificate. You cannot force CA to use a certificate with particular trust chain.


Why doesn't SMTP check that users are authenticated to send from an address?

So is there a reason why we don't check?

Because SMTP was designed at a time where the sender was considered trusted. The origins date at least back to RFC 788 from 1981, i.e. at a time where only comparably few nodes on the internet existed, mails could be easily traced back to the sending node by IP address and sender spoofing was not an issue.

  It would seem to make sense we'd have some form of digital signature to check.

A digital signature would require to have each sender some kind of key or certificate in the first place. Also this certificate would need to be widely trusted because otherwise one could not really check if the sender is the one he claims (i.e. self-signed certificates would not help). One also would need some infrastructure to revoke and renew certificates in case they were compromised.

Instead it is common today to require authentication by the end user. But since SMTP is a hop by hop model where the end user only sends the mail to the first hop and the next hop forwards the mail in behalf of the original user  the other hops are still somehow need to trust each other. There are some mechanism to make at least sure that the claimed senders IP address is somehow associated with the senders IP (SPF), to have some trustable path between mail servers (DKIM) and to align the SMTP.MAILFROM with the RFC822.From (i.e. SMTP envelope with mail header) as done with DMARC. Only, these "add-ons" are not sufficiently employed to broadly protect against sender spoofing.


How can I see the websites visited by clients of my WLAN?

You can intercept the traffic by building a bridge between the AP and the uplink. This can be done by using the bridgeutils and two network interfaces.  The software side is described here.

This will allow you to capture and view all traffic. You can then display the data in wireshark or use a transparent proxy to get the informations you want in a protocol specific way. You can use squid for http for example. It will not be possible to read encrypted traffic unless you have administrative privileges on the hosts that are connected.

You can also only display the DNS requests to gather information abour what hosts are resolved. This will not only include all hosts that are used as http servers but all hosts that are used by your clients.

When you have administrative privileges on the hosts connected you can install a fake CA certificate in the browsers and the OS list and then intercept the SSL connection using a tool like mitmproxy which is described here.

To be specific for whatsapp have a look at this article it will almost surely not work.


Securely map random string to a custom charset

You can [65, 66, 67] convert to 656667. Since you can recompute it back, it would be of same security level. However, I suppose this is not what you really want. I guess, you want the result with as little letters/digits as possible.

Consider the password as a n-base number where n is number of possible characters in the password. What you really want is to convert n-base number (password) to m-base number where m is number of character in the destination set. It's easy if you have just small numbers which can be held in the integer value. It's more difficult with larger numbers however, you would need just a middle school arithmetic.

For example, we have 26 letters a..z.
bcd = [1, 2, 3] would be 26-base number (letter a is 0). You can convert it to integer easily:

n = 1 + 26 * 2 + 26^2 *3

BASE = 26
res = 0
k = 1
for n in abc:
    res += n*k
    k *= BASE
return res

It's like 1234 = 1 * 10^3 + 2 * 10^2 + 3 * 10^1 + 4 ^ 10^0 just 10 would be 26 :-)

Then, you can convert it to 10-base (or whatever base) number:

BASE = 10
while(n):
   out.append(n % BASE)
   n=n/BASE
return n

As I mentioned, the problem could be a large number. You can implement it by yourself and it's not as difficult as it looks, just use the base division algorithm which you learned on your middle school or even earlier, or you can try to find some big-number python library which would be even easier.


Can an app access location services when I turn off location services?

No, because ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION permissions can't turn on and access location services if they are disabled (assuming your phone isn't rooted). However, the app could still try to enable location services or find your location with other methods.

Vulnerabilities have existed to turn on location services without user interaction, however there is no intentional way to enable GPS programmatically without user interaction.

Without allowing the location permission, apps can still see your external IP address and router BSSID. Your IP address can be used to
 try to find your location which will probably only be accurate to the city / region (iplocation.com).

Your router's BSSID could be used to find a more accurate location if somebody has used a wardriving service like Wigle to map out your WiFi network location on Wigle's global map. This would allow the app to enter your BSSID into Wigle's API and find a precise location. If you were to have enabled location services, the app could gather BSSID addresses of networks around you for a more accurate location.


Does adding random noise and/or resizing images help neutralize graphics files with embedded exploits

It depends. The specific example you gave is for an XSS exploit, which is not an exploit of image viewers or decoders. Modifying such an image may destroy the malicious code, depending on the kind of exploit. If the image is corrupt such that it will exploit an image viewer, editing the image in any way (including resizing it) will very likely pass it through the same vulnerable decoder (e.g. libpng) as the one used by an image viewer. Consider this simplified view of how an image editor works:

A source image is passed through a decoder which converts it into a pixel map.
Any modifications to the image are made to this raw pixel map, in memory.
The pixel map is compressed and converted into a standard image format.

Now compare this to how an image viewer works:

A source image is passed through a decoder which converts it into a pixel map.
The pixel map is displayed directly on the screen.

The first step in both instances are the same. Unfortunately, this step is where the vulnerable image decoding library is affected. In many cases, modifying an image is actually worse because the decoders are often more complex in order to support a wider variety of obscure formats and features.


How key_derivation and key_verification functions are implemented of a 7-zip archive's encryption mechanism?

Key recovery works like this.  The tool guesses many possible passphrases.  For each passphrase, it tests whether that passphrase is correct.  It keeps going until it either finds your correct passphrase, or until you get tired and give up.

So, how do we tell whether the passphrase is correct?  Normally the method would go like this.  We use the key derivation algorithm (the same one that would be used when you decrypt the archive using the 7zip program) to compute the derived AES-256 key.  Then, we try decrypting a few blocks of the ciphertext under this key.

Tyipcally, the plaintext has a hardcoded constant at some fixed position, so we can check whether our guess was correct by checking whether this constant appear at the fixed position in our trial decryption.  (Sometimes, for some file formats, there is no hardcoded constant, but there is a checksum, so we can try decrypting and see whether the checksum is correct.  Or, for some file formats, we may know that the plaintext is typically ASCII, so we can check the trial decryption to see whether it looks like plausible ASCII text.)  The exact method used depends upon the file format, but usually this stage is not a serious barrier.

This approach is known as trial decryption, or brute-force dictionary search, or a dictionary attack.  All of the smarts come in the part that I didn't talk much about: how to come up with a list of plausible guesses at the passphrase, in some intelligent order.

See also Brute-force heuristics used in password cracking.


For security, one important thing to take into account is that an exhaustive search on the master password is feasible. Schematically, an attacker who got a site-specific password (e.g. an evil admin on that site) can run your Java application (or some code of his own which applies the same algorithm) and "try" potential master passwords, to see if it yields the known site-specific password.

If your master password is fat and random (say, at least 70 bits of entropy), then this won't be an issue. However, if your master password is more "normal" (a "strong" password is, say, 45 bits of entropy), then this is a weakness. The situation can be improved by using proper password hashing:

You need the transformation from master password to site-specific password to be slow through the use of many iteration.
You need a salt. In this case, imagine that 10000 people use your system and all have an account on, say, google.com (a fictitious example). They will all use "google.com" as "password use". Correspondingly, an evil admin at google.com could attack all the 10000 master passwords in parallel, with a lot of cost sharing. You could use your own name as salt; names are not utterly good salts, but this would still significantly improve this situation.

This is "brute force", but with human-remembered passwords, brute force tends to work.

For usability, there can be some issues:

You have to remember what password length you used on each site.
Some sites have special requirements, and there is no "one size fits all" set of rules which works everywhere (e.g. some sites make it mandatory to use punctuation signs, while some others prohibit punctuation signs).
Some sites may mandate password changes. By definition, your applet cannot tolerate a password change, unless you use a new "use" string, and then you have to remember it.
In addition to being suboptimal for password hashing, Sun/Oracle's default implementation of SecureRandom is not well specified, and not guaranteed never to change. If Oracle decides to modify it at some point, all your passwords will be lost. You really should rely on some algorithm which is not subject to such changes.
Good luck running your Java code on your iPhone or iPad. For real portability (including making your code run on the machine you will own 5 years from now), you may need to implement your algorithm in several languages, because there is no such thing as One Language To Rule Them All. This again implies using a well-defined standard, and not "what Java appears to use for now as a PRNG algorithm".

For all the reasons above, making a "password wallet" which does not need storage space is challenging. This concept has been proposed and even implemented many times, and that may work for most sites, so you may tolerate it for your own usage. Depending on your own context (which site you use, what kind of hardware and OS you own...).


Harden against privilege escalation in Microservices

Considering that you don't want to do this on server-side, I see only two other possibilities:

Go with security through obscurity, and never expose the Customer-Id on user facing (any action that make it show up in address bar, UI, browser history etc.). This won't patch your problem and will not protect you against a dedicated attacker. Though it might work at certain degree.
Use Stateless Self-Contained Tokens (eg. JWT) for generating the user session. And store all the customer-id's that are bound to that user on the token itself. Then, when you verify the session token server-side, you will also get authorization at same time. This would not cost in performance at all. Though, it might work as a solution only as far as you wont have a lot a customer-ids bound to a user (obviously you don't want the whole DB in the token).


The connection is unencrypted UDP (if you
  know how to properly encrypt UDP, than tell
  me)

DTLS (Datagram Transport Layer Protocol). DTLS works very similarly to TLS, but is instead designed to be used in UDP and preserves UDP semantics (unordered, no automatic reordering/resend, low latency). DTLS is widely used to secure UDP, for example in WebRTC, Cisco AnyConnect VPN. The widely used SSL libraries OpenSSL implements DTLS.

  Alice, with my game, wants to connect to
  Bob's server, which is designed for my
  game. Alice can get a token from my
  official (trusted) server. She also needs
  to authenticate on Bob's server to prove
  she is really Alice. But if she sends the
  token to Bob directly, Bob can exploit her
  token.

Alice need to create a client certificate and have the client public key be signed by the trusted server (acting as a CA/certificate authority). Alice then presents this certificate during DTLS handshake to Bob to authenticate itself as Alice. Bob trusts this certificate because the Certificate is signed by the trusted server and Alice was able to prove that it owns the corresponding private key by successfully completing the handshake. Bob cannot use Alice's certificate to impersonate Alice because a Bob doesn't have Alice's private key.


How dangerous is referencing a variable out of its lifetime

The issue of using of using memory outside its lifetime is that its content might have changed in an unexpected way.

Consider a dynamically allocated structure with a function pointer as field. If this memory is somehow freed, it is possible that the next memory allocation request points to this memory. An attacker controlling this memory might put data in it which is then interpreted as a function pointer to malicious code. This is an example of arbitrary code execution.


How do I use Windows 7 virtualization features to prevent transitive trust of admin credentials?

I am also not entirely sure I understand - so let me offer some possible solutions:

Use three separate virtual machines as described here by a rather famous security researcher. Essentially - each virtual machine is a totally separate environment, ideally speaking as if you had three separate computers. In order to effect this, you'll need a virtualisation solution of some form (virtualbox, vmware etc).
Use different accounts and don't use RunAs. You risk data leakage this way but it's a lot easier than spinning up the required virtual machine.
Use RunAs and accept the risk.
Do not use RunAs.

I should briefly talk about those virtualisation features. Those features are provided to enable XP-mode to work through Microsoft's VirtualPC.

Clearly, do not use RunAs is not acceptable and using three VMs might be a bit painful, as is constantly logging out as in 2. There might be a way you can make this work for three:

In terms of current administrator accounts, what actually happens is that your ability to act as an administrator is curtailed by privilege levels. Three components come into play - UIPI, Mandatory Integrity Control and separate desktops via CreateDesktop. How they interact is complicated:

MIC says each process is either High, Medium or Low Security. I think it also includes a DRM level - and I know it also includes a System level. In either case, the idea is that a Medium object cannot meddle with a High object. See here and here. Likewise a High object cannot read a medium object - this is no write up/no read down in action.
UIPI says that only certain messages can be sent from Low to Medium and Medium to High processes. The whole GUI model resolves around sending messages; if hardware generates a event, that's a message in your message processing routine (usually called WndProc).
CreateDesktop creates a whole new blank desktop. Sysinternal's rootkitrevealer does this, as does KeePass, as does consent.exe, your UAC dialog process.

What makes consent.exe secure is the combination - not only is the process run as NT AUTHORITY\SYSTEM (which ordinarily would not be a barrier to an Administrator user) but it also runs on a separate desktop (it takes a screenshot of the current desktop and grays it out to achieve that effect I believe) and it runs as a HIGH privilege level, meaning not only can medium/other processes not get to it if run as an Administrator, but the desktop is unique and there's nothing else on it to send messages to it.

So, you could use the mandatory integrity controls to isolate some of your processes. One drawback is that you can't easily use the CreateDesktop mechanism yourself - it's a programming instruction. You can however combine MIC with separate accounts on a single desktop. You might like to read some thoughts on that by the previously-mentioned famous security researcher. With a bit of experimentation you might be able to adapt this to your needs.


The first one - "You don't have permission to access this page" - doesnt sound like the browser. The second - "This page cannot be displayed" - could be.

Different browsers react differently when they catch an XSS attack. If mode=block is set in the X-XSS-Protection header, both the latest version of Chrome and IE will give you a page similar to the one you get if you have no internet connection:

Earlier version of IE would give you a page containing only # and a warning dialog at the bottom of the page.

If mode=block is not set, both Chrome and IE will just quietly filter out the injected JavaScript and display the page without it.

If you want to test how a specific browser react, I recommend this great test page. Compare the error pages you got with what that site displays to know if it is the browser or not.

So if it is not the browser, what is it then? It is probably the page your are trying to exploit that has caught your XSS attempt and serves you a standard error page to fend off your attack. Or perhaps you caused an internal server error and the error page is a default fallback if that happends. It is impossible to know for sure what is going on behind the scenes on the server without having the source code it uses.


The rationale for unique salts is not simply to combat rainbow tables.  If your entire database of passwords is hashed without salts (or with only one salt), then an attacker can attack your entire password database simultaneously instead of being forced to attack each password individually.

Also, as mcdowella has pointed out, a password database which is not protected by unique salts can potentially fall victim to an attacker extrapolating information from the fact that multiple users are observed to share the same password.

Neither of your solutions address either of these problems.  You can make the attack more expensive computationally by using something more secure than sha1 (a high itteration count PBKDF for instance) but that isn't a replacement for unique salts.  They are easy to implement and the cost/benefit ratio of unique salting in terms of additional computation time and  increased difficulty to attack is better than pretty much any other single approach.


Does any DNS Recursive resolver accept a "DNSSEC-only" option under DNSCurve?

It appears that secure DNSSec recursive queries are not possible to enforce.

According to the notes in this IETF draft:

  DNSSEC is not an enforcement mechanism, it's a resource. When I see
  folks voice opinions that DNSSEC's recommended operation has to
  strictly followed, my gut reaction is that these folks have forgotten
  the purpose of all of our efforts. ~ Ed Lewis

DNSSEC is offered as a help and DNS servers can be configured to maintain the security of the recursion chain, or not. It also appears form Mr Lewis' comment, that there might not be a method to enforce secure recursion for some time.