Questions regarding CRLs (producedAt and not modified)

[...] is it because CRL's are seen as static files [...]?
  Wouldn't this also be an easy way for hackers to withhold updates to a CRL (as long as the old one's still valid)?

Yup. Both limitations are known. And from how I read the RFC, both are deliberate design choices.

From RFC 5280, section 3.3 Revocation: (emphasis mine)

  An advantage of this revocation method is that CRLs may be
  distributed by exactly the same means as certificates themselves,
  namely, via untrusted servers and untrusted communications.

  One limitation of the CRL revocation method, using untrusted
  communications and servers, is that the time granularity of
  revocation is limited to the CRL issue period.  For example, if a
  revocation is reported now, that revocation will not be reliably
  notified to certificate-using systems until all currently issued CRLs
  are scheduled to be updated -- this may be up to one hour, one day,
  or one week depending on the frequency that CRLs are issued.

Further reading

Related question: 2015-12-28, Why do so many browsers show sites with revoked certificates?


You can just disable javascript. There is not really a good reason items in RSS feeds should use it.


Which ports are potential security risks for nmap?

It doesn't really work like that.

Ports don't pose a security risk in themselves; it's the application listening on a port that has the risk attached.

And, how vulnerable any given application might be depends on many factors - is the application well patched? Is it well configured? So you can't just say "VNC is a risk", what VNC server is it? What version? How is it configured?

And, of course, security is always more complex. For example, I bet you picked telnet because everyone always says "telnet's insecure, use SSH instead", right? Which is true, but that's because the protocol telnet uses isn't secure against eavesdroppers, it's nothing to do with there being exploits for telnetd (i.e. the application that typically listens for telnet connections).

What you're meant to use nmap for in this context is to check that only the applications that need to have a port open actually do have a port open.

If a host doesn't need sshd, but nmap finds one listening, then you know to go onto the host and fix that. Which is nothing to do with how secure sshd or ssh is.


how IPS and IPSec work together in a host

Linux Based Router

In Linux the key exchange (generally ISAKMP) is performed in user space, while the security policies, keys, and encryption/decryption are performed at the kernel level.  When a packet arrives the kernel first processes this packet by checking to see if the SPI and IP match a security policy.  If it does the packet is processed using the policy's stored keys, and the promoted up the network stack for processing.  This is still performed at the kernel level.

Now where Snort sits in the network stack implementation is important.  As it's a user space program it receives packets from the kernel.  This is generally performed by the kernel's network filter.  Then the packets from the kernel's netfilter get passed on to user space programs like snort [1] (search Snort).

What this means for you

Kernel sees encrypted packets
Kernel determines if it has a security policy matching these packets
If yes, kernel decrypts the packets and promotes them up the network stack
Netfilter processes them, and pushes the decrypted packets up to user space
Snort sees decrypted packets and processes them.

This isn't the full process, and I'm might have glossed over a bit of the Linux kernel network stack.  But you really don't want those details anyway.

Or maybe you do...
Dirty Details on Linux Kernel Network Stack
Dirt Details on Netfilter
Filtering IPSec packets after decryption using iptables

An Interesting Side-note:
If you're sniffing packets on Router 1 with Snort or even Wireshark.  Ping through the VPN.  From Router 1 you should see both the encrypted ESP packet coming in, and the decrypted response in Snort/Wireshark.  As verification that it will in fact see both packets.


How does SELinux affect the Linux Kernel networking stack?

Access can be controlled for local processes accessing local network assets like for example network ports. By associating labels with port objects and userids, groupids associated with processes (even individual processes, allowing you to specify whether and how an entities associated with particular labels can operate on or interact with entities associated with particular labels. This is generally pretty solid. With the exception that no access control is enforced for binding sockets to ephemeral ports.

Alternately secmark allows one to associate labels with "non" local assets as they come in or go out using the netfilter security table. So the labels only apply inside the system. (for example. a packet comes in unlabeled, gets associated with a label using netfilter and then you can specify rules how other local entities associated with particular labels can operate on the labeled packets). This is a local solution using netfilter.

Really associating labels with packets as they traverse the network can be done with netlabel or ipsec. This is used to enforce confidentiality on "trusted" networks. Ipsec is preferred for this i believe rather than netlabel (Multi level security).

SELinux is generally not the optimal tool to enforce controls on the network. Other technologies are generally a better solution. Except if you want to enforce confidentiality on trusted networks.

Generally the idea is that SELinux allows you to associate security labels with many entities, ranging from individual users groups of users, or even individual processes to local and non-local assets such as for example files and network nodes.

I am aware that this does not answer the question and that my information is not fully accurate, and is certainly not comprehensive, but it is something.


Both Ophcrack and ONTP&RE incorrectly show Windows 10 passwords as blank

Windows 10 anniversary update uses new SAM encryption. Hashes are stored differently too. That's why PWDUMP seems always returns an empty hash. Windows 10 Anniversary Update and later uses AES128 to encrypt password's MD4 hash.


Python 2.7.6 with openSSL 0.9.8 unable to dohandshake with TLS protocol supported site

Accrording to the wireshark pictures the .NET client is using TLS 1.2 while your Python program is using TLS 1.0 with a SSLv2 compatible handshake. TLS 1.2 is not supported with openssl 0.9.8. Support for TLS 1.2 was only added with OpenSSL 1.0.1. TLS 1.0 is supported by openssl 0.9.8 but it is unknown if the payment gateway really supports TLS 1.0 since due to PCI requirement several payment gateways require TLS 1.2 now.

  But i am unable to upgrade my openSSL and get this working. What do you guys advice on this.

If TLS 1.2 is required by the payment gateway you've lost with your old OpenSSL version. If TLS 1.0 is possible one would need to see the code for your client and how it can be changed to not use a SSLv2 compatible handshake with TLS 1.0. But this part of the question would then be off-topic here and on-topic at stackoverflow.com.


Remotely exploit Linux kernel with CVE-2017-18017?

The description of the sechole is this:

  The tcpmss_mangle_packet function in net/netfilter/xt_TCPMSS.c in the Linux kernel before 4.11, and 4.9.x before 4.9.36, allows remote attackers to cause a denial of service (use-after-free and memory corruption) or possibly have unspecified other impact by leveraging the presence of xt_TCPMSS in an iptables action.

Running a server with a 4.4 is not enough. As the kernel.org state says, the 4.4 line is still being developed, the last release is 4.4.196 from 2019-10-07. Most likely it only gets security patches, but these it gets. It is unlikely that they had not fixed it, only it is not mentioned in the CVE description.

The test the code, you need to find a kernel which is enough old for the bug to happen. I would suggest to use 4.9.35 - it is the last kernel with a clear version and mentioned in the CVE.

So we download 4.9.36 and 4.9.35, and compare their net/netfilter/xt_TCPMSS.c. You can do this also with a git command. Check, what changed.

The difference is very small:

$ diff -urNw linux-4.9.3{5,6}/net/netfilter/xt_TCPMSS.c
--- linux-4.9.35/net/netfilter/xt_TCPMSS.c      2017-06-29 13:00:49.000000000 +0200
+++ linux-4.9.36/net/netfilter/xt_TCPMSS.c      2017-07-05 14:40:44.000000000 +0200
@@ -104,7 +104,7 @@
        tcph = (struct tcphdr *)(skb_network_header(skb) + tcphoff);
        tcp_hdrlen = tcph->doff * 4;

-       if (len < tcp_hdrlen)
+       if (len < tcp_hdrlen || tcp_hdrlen < sizeof(struct tcphdr))
                return -1;

        if (info->mss == XT_TCPMSS_CLAMP_PMTU) {
@@ -152,6 +152,10 @@
        if (len > tcp_hdrlen)
                return 0;

+       /* tcph->doff has 4 bits, do not wrap it to 0 */
+       if (tcp_hdrlen >= 15 * 4)
+               return 0;
+
        /*
         * MSS Option not found ?! add it..
         */

Note also, the ordinary networking code of the linux does not use this file. It is the MSS iptables target, thus your exploit will only work on servers using it. It should work only on data packets targeted to the TCPMSS target in the iptables.

  The TCPMSS target can be used to alter the MSS (Maximum Segment Size) value of TCP SYN packets that the firewall sees. The MSS value is used to control the maximum size of packets for specific connections. Under normal circumstances, this means the size of the MTU (Maximum Transfer Unit) value, minus 40 bytes.

What we can see, is actually 2 minor changes. As it is visible, it does not make correct boundary checks for TCP packets with an uncommonly long TCP packet header length.

How exactly can be used, it is already hardcore kernel programming. You probably need to use netlink sockets on the "attacker" side, and do some debug work on the defensive one. First guarantee that the packets you send to the host, are really getting the packet (simplest way: insmod a modified xt_TCPMSS.ko which emits printk() debug log). Then you can play with it.

Probably the development of the synthetization code (on the attacker side) will be more hard.


No, the product key has nothing to do with the security part of the OS.

If you do not activate a Windows 10 copy, the only practical inconvenient is that you cannot make desktop-related background customization. Everything else work exactly the same.

As for a key brought at a discount, it may very well work and let you activate and use your product on unlimited time or stop working later. In both cases, there no influence on the security part.

But that being said, you should note that owning a product key that works does not mean your software is licensed. The fact that MS does not care is another matter.


Increased security from separating username and login name?

Not more secure and maybe less due to user expectations and behavior.

What you are proposing is no different than requiring a user to split their password into two pieces, entering one half in the username field and one in the password field. So it can't be better than having the combined string as a password.

But users will not likely treat their username as a secret. Nor will password managers. And maybe not even you and your developers. So half the user's password will be insecure.

There are well-known patterns for working with passwords and authentication. It is usually best to stay with them.


Metasploit reverse shell through docker and virtual box

From my understanding you have the following:

192.168.10.1 (host machine)
192.168.10.2 (VM)
172.17.0.x   (docker w/ metasploit ... can be obtained via docker inspect <container id>)

Since you are running metasploit from 172.17.0.x you should instead set LHOST=172.17.0.x

This should work because the docker engine sets up a route on your host to direct traffic from 172.17.x.x to docker0 bridge

You might have to set this route in your local network router as well (172.17.x.x to 192.168.10.1)... because its possible your VM is not using your Host computer as a gateway ... and is instead talking to your actual network gateway (depends on how your VM is setup).


How secure is a password made up of three or four three-letter words?

I would have to disagree that his claim of three 'three-letter' word is secure. In his article he says:

So - 500 x 500 x 500 = 125,000,000 (one hundred and twenty five million) possibilities.
Maybe that doesn’t sound like a lot - but if you could check 20 of them every second, 24 hours a day, you would need roughly 60 days to get through them all!

First of all, password cracking tools and combination of hardware can crack way more than 20 per second especially if the list of combinations is pre generated. On top of that, if a hash of these passwords are retrieved then an offline cracking attack can be performed which means the attacker has all the time in the world to try to crack them and if it actually did take 60 days, to a motivated criminal that is nothing.
The simple fact is that 9 alphabetical characters is just too short in the present day.
12 characters expotientally makes it more difficult but using only alphabetical  isn't the best.
End of the day, I like to use a password manager and generate unique 20+ character password with alphanumeric, special characters and mixed case.


Can we make sure that the new Lavabit certificate is not under control of the FBI?

Can this site be trusted?

No.

Well, not if you consider GoDaddy subverted or subvertable. As
even the published serial number or website could be an FBI plant ;-).

But if you want your emails, you'll need to connect to the site.

  What is the reason for allowing password changes only for five days in this context?

We are assuming that the government can't coerce Ladar Levison via a gag order to provide the new private key or update his site's listed serial number within the time frame provided.

  Does it make sense to check this Serial and Fingerprint, as they are printed on the same webpage the cert is used on?

No, but Ladar is probably discreetly distributing the current serial throughout the internet.

For example, if the cited serial changes compared to the (original revision) post on Stack Exchange then the spooks may be performing a man-in-the-middle. Still, it doesn't protect against Ladar giving up the current private key though  (assuming he doesn't take a 5-day vacation in Rocky Mountains without mobile phone contact and the only copy of the server's access credentials).

  Is there a way to make sure that this new site resp. the SSL certificate is not under control of the FBI?

No. Of course any centralised email product requires trusting the provider hasn't had the new key beaten out of them - or that the new server layout and email communiqué isn't the Feds in disguise. In practice Ladar should speak the serial number (and show on a paper placard) in a YouTube video while showing his face and other 'biometric' credentials.


Is there an estimation of the number of zero-days out there?

Vulnerabilities, in general, exist before they are found by researchers so the number already in existence but not yet known could be very high. As for known Vulnerabilities that would constitute Zero-Days where an exploit exists but are still held privately by a few people or organizations, there is really no way to know because too many of these organizations are very secretive for obvious reasons. It is too hard to speculate how much effort has been put into finding Zero-Days globally much less how productive those people or organizations have been at doing so.

That said the following Rand Corporation paper has a lot of very relevant information to your question.

Zero Days, Thousands of Nights "The Life and Times of Zero-Day Vulnerabilities and Their Exploits
http://www.rand.org/content/dam/rand/pubs/research_reports/RR1700/RR1751/RAND_RR1751.pdf

Something to also keep in mind is there has been a lot of advances in fuzzing technology in the last few years which may make finding new zero-days easier for attackers.


firstly, it is bad policy to have non-individual based passwords and the first course of action would be to setup individual accounts for the users.

If the supplier cannot do that - then an alternative action would be to setup a simple federated trust model where the users never sign in to the 3rd party site but simply "single sign on" to the site using a federated trust model.  There are industry standards for this such as SAML2 that allow you (and your company) to retain the identity management (including joiners/leavers/movers).

Clearly this will only work if you disallow normal login to the third party site.  My client does this with every SaaS site that their employees use.

google for:  Federation, SAML2, federated Single Sign On.


First of all: Be careful of attacking random targets on the Internet unless you have an order to do any "white hat" / ethical hacking by the owner of the information systems you are trying to break into. Otherwise you may become liable to civil and crime investigations.

Having said that, the initial intuition would be that there is no way to tell a domain's IMAP server in a similar way as you could just lookup a domain's MX (SMTP) server through the DNS system.

But there is; at least for some domains. Some domains use autoconfiguration mechanisms to make it easy for people using their services to configure their MUAs. Take a look at

https://wiki.mozilla.org/Thunderbird:Autoconfiguration
https://docs.microsoft.com/en-us/previous-versions/office/exchange-server-2010-technical-article/jj591328(v=exchg.141)

for technical details. YMMV.

The answer to the 2nd part of your question is almost the same:

Some systems use the user's email address as a username, some don't. But if the domain in question is configured to use either Autodiscovery or Autoconfig, the service will also tell you the username that belongs to an email address.

Please not not disregard my warning in the beginning! You may harm yourself.


Yes, your scenario is acceptable when CA itself has SHA1 certificate, while signing issued certificates with SHA2.

Refernces:

Internet PKI: CA Browser Forum (CAB Forum) baseline requirements, §6.1.5

Microsoft: Windows Enforcement of Authenticode Code Signing and Timestamping

Google: An update on SHA-1 certificates in Chrome

All these references from major vendors include explicit information that SHA1 root is acceptable, while non-root certificates MUST be SHA2.

Edit to reflect your second question.

CAB Forum requirements are designed for their members (public CAs). Although, it is not recommended practice to issue end entity certificates directly by root CA, it is acceptable from browser perspective. In fact, most badly designed private PKIs consist of single Enterprise Root CA which issues certificates to end entities. Although, it is completely acceptable, it is insecure.

Instead, I would recommend to implement a 2-tier PKI with offline (offline here should be treated literally. It MUST NOT be connected to any network) Root and online Subordinate Issuing CA which will issue certificate to end entities.


TL;DR - As long as you don't expose your XAMPP server outside your LAN, and use the practices that mentioned in the link you attached - It's pretty safe, and personally I wouldn't worry too much.

When you are installing XAMPP server, you are actually adding few attack vectors to your computer:

PHP code that maybe (hopefully all your code will be safe :) will
have some vulnerabilities
Apache Server (pretty cool and famous vulnerability for example)
MariaDB/MySQL Server (that's the PHPMyAdmin panel)

However, those attack vectors, on default, are only accessible inside your LAN, thus preventing someone to use them.

Having said that, installing it on a VM will give you somewhat more protection, since someone who will use one of the mentioned attack vectors in order to run code on your machine, will have to get another guest-to-host vulnerability (and that's not a trivial vulnerability to have).


Architecturally this is likely to be reasonably secure, however there are still some things to consider.

Do you have Full-Disk Encryption on any laptops which will be accessing the service? If not there are some risks if a device is lost, as the credentials for accessing the network will be stored on the laptop (cached windows creds and the machine certificate if used)
How will the guest network be configured exactly?  I've seen some implementations where there's some information leaks where the guest uses the internal DNS servers, so they can query internal server names.  A minor point on it's own but worth thinking about.
Be careful to check that the APs are correctly configured.  Most implementations have both networks on single APs so if there's a configuration issue it can lead to unauthorised access to the Internal network.  If you think of your access points like firewalls in terms of change control (as they effectively segregate an untrusted network from a trusted one) that's a decent way to go.
It's worth making sure to use something like WPA2-PSK on the guest network, I've seen quite a few implementations where it's unencrypted and it just leaves guests at risk for no major benefit (assuming that they'll need to authenticate anyway via a captive portal or something similar)


Why are SSL handshakes secure and why can't a hacker look at that and decrypt the data?

See the Handshakes section of Thomas Porrin's answer to How does SSL work? for full details, but for the very short answer:

Because the first handshake of a sessions ends up using asymmetric cryptography to encrypt a symmetric key to the other side's public key (which is indeed available via packet sniffing), and then the other side uses their private key to decrypt it.  This private key is not transmitted between the two, and without it, it is prohibitively difficult to decrypt the message containing the symmetric key (barring implementation or design flaws).

After the symmetric key is transferred, then a symmetric cipher can be used since there is a "shared secret" key.


How to analyze and track what data a software sends?

With wireshark you can see all the incoming/out-coming traffic at your network. You can install wireshark at your vm.

It shows you a breakdown for every packet being exchanged from your network, you can see all the information of that packet including ip source, ip destinations,payload, protocol being used etc.

Once you've found a suspicious packet you can right click it -> follow stream which will show you the entire exchange of packets between your computer and the target server.For every packet you can see its payload,which is the actual content of the packet.

The payload will be in HEX form and possibly encrypted which is a downside at tracking exactly what information is sent.


Replace /se/invalidLogin with some page text that's encountered when the login is wrong.

e.g. "Incorrect password"

Hydra will check the text on the redirect target.


BitLocker : Update Volume Master Key and meaning of "keyed" vs "re-keyed"

The diagram in the page you linked demonstrates the functionality quite well. The idea is that the authentication mechanisms are all capable of decrypting the Volume Master Key (VMK), which then in turn can unlock the Full Volume Encryption Key (FVEK).

The idea behind this is that, if any of the individual authentication parts are compromised, the VMK can be changed without having the re-encrypt all of the data on the disk. Essentially, you can just change the VMK and re-encrypt the FVEK with it.

BitLocker itself does not provide any functionality to change the FVEK, as it would require decrypting and re-encrypting the entire volume. The only way to re-key appears to be to fully decrypt the volume and re-encrypt it.

Changing the VMK, however, is certainly possible. When BitLocker is put into disabled mode, the VMK is encrypted with a randomly generated surrogate key, which is stored in cleartext on the disk during this time. As the VMK is essentially not protected during this time, BitLocker automatically generates a new VMK after it is enabled again.


Reading mail from GMail with secure access

While there may be other security problems, a big one is that this authentication mechanism bypasses Google's 2-factor authentication. If you go to the  https://www.google.com/settings/security/lesssecureapps page to enable Google 2FA while you have 2FA enabled on your Google account, Google displays this message:

  This setting is not available for accounts with 2-Step Verification enabled. Such accounts require an application-specific password for less secure apps access. Learn more

This is because there is no way for the client application to accept the 2FA input and pass it to Google.

One of the advantages of protocols such as OpenID Connect is that entire authentication workflow is delegated to the authentication provider. So when an OpenID Connect enabled application wants to authenticate, it calls the authentication provider to display the login page. This allows the login workflow to be more complex than a simple username/password.


What are the biggest security risks/considerations for hosting your own private website?

Well if you are hosting from inside your own network then you have a little bit more work to do.  ( ps don't use windows , install Linux instead , not only will it be safer but in general all the typical things that you expect to use for hosting a website are designed for Linux , apart from iis windows support is always "hacked in" )

If hosting from a third party provider and assuming that you have no sensitive information stored then you are pretty much set. Just don't reuse passwords and there is nothing of value to worry about.

If hosting from your home network then you effectively have a internet visible IP address which is easy to find ( via your domain name ), so you have to worry about ensuring that everything on that server is completely locked down ( due to the fact that if the web server gets compromised then you have to deal with the possibility that you have a malicious machine on the inside of your home network which gives access to all your data, and the potential to even sniff or inject all network data if your network is appropriately mis configured.


Can an XSS exploit on a subdomain steal the cookies of the parent domain?

A subdomain can only share a cookie with its parent domain if it is explicitly given in the set-cookie header issued by the server like this:

Set-Cookie: name=value; domain=www.parentdomain.com

Otherwise the cookie is "host only cookie"

To answer your question an xss should not be possible
Or i am wrong


Extract WPA PSK from airodump-ng output file

Assuming you have properly captured the Handshake using airodump-ng.
you can crack .cap using aircrack-ng as:
  aircrack-ng  -w  Wordlist captured.cap file


Solution to cryptographic end-point failures?

You certainly can have dedicated hardware (an HSM, or hardware security module) that both protects keys, and performs cryptographic operations such as encryption, decryption, and signing in a hardened, special purpose appliance.

The primary reason they're not more widely used is, as you have already suspected, price.  They're expensive and complicated, and the risk of compromise from a three or four letter agency (or other threat actors that would compromise a cryptosystem) is, to the average organization, not sufficient high as to justify the cost.

You also have to consider that the threat model they protect against is quite small.  Even if you're performing cryptographic operations on dedicated hardware, if the hardware communicating with your HSM (sending plaintext to be encrypted, or receiving decrypted ciphertexts) is compromised, the raw communication is still at risk...You're still only ultimately protecting the keys.  This does add a valuable layer of security, but it is still a limited layer of security.  This has to factor into the equation of whether the risk is limited to a degree that justifies the price.  In many cases (or most cases, perhaps) it does not.  The performance you can get by offloading crypto operations to dedicated hardware may justify the price, but in many (or perhaps most) cases, the security that you get will not.


VPN and SSH are similar in the sense that they both establish a trusted and encrypted point-to-point channel, but that's pretty much where the similarities end. The goal of VPN is to grant you access to a network you would otherwise not be able to access, while the goal of SSH is to grant you shell access to a particular system. They play different, non-exclusive roles -- it is perfectly common to require VPN before being able to use SSH.

There are multiple benefits of using VPN over direct ssh. SSH is a root-level daemon that gives direct access to a device. There have been 0-day vulnerabilities in SSH in the past, and who knows, there may be one lurking around the corner, giving attackers direct access to any internet-exposed system. Alternatively, a misconfigured ssh daemon may allow logging in with passwords that can be guessed or sniffed via keystrokes. Not exposing ssh on your devices directly to the internet is a very good security policy.

VPN, on the other hand, is usually done via an appliance or via a non-root daemon, limiting the attack surface. VPN also dramatically simplifies access to restricted resources other than just SSH -- e.g. internal-only websites. While you can port-forward using SSH, it is a lot more hassle compared to using a VPN. Additionally, running a VPN server allows implementing centralized 2-factor authentication, assigning static internal IP addresses to authenticated accounts, etc. The latter is useful when tracking admin access via netflows and when restricting access to internal resources by groups.

In other words, requiring a VPN connection before accessing ssh on systems is both common practice and good security policy.


Can you provide loss values on security breaches?

The return on investment for security measures is really hard to show. Companies that were compromised by NIMDA or CodeRed had their losses published. Here has a good discussion about it: Schneier on Security: Security ROI


Why did it take so long to enforce memory permissions?

It's primairly a question of cost-benefit analysis on the hardware manufacturer's side, and a question of risk analysis on the behalf of OS vendors.

The x86 architecture has provided memory page access rights as far back as the 80386, but at that time such hardware enforcement would have been expensive to implement in the hardware, and wasn't seen as necessary. Computers were already prohibitively expensive for most users, and most small businesses, so hardware manufacturers didn't want to increase the cost for the sake of a feature their customers wouldn't understand or care about.

As time progressed, this complacency became more apparent. The era of buffer overflows was upon us, and it was starting to hurt big businesses. By 2003, computer security had become proven to be a commercially profitable field, and hardware prices had dropped to commodity levels. AMD and Intel finally decided that hardware enforcement was a profitable feature, so they implemented Never eXecute (NX) in early 2004. AMD released the Athlon XP-M "Dublin" with NX support, and the first Intel processor to support it was the Pentium 4 Prescott (revision E0). However, at this point, the market share of processors with NX was minimal.

The major barrier to software implementation was that Physical Address Extension (PAE) had to be enabled and supported before NX was available for use. This meant extensive changes to core memory management inside the OS kernels.

Another part of the problem on the software side was poorly written applications. Some code relied on the ability to erroneously execute data that had not been placed in memory pages marked as executable. With the advent of hardware enforcement of memory access flags, these programs would throw an access violation. Careful consideration of the benefits was needed before going ahead with the changes. DEP as a concept, without hardware support, was considered as a potential feature of Linux at an earlier date, but it was rejected due to complexity problems, breaking changes, and the fact that the software enforcement mechanisms could easily be bypassed.

Once hardware support was available, operating systems had to be modified to use it. This was not a trivial task. DEP marks certain important structures, such as the stack and heaps, as non-executable. This required every initialization routine that dealt with creation of threads and processes to be modified to support NX, as well as certain changes to memory management (e.g. heap allocations). Finally, some hardware abstraction layer code had to be modified, in order to properly recognise the NX flag on supporting processors.

All in all, this actually happened surprisingly quickly. Once the hardware NX enforcement was available, both Windows XP and Linux released NX-compatible builds within 8 months.


Root certificates don't need to be revoked unless they are compromised. In case they are compromised they can be revoked by placing them on a blacklist within e.g. a browser, or by removing them altogether. Obviously it's not possible to just create a CRL as there would not be a trusted private key; instead this is a out-of-order operation.

In general it's better to create a new root certificate and let the old one expire. Note that the underlying certificates should have an expiration date that is lower or equal to the expiration date of their parent. Of course the new root certificates need to be communicated securely to e.g. the browser manufacturers. How this can be done is generally communicated by the browser manufacturers, e.g. see the Mozilla policy here.


Can the ISP (or anyone spying on my WIFI network) see which VPN IP I'm connecting to?

Yes, your ISP would be able to know the entry IP of the VPN you're connected to. They are the ones connecting you to that specific IP, after all. They should not be able to know the exit IP, though, and therefore should not be able to see what ultimate site you're connected to or what you're doing there (this assumes the VPN is encrypting your packets properly, of course).


What is the fastest way to brute force a hardware code

This is called a De Bruijn sequence. A pattern that contains all patterns within it.


How to handle legacy website account login credentials

Use Lastpass and let it import all your passwords from Chrome. Then you have a nice database that can be shared, updated and exported easily.


Can a form submission be encrypted even though address bar shows HTTP?

To expand on Thebluefish's answer, the form submission process appears to use HTTPS (an encrypted protocol) for the credit card element to https://connect.firstdataglobalgateway.com/IPGConnect/gateway/processing when I am looking at the page.  But this does not mean this setup is safe to use.

The overall setup is very vulnerable and needs to be fixed.  I would not submit any credit card details through this service and would recommend that you do not use it.  If you absolutely need to use it, you should get a prepaid credit card with just the amount necessary for this service and then use that credit card to minimize the damage if it is stolen.  Or if your credit card offers one time use credit card numbers, you could possibly use that (though again, would be at some risk of the one time use credit card being captured and used for a different purchase).

The problem with the page is that everything but the form submission is being sent over unencrypted HTTP, that any network attacker can trivially alter.  E.g., an attacker could buy a domain and then change the domain where the HTTPS form is sent to one they control (that may even look similar).

They could keep the form sending the data to the correct domain via HTTPS, but insert malicious javascript anywhere on the page or in one of the libraries to bind an action to additionally send the form data to some attacker controlled URL.

Again, we could look at the page as it renders right now for us and determine it doesn't do any malicious actions.  But any router/ISP/computer between you and the server www.myisic.com could change the current content of the unencrypted http page to something malicious allowing your credit card details to be stolen.


Tor does not always protect your ip fully when you need to interact with the end node. You can check your efforts with online checks like this.

What has worked for me on every check I've tried is JanusVM. It runs as a VM, which you use as a proxy for your hardened browser VM. Janus uses Tor, squid, dns-proxy-tor, and privoxy to cover your ip. It is very simple and easy to setup.

I use VirtualBox's 'Seamless mode' so that my browser (in a guest VM) looks and acts like a local app on the host. Very convenient as long as you still remember which window is in the protected environment. :)


Is it really necessary for security to have login on separate page?

I do agree with him that this is a concern, there are two ways to mitigate this:

Don't load scripts from external parties
Run it on a seperate page without third party scripts on any of the admin pages

Third party scripts, especially advertisements, are sometimes susceptible to hijacking by malicious entities. There are two main associated risks with running this script:

Someone might inject a phishing form to phish your credentials
Someone might use it to steal your session information

Additionally, for most sensitive websites, we even recommend restricting the administrative pages to certain network ranges only. They should preferably not be accessible from the Internet.


A complicated SSID does not determine the security strength of your network. However, the password complexity would decrease the time cracking the encryption key. I have been doing loads of GPU cracking attacks on WPA2. With a single and decent GPU I was able to go through the famous rockyou.txt wordlist (14 344 392 password) within a hour. Imagine the speed if the attacker rented a password cracking machine. These are not too expensive and are actively being used by attackers. A long passphrase with the use of upper, lower, special characters and numbers would mitigate the risk of being cracked significantly.


Is it generally safe to disable Windows 10 Proxy Auto-Discovery Protocol (WPAD)?

Overview of WPAD:

The Web Proxy Auto-Discovery Protocol (WPAD) is a method used by client devices to locate the URL of a proxy configuration file (e.g. a PAC  file) that is being hosted on the network, using either DHCP and/or DNS discovery methods which differs based upon the browser.

Once a proxy configuration file has been detected and downloaded the browser is configured in an appropriate way to either send web requests via a proxy server, or to bypass the proxy all together and send the web request straight to the web server.

Answer

The main point to understand here is why you are looking at disabling WPAD. From a security perspective unless you operate on a network that utilises WPAD and a Web Proxy (unlikely if you're not on an enterprise/business network) there would be no harm in disabling WPAD within each of the browsers that you use.

Based on the questions which you are trying to follow on from I'd take a guess in saying this isn't an area you need to troubleshoot further and the cause of your problem is likely to be elsewhere.


Altering variable in a php file on a web server

$_POST is just as vulnerable as $_GET. If this variable is not being sanitised and/or validated later in this script then you can manipulate it however you like.


Could the unused Mali GPU in the Libre Tea Computer Card be a security risk?

A GPU is a secondary processor which accepts compute kernels, small bits of executable code that it runs many times in parallel on graphics data. The GPU is controlled by the operating system and by the firmware. Many GPUs do have the ability to perform direct memory accesses (DMA), which can be a security issue if it has been compromised. There are PoCs available which can do this, however to insert the malware and compromise the GPU, the operating system must be compromised in the first place. As a result, there are only two circumstances where one can be risky:

The GPU ships with compromised firmware, being "backdoored" from the get-go.
The operating system is compromised, which offloads malware to the GPU for stealth.

This means it is not likely for an unused GPU to be a security issue. If it is still a risk within your threat model, some systems have an I/OMMU, which can be used to isolate the memory regions a device can access. This can prevent a compromised or malicious GPU from performing DMA attacks.


Should I be worried about old viruses from a hard drive that hasn't been used in the last 13 years?

You'd have enough problems trying to get a legitimate 13 year old program to run, much less a malicious program. While it's certainly possible that malware remains that can infect your current computer after all those years, it's not likely going to be able to cause much damage. Back then, malware could rely on the assumption that the computer would run it with high privileges, allowing it to do anything it wants, such as writing directly to the hard drive. Nowadays, malware is run under a much more limited context.

Regardless, as long as you don't actually execute the malware, you should be fine. Don't run any programs that you see lying around from 13 years ago. You aren't going to get infected simply by transferring some files over unless you have some particularly advanced malware in there. Even advanced malware relying on exploits is unlikely to be able to succeed, as the security techniques Microsoft has employed has changed and been improved drastically since the malware was written.


(WMI Infections) Suspect behavior from scrcons.exe detected?

The target IP belongs to KRYPT TECHNOLOGIES, which is a cloud hosting company.

Their IPs are known to be used in an abusive manner:

they are known for using and hosting ambiguous domain names
they tend to also have malicious traffic and internet abuse trends
many of their so called legitimate websites hosted by them are actually fronts for hosting virus’s and other malicious distributed files, attacks and other malicious activities
BOTNET activities
activities that have been monitored through their internet access has been Spam, Virus Activity, Hacking Attempts, as well as Malicious file distribution

Verdic: Virus/malware.

Recommended Actions: delete files, blacklist IP in firewall.


If my company receives credit card statements showing credit card number, does it have to be PCI compliant?

Yes, your company needs to be PCI compliant.
It doesn't matter if your customer's credit cards are stored in that format or the other (PDF\in DB \ paper ...) as you wrote as long as you store transmit or process you are required to be PCI compliant.

regarding your question in the comment regarding "I don't even know if storing such document requires me to be a Merchant or Service Provider"
than the answer is you are a merchant and you might be considered as a Service Provider for your customers PCI compliant under requirement 12.8


Is it possible for hackers hack my PC by creating fake AP that my PC probed

If they know the SSID and the password then yes they can create a rogue AP that your PC will connect to.  As to the possibility of a "hack", there is a provision in Windows (and a similar feature in other OSes) to designate certain networks as trusted or untrusted.  This causes the local firewall to choose looser or more strict settings, respectively.  It is a good idea to implement this if you are connecting to public WiFi, which will protect your PC from basic intrusions. There is still the chance that a sophisticated attacker can intercept your communication and perform a complex man-in-the-middle, and the only way to guard against that is to use a well configured VPN session any time you are connected to a WiFi access point you don't fully control.


Does PT (Penetration Test) allow rooting a server?

In a Penetration test,you can root a server if you are permitted to do. The question cannot have a generic answer. It can only be specific to a each case.

The Rules of Engagement specify whether or not you can root a server. A few things are considered for this:

Is the server a Production one? If yes, then certainly you should restrain from rooting it.
If its a Test server, you have to be consider whether rooting this server can be directly be used to compromise/sniff/etc any Production servers on same network. If so, then probably you should not root it.
Businesses/Financial  Impact that you may cause by rooting the server and post exploitation steps.
Also, you have to consider the terms/agreements you have agreed to. Sometimes, there can be backlashes from management even if your intentions are good.

If you are not sure, better check with some person responsible for the servers (management).

Ultimately, post-exploitation does not require rooting a server, but is one option for performing the task.


Certificate warning when I enable DNSSEC

It all points back to DNSSEC being the culprit but I can't be sure.

DNSSec just protects the DNS records against manipulation. The error message instead stems from the certificates subject not matching the domain name used for accessing the system. These two things are unrelated.


Does Username + Password + Pin improve login security?

1) More authentication has all the Pros and Cons usually associated with it (more information is harder to hack, but harder to remember). With a pin, people are extremely likely to use birthdays and other easy to remember numbers, so social engineering might make it easier to break than a password or actual 2-factor.

2) Do you have other systems in place to prevent brute forcing? If not, you should place it on the primary page. XXXXXXXX#### is harder to guess than XXXXXXXX then #### (simple math: you'd have to guess "AAAAAAAA" 10^4 times before concluding moving on to "AAAAAAAB" in the first, but only have to do it once in the latter. Multiplication of possibilities versus addition). If so, perhaps some benefit is gained placing the PIN on page 2 because the PIN could be sent on a more secure line?

3) Password rules, while nice in principal, fail in practice for much the same reasons as seen in 1. Social Engineering, incrementation of passwords, and writing them down on a sticky note by your desk. There are plenty of other questions about best practices for password rules (I use 14 character passphrases generally), but all passwords are weak to social engineering and forgetful users.


Risk of self signed certificates with Android

It sounds like your use of a self-signed certificate is safe. But any variation in your usage pattern runs risks. For example, if you connect to your server via a web browser or other tool, you will not be able to automatically validate the certificate. You can still do that manually, but it won't be automatic and is somewhat error prone.

I suspect that the T10 was focused on the general case and didn't bother saying "Unless you pin the cert to your app and only access the server via the app or always manually validate the cert."

If you care, you can go get a free SSL cert from StartSSL.com and just bypass the problem altogether (though cert pinning will add security even with a signed cert).


I would look at Snort signatures, learn how they are written and use them as a template if you need to create your own.  For some examples, this page has collected several signatures it has found most effective against malware found by its Honeypot.

This is a good article about testing Snort with Metasploit.

Since you asked about a book, it has been almost 10 years since this book came out but that page has all the problems and answers from the signature section of the book.

Finally, the snort-sigs mailing list has in-depth discussion about exactly what you are looking for.  I would craft a much more specific question than "where do I look" if you approach that mailing list.

It is common to feed Wireshark captures into Snort manually and I think this is what you would do for this exercise


I don't recall hearing about a proposed authentication scheme where the user has to compute, essentially, a one-time password in their head.  I agree with you that most users would probably not be accepting of such a system, especially if it were designed with enough security to resist being easily reverse engineered by an attacker that can observe the challenge prompts and responses.  Here's one paper that proposes a slightly different system for entering PINs: How to Fend Off Shoulder Surfers.

You also mention graphical passwords, and I do know that there has been sustained work in this area to combat 'shoulder surfing'.  But I believe even they don't claim to be impervious to attackers who have prolonged observation capabilities, just more resistant than other authentication systems.  I can point you to a few related papers if you care to delve further into the subject:

You Only Live Twice or "The Years We Wasted Caring About Shoulder-Surfing"
Shoulder Surfing Defence for Recall-Based Graphical Passwords
Shoulder-Surfing Resistance with Eye-Gaze Entry in Cued-Recall Graphical Passwords
A Comparison of Perceived and Real Shoulder-Surfing Risks Between Alphanumeric and Graphical Passwords

For situations where all visual and audio data are susceptible to observation we typically rely on an authentication system where there is no observable data leaked.  This can be something like RFID cards, smart cards, certain types of biometrics, etc.  When these options aren't available, or are combined with knowledge like an ATM PIN, we typically try to implement the controls you mentioned to reduce the possibility of illicit observation.


45.79.198.112 seems to be used by some apps for checking connectivity.  I think your OS is doing the same.

Basically the underlying OS still need to know that it is connected to the Internet and able to route your VPN packets. in order to to do so it connects to certain servers and fetches a file. If successful then then you will see the network icon in the status bar showing "connected" .


Is it a good or bad practice to fake user agent?

For most cases, exploits won't try to determine if a browser is exploitable before trying to run, so the added security from spoofing it is negligible at best. As far as privacy goes, spoofing the user agent may actually be harmful since it would make you almost 100% unique if it was an impossible combination, like a desktop web browser at some odd phone resolution. If you have a common web browser resolution and disable other things that can cause combinations that are usually impossible (fonts, etc.), you may be able to reduce the chances of sites tracking you based on a fingerprint, but otherwise you'll be making it really easy.


What are the security risks to have admin rights for a user account on Windows 10?

Credential Guard does not protect against theft of domain cached credentials or the local SAM database containing password hashes of local users, because these things are stored on the hard drive. The latter is not a problem if you are using LAPS. The former is not a problem if all accounts are using secure passwords (or if you set the maximum number of cached credentials to zero, which may not be advisable depending on your requirements).
However, best practices are best practices for a reason. It's the principle of least of privileges and the concept of defense in depth that can prevent damage in case another vulnerability arises. New techniques could come to light, or a bypass against Credential Guard could be found in the future. After all, Mimikatz is just one exploit of the fundamental problem that whoever controls the computer also controls the users that are logged onto it. For example, I'm not sure if Credential Guard protects against token impersonation.


Is there any point in passphrase-protecting an SSH private key that is used by a service account?

In these sorts of scenarios, I leave the private key unencrypted (except maybe sitting on a disk that is encrypted), with read permissions restricted to root and the cronjob run as root, but do my best to restrict the usefulness of this key to the very specific task (versus allowing it to login to the remote machine with full access).

This can be done fairly straightforward by configuring ~/.ssh/authorized_keys to automatically run a specific command when logged in using the specific key.

command="/usr/bin/remote_commands_to_run.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-rsa AAAAB3Nz...DfE= root@some_client

See this answer for more.  You should be careful that the commands in /usr/bin/remote_commands_to_run.sh do not allow an attacker to escape to a shell.  It may also make sense to create a limited account on the remote machine with say a shell of /bin/false that runs the remote command (e.g., put the public key associated with the private key in that limited user's authorized_keys).

As always after setting it up, try and test to make sure the key doesn't have more privileges than you expect (e.g., that sftp doesn't work, that rsync doesn't work, etc).

On further notice, I see your particular task is to rsync data (presumably in specific directories).  This is probably doable with limited accounts (e.g., chroot'd to only be able to see those specific directories with no access to a shell).  I believe tools like rssh can be used to do this; consult superuser or serverfault for best advice.

Granted what I do in this scenario is mount the specific directories as a network drive (e.g., through NFS / sshfs) and then do the rsync to that mounted directory in a cron script.


They mean create a new passphrase with more words in it.

The main reason for this is that reuse, even if it is just to add something on the end, dramatically improves the chances an attacker will be able to find your passphrase, or in the situation that they may already have it, they could configure a brute force tool to start with your old passphrase and try combinations of that passphrase with a dictionary word added - which makes the attack simple and quick.

re-use is bad. Whether it is using the same passphrase across different sites or applications, or reusing a large portion of your passphrase and just changing the end (or start, etc.)


Configuration of Burpsuite (Forwarding request)

If you surf through pure http (without SSL) pages you should have no problem. But to surf through https (using SSL) websites, as Arminius said in a comment, you must to install Burp's certificate. Burp needs to perform a man in the middle to serve ssl pages to you using it's certificate.

Open your browser and open http://127.0.0.1:8080 to access to burp's page. Download Burp's certificate clicking on CA Certificate, is on the top right side of the screen. Once downloaded, install it on your browser. the installation steps may vary depending of your browser. Then you'll have no problems surfing ssl sites and you'll see https requests on your Burp's proxy HTTP history.


How less secure is an encryption if we know something about the original data?

If knowing part of the plaintext gives an advantage to the attacker in its efforts to guess or recompute other encrypted bytes, or the key itself, then this is considered a serious weakness of the encryption algorithm. No such weakness is known for AES.

The paragraph above needs some precisions. Indeed, if I, as an attacker, is given the knowledge that some plaintext bytes are "Pope Bened.ct XVI is resigning", with the "." being a byte unknown to the attacker, then I can guess with relatively high probability that the unknown byte actually encodes an "i". So the correct definition would be: if the attacker, given knowledge of some plaintext bytes and the whole encrypted file, can guess the missing bytes with higher probability of success than the same attacker who knows the same plaintext bytes but not the encrypted file, then the encryption algorithm can be considered as broken. AES is not considered as broken, so that's OK.

Another point is about active attacks. An attacker may want to modify the data so as to induce an honest system to work over fake data; and the behaviour of that system can give a lot of information about the unknown bytes (a variant of this attack is what is used in the BEAST attack on SSL/TLS). Knowledge of some plaintext bytes makes such attacks easier. AES-CBC, by itself, does not protect against active attackers. To defeat active attackers, you need to apply a MAC. Combining encryption and MAC is not easy; you'd better replace CBC with an encryption mode which includes a MAC and handles the hard work (e.g. GCM or EAX).

(The definition above is about "known plaintext attacks", where the attacker knows part of the plaintext. For active attacks, we would talk about "chosen plaintext attacks", where the attacker gets to choose part of the plaintext, and "chosen ciphertext attacks", where the attacker alters the ciphertext and observes more or less directly the result of decryption. Properly applied and verified MAC gives reliable protection against chosen ciphertext attacks.)


Is the SSH last login message reliable or rather something easy to get tampered with?

The last login information is stored in a log file. If the attacker has wiped or expurged other log files, it's likely that they've wiped this one as well.

Specifically the last login information comes from the wtmp file, typically located at /var/log/wtmp.

The crontab entry enumerates the available network interfaces and brings them up. It's a crude way of making it harder to disconnect the machine from the network.

The last two lines of the crontab script copy /lib/libudev.so to /lib/libudev.so.6
and then executes /lib/libudev.so.6. The current version of libudev is 1, so this file wouldn't interfere with the normal working of the system, but I guess it wouldn't immediately jump out as suspicious if you happened to notice it in a directory listing.

Understanding how the malware works is interesting, but it's unlikely to help you find how it got there.

What you've found is pretty crude and obvious, but there's probably other less obvious stuff as well. As usual, the only way to get a clean system is to nuke this one and start from scratch.


How to know the windows security dialog asking for username password is genuine?

What's going on?

Deviant software behavior. It may be a simple bug, or it could be the side effect of a malicious program. it's hard to tell without more information.

  Is Outlook launching some custom dialog for password?

It looks like Outlook ow whatever programs you are using are sending data to a standard authentication mechanism. My guess is that there may be some language translation occuring: i.e. from some language to English.

  How can user trust such dialog?

You would need some assurance mechanisms in place. An integrity checking mechanism is a good place to start. You will need a know good integrity value and a system capable of periodically checking your current software against the known good values.

  Is any app free to launch such dialog?

More or less yes. Windows provides a framework to programmers for presenting GUI components to users. Even if the authentication mechanism is protected the dialogue GUI can be faked and has been on many versions of Windows in the past.


No one can just "read" anything from your computer/smartphone via the internet. Your computer/smartphone has to actively send it to them.

This being said, there are many applications running on your computer/smartphone that are designed to send data to others through the internet, just like your browser, when it is sending your request to view a certain web page or your messaging client when you send a message or check the server if there are new messages.

For your convenience, many of these applications will not ask your permission everytime they send something to the internet, but they will permanently listen to the internet for legitimate requests and reply to them.

But how does an application distinguish between legitimate requests and malicious requests? This is the tricky part and if developers made a mistake here, attackers can find and exploit it.

So, what increases your risk of "getting hacked"?

having many applications running that communicate with the internet
using many "convenient" features like automatic installation, automatic loading of media contents, etc.
Using old versions of your applications (and your operation system). When software developers get word of security breaks in their software they usually try to fix them asap and release a new fixed version.

So, don't litter your devices with useless, outdated applications. Always update your operation system and the applications you need and remove those you don't need.


Why a physical signature is even listing any security at all?

I'm from germany where I have to "access" my money mostly by using a pin.

In germany both PIN and signature are heavily used if you use your card for paying. The reason is cost vs. risk: To get a signature is both faster and I think also cheaper for the vendor but the risk of cheating is higher. With PIN the risk is reduced but the costs are higher. Thus PIN is commonly required in high risk or high price environments where cheating causes more harm (like buying a computer or TV) while in lower risk or lower value environments (food store) a signature is often enough.


RSA 4096 with AES 256 Encryption Process Using PyCrypto

My main feedback: You don't provide enough technical detail to provide a complete critique of your proposal, but you have provided enough information that I can see that you are making several common mistakes.  Here are the main mistakes I can see so far:

Mistake #1: inventing your own encryption format.  Usually, designing your own format for storing encrypted data is not a good idea; you are likely to get something wrong.  It is better to use a standard format, like GPG or the OpenPGP Message Format.
Mistake #2: failure to include message integrity protection.  Encrypting data without also authenticating opens you up to subtle but serious attacks.  This is highly counter-intuitive, and a very common mistake.  It is tempting to think, gee, I want to keep this secret, so if I encrypt it with a good encryption algorithm, I'll be fine.  But nope, you won't be fine.  You also need message authentication, to defend against chosen-ciphertext attacks.  And you need to apply with a proper mode (e.g., authenticated encryption, or Encrypt-then-MAC) and with proper key management (independent keys for authentication and encryption, or appropriate use of key separation).

To avoid these problems, follow the advice at the links I gave above.

Other miscellaneous feedback:

There may well be other problems; you haven't provided us enough information to identify them all.  Here are some examples of potential problems:

For instance, you don't describe how the IV is generated.  In past systems, poor IV generation has occasionally led to security problems.  (The IV needs to be generated using a crypto-strength pseudorandom number generator.)
You don't describe how the AES key is encrypted.  (You need to use a proper padding scheme, e.g., OAEP or PKCS#2.)

The key lengths you have selected are overkill.
Keep in mind that, when modern cryptography is properly implemented and used, it is almost never the weakest link in the system.

Instead, attackers usually defeat crypto not by breaking the crypto algorithms, but by bypassing the crypto and attacking some other aspect of the system -- maybe applying social engineering to the humans, maybe finding a security hole in the code and compromising an endpoint, maybe exploiting errors in the key management, or any of a number of other ways of attacking a system.


Which things are the most important?

Really you don't know very much from an IP address. First thing to note is that an ip address is not the same thing as a user - particularly (and increasingly) with ipv4 addresses. If you've got a significant amount of traffic and identifiable patterns of fraud then you can start building your own reputation database.

Some key points are:

don't use IP addresses - use netblocks from the whois lookup
it may be advantageous to differentiate by geography - at least at the country level - there are free lists of net blocks by country
beware of small networks (up to /10) they are usually servers not end users
if you've got an authentication mechansim, then track what netblocks individual customers use - apply additional authentication when accessed from a network not seen in the N interactions / the last M weeks for this custmoer
using reputation services may not have huge benefit - apart from spammer listings, these are usually populated by organisations running services which might be subject to big losses - if you're not running an online banking / payment system then you'll be targeted in a very different way
use the time (at the client) to determine risk (does customer A usually access the system between, say 11pm and 6am?)
if possible check the local time on the client matches the expected timezone for the IP address
watch out for multiple users from the same IP address - once a user has authenticated at an IP address, apply additional checks for the next X units of time for different users from the same IP address

I've not specified exact values for M, N and X - ideally these should be adjustable by network - differentiating between home ADSL/Cable providers, mobile network providers, overseas locations and others.

Track authentication failures - these are your first level of abuse detection.


There are any of a number of different ways to do this.  Many options, both open-source and proprietary will handle it.  I know DD-WRT is one example of an open source router firmware which provides this kind of functionality directly.  Behind the scenes, what is basically happening is that any connection that is made to the device gets routed to a special network where any request will resolve to an HTTP redirect to the login page.  Once login is done, the router tracks the MAC address of the device that is allowed access and redirects it to the network that is actually connected to the network or Internet.

A similar type of goal can be accomplished for private networks using WPA-Enterprise which would require an actual username and password to be configured in the wifi connection itself, though WPA Enterprise is not what you are directly talking about since it doesn't use an open wifi connection.  It is, however, more secure since it gives each user their own user specific encryption and thus multiple users can not eavesdrop on each other.


As the IP address being visible on the LAN is how your VPN packets get back to you hiding it from other people on the same LAN is a tad hard.  Also normally the point of a VPN for privacy isn't to conceal your IP address from everyone but to make sure that the people who can see your IP address can't see what data you are sending and receiving and people who can see the data can't see your IP address.

Whatever you do the people who administer the LAN will probably be able to tell you are the person using a VPN if they can be bothered to look.  Most techniques that would hide your IP address on the LAN will make you even
more obvious in some other way.

If you want to hide the fact that you are using a VPN from the LAN admins your best bet is to try and make sure that your VPN looks like normal (eg https or ssh) traffic.  While this isn't too hard to do at a superficial level traffic analysis would probably reveal you.


Having multiple JREs on a system isn't in and of itself a risk, but the risk that they might be invoked by untrusted code is present.

So the key to this setup is likely to be ensuring that the outdated JREs can only be invoked by the application that you need it to and not by any untrusted code.

Exactly how you achieve this depends on the application that you need to allow the use of.  If it's a thick client app then installing the outdated JRE in the applications home directory and ensuring that any environment variables (like JAVA_HOME) that direct programs to specific JREs are not pointing at it would help.

The most critical element in terms of likely risk is ensuring that the Java browser plugin for the vulnerable version is not exposed to the Internet.  There are a large number of malicious sites/exploits which can attack that weakness, so it's one to avoid.

If your business app. needs the Java browser plugin then things get harder to do with less risk.  Here I'd say your choices are either to ensure that the browser with the outdated Java plugin is only usable for access to the legacy application (e.g. force a proxy and set it to one that can't get to Internet based sites), or to provide a Virtual environment with the browser/Java plugin made available and again make sure that environment can't access the Internet.

With any of these solutions there is still a risk that an attacker will find a way to invoke the vulnerable JRE but by restricting the use of it, you can reduce the level of risk.


Have you tried Fail2Ban? One of it's preconfigured filters for Apache is designed to "match web requests for selected URLs that don't exist", and will let you ban offending addresses accordingly.

If memory serves you can customize the bans to expire after a specific amount of time, and kick in after a specific number of violations, so you could set it to block any ip that tries to access /admin.php for 3 days, drastically reducing the viability of random scans while not permanently blocking an IP that might soon belong to a legitimate visitor.

How-to's here or here to help you get started.

The filter I believe you're looking for is called apache-botsearch.conf on my system.


Are there enforcements on host configurations to protect other computers?

No, there are is no technical enforcement for such attacks (I take you mention the Smurf attack as an example).

TCP/IP comes from a place where the reliability of the network was key, not its security. This is why there are no basic security elements built into the protocol and, historically, we relied on "best practices" (like the one to change the default for routers in the case of the Smurf attack) to protect ourselves and others. Some protocols were also changed to disable malicious behavior which was not thought of initially.

There are however organisational  ways to address such issues, a typical one being blacklists of various sorts. This does not work too well, is hardly scaleable but this is the best we have today.


In this case you have to wait until the time period you set in max-age is passed.

In this situation it's better to roll back to the old certificate, add a new pin to Public-Key-Pins header and wait for some time until the vast majority of clients receive the updated header.

In future, just don't rely on only one pin - always have a reserved certificate.


I wrote some code in order to get an answer to my question. The general logic of the TPM is as as simple as follows:

The parent key always has to be loaded in the TPM in order to load a child key.

That means that Idea 1 is completely valid (including the optional steps) and Idea 2 is not. BK with parent SK2 cannot be loaded as SK2 hasnt been loaded previously.

So basically the TPM needs only 3 slots in order to build endless key hierarchies. Generally a TPM still owns more than 3 slots (e.g. my TPM has 32 slots).


Secure Web Password Fields + http to https redirect

Yes, this is a security issue because an attacker may be able to change the HTML code. He can change the action attribute of the form to point to his own server. Or less obvious and better: Add some javascript code that mirrors the password to his own server without breaking the login to the real site.

Unfortunately both Facebook and Twitter set a bad example here. Google Plus, however, redirects to https immediately, so there is some hope.

What should you do? Educate users that they need to check the address bar for https and the correct domain before they enter any private information into web forms.


All user-supplied input should be validated on entry (use Hibernate Validator with its @SafeHtml annotation), so you don't fill your database with potential XSS that could wreck another application, or later versions of the same application

You could use my crude tool to validate all GET & POST parameters and header names and values:

http://blog.databasepatterns.com/2015/08/simple-inbound-xss-filter-for-spring.html

Heads up: it doesn't validate request bodies

User-supplied data should be escaped on output as well

You can use this Expression Language resolver to "auto" escape all JSP pages https://pukkaone.github.io/2011/01/03/jsp-cross-site-scripting-elresolver.html


I think your safest bet is to provision a TS Gateway server and stand it up in front of your Windows 7 box.

TS Gateway allows for the connection to remote desktop devices over a TCP 443 port connection as opposed to an RDP port directly connected to the internet. I have implemented several of these with my clients and have noticed dramatic decreases in brute force attempts (even on boxes with RDP listening on a non-standard port).

The second option I would recommend would be to put the RDP server behind a VPN connection. Get your employees to VPN into your network, then have them log in to the RDP box.


How do I forensically determine whether a mobile phone has been infected with a spy suite?

If I were in your position, I would grab complete image(s) of the individual mobile device(s) to forensically analyze the images using another, independent system because…

You do not have to install anything on the related mobile devices as you can analyze the device image(s) on your other system with any tool you like/want/need.
You can modify (in the sense of “cleaning up suspicious and/or malicious data”) the image as needed and push the checked and cleaned image(s) back to the individual mobile device(s).
You have image(s) of the mobile device(s) which can act — if needed — as forensic proof and legal evidence.

If you do not know how to create and analyze such device images but are almost sure that the devices are indeed compromised, it's time to get professional help from an information security specialist… your best choice will be an forensic analyst in this case.

Additionally, since you are describing a situation that could involve a commercial environment (work/company), you should also reach out for legal advise in case you actually manage to identify the person(s) who have compromised your devices.

As you might know, governmental institutions and agencies (including “ye regular police”) have access to specialists like forensic analysts. Most probably, they are your best choice when it comes to "securing proof" and "defending your rights" (in a legal sense).

The above approach has a high potential to close the loop of your security problem without too much impact, while providing you with a good stand when legal consequences start gaining importance to you.

EDIT

The following information will be of use to you:

SANS: An Incident Handling Process for Small and Medium
Businesses (PDF)
SANS: FORENSICS PLAN GUIDE (PDF)

Whatever you do, do not destroy or modify digital evidence. That's why I am advising a forensic analyst instead of doing research and analysis yourself. And let's be honest — if you were trained in digital forensics, you wouldn't have asked the question in the first place. Instead, you would have applied the 6 Phases of Incident Management…

Preparation
Identification
Containment
Eradication
Recovery
Training

… using the appropriate proceedings and tools.

EDIT

Due to the comment(s) talking about iPhone and iPad imaging, I would like to note that when I talk about imaging for forensics purposes, I am talking about "professional digital forensics software" that fits the individual needs and purposes of the analyst.

This is a list of currently available tools which I would use (depending on the situation and needs) for iPhone/iPad:

Black Bag Technology Mobilyze
Cellebrite UFED
EnCase Neutrino
FTS iXAM
iPhone Analyzer
iphone-dataprotection
~ A set of tools that can image and decrypt an iPhone. The tools can even brute-force the iPhone's 4-digit numerical password.
iOS Forensic Research (Available to law enforcement only!)
~ Among many things, Jonathan Zdziarski has released tools that will image iPhones, iPads and iPod Touch.
Katana Forensics Lantern
libimobiledevice
~ A library with utilities for backing up iPhones. The output format is an iTunes-style backup that can be examined with traditional tools. They are available in the Debian-testing packages libimobiledevice and libimobiledevice-utils.
Logicube CellDEK
MacLock Pick
Micro Systemation .XRY
Mobile Sync Browser
Nuix Desktop and Proof Finder
~  Tools that can detect and analyse many databases from iOS and iPhones and can directly ingest HFSX dd images.
Oxygen Forensic Suite 2010
Paraben Device Seizure
SpyPhone

I'll spare you listing the appropriate tools for Android, Blackberry and other mobile devices, which each have their own set of forensics tools. I'm convinced you don't really need a list of tools, since any forensics specialist knows them. If you don't, you're not a digital forensics professional… yet.

Now, if you want to dive in a bit deeper into digital forensics, you should take a look at

http://www.forensicswiki.org/wiki/Main_Page

which provides some pretty good heads-up information for people who aren't educated in the field.

Also, you should read some books on the subject like "iPhone and iOS Forensics".

If you're still interested in digital forensics after reading a dozen of books and getting your hands dirty by trying it on your own devices, I would like to advise you to reach out for an according digital forensics education. It's an interesting field and you can trust me when I say: "it never gets boring."


In BeEF, a ping is not an ICMP ping request, and a port scan does not mean a SYN scan (or any of the other common port scanning methods you'd find in nmap for instance). Instead BeEF uses standard web APIs that make layer 7 network requests (HTTP/FTP/WS) and measures the timing of these API calls to determine whether a host was up or a port open.

There are three different techniques BeEF uses for this purpose:

Cross-Origin XMLHttpRequests
HTML Image elements with onerror/onload event listeners
WebSockets

The ping module uses Cross-Origin XMLHttpRequests only, while the port scan module uses all three. BeEF never accesses OS-level networking functionality and cannot send ICMP ping requests or do a TCP SYN scan.


Google thinks I am a robot when using proxy, but only in Safari

Google's new reCAPTCHA uses cookies:

  To put it simply: user’s past behavior and previous CAPTCHA solves are recorded in their cookies, which are then detected by future reCAPTCHA challenges.

So seeing different behavior in different browsers isn't surprising. You may find that using an incognito/private browser window changes the behavior.


Why does Safari seem to be accepting an HTTPS connection every other browser rejects?

With Safari, if it cannot validate the certificate, for example because it is self-signed or is signed by an untrusted CA or, quite often, because the server is not sending the intermediate certificate, you can click the "Continue" button on the error dialog and it will automatically store an exception to trust this certificate for this site for the rest of the session (until you quit the browser).  You also have the option of showing the certificate and explicitly saving it as trusted so it will always be trusted in the future.

There is also a preference option to some kinds of certificate errors in general.  In the Security pane of the Preferences window, you can uncheck "Warn when visiting a fraudulent website."  I believe that just fixes host-certificate name mismatches, not invalid certificates in general, but I'm not sure.


Python - ctypes.cast function call outputs Segmentation Fault error message

The VM machine was x64 architecture, and I fed it 32 bit shellcode, terrible mistake on my part, but finally mystery solved.


Why does cellular communication protocols use A5 or KASUMI and not AES or 3DES or RSA

It seems to me this is for historical and technical reasons. A5/1 and A5/2 seem to be rather old designs from late 1980s. They do not appear to be in use any more. There was no AES at that time and 3DES is block cipher and GSM networks vendors apparently wanted stream ciphers back then. KASUMI seems to have been accepted also around the the time or before AES was announced, so they couldn't have made AES the standard cipher either. Also, AES is USA standard while these GSM network standards are international, and politics is a thing.


Is a password easier to brute force if it contains a repeating pattern?

There are three scenarios here:

Attacker has no knowledge of the pattern scheme:
When the attacker has no knowledge of the patterns, the brute-force attempt will have to be exhaustive. The attacker gains no practical efficiency improvement, because there is no way of him knowing the construction of the password.

Attacker has some or full knowledge of the pattern scheme:
If the attacker has knowledge of the patterns, they may improve the efficiency of their bruteforce attack by not attempting passwords that do not match the pattern scheme.

Attacker has no initial knowledge of the pattern scheme, and multiple hashes are available:
If the attacker has no initial knowledge of the pattern, but has a number of different password hashes to crack (all of which use the same scheme for the password) he may crack a small number of them via exhaustive bruteforce, then deduce the pattern. From there, the attack becomes much more efficient.


Can I be tracked down using Tor after not using it again?

Tor is probably one of your best options at being anonymous on the internet.  That being said there are always a possibility of being tracked.  For instance if you had your internet connection tapped before you started using tor and your exit node was one controlled by the same people (big if), they could potentially find out who you were by a throttling your connection in some sort of regular pattern and comparing it with the exit node you used.  In addition there is a small possibility of someone holding a zero day that would allow you to be deanonymized.  Or the version of Tor you downloaded could have been modified by a third party (assuming you didn't check the hash).  You would probably have to be a pretty wanted man for anyone to use any of these techniques though.

Again, Tor is one of your best bets, maybe in the future if you are more worried about it you could also use a anonymizing vpn (who have a canary that is not triggered) and a couple of other proxies.

Edit: not using it again is not really gonna help you.


Can I bypass basic auth to fingerprint a web server with Httprint or netcat?

It fails because of Basic Auth (ie "Connection Refused") ...

I think you are missing concepts: "Connection refused" means that establishing a TCP connection to the server has failed. This has nothing to do with Basic Authentication which happens only after a successful TCP connection could be established. With Basic Authentication required the server actually provides a HTTP response suitable for fingerprinting.

In your case it might be more a problem of the source IP address blocked or no server at the location you try in the first place. What exactly of these is the problem is not clear from your question and thus it is unclear if and how it can be bypassed. But giving that the site is not responding on port 80 it might actually be the same for port 443. And if there is no server at this location in the first place then there is nothing to bypass.

EDIT after the OP provided screenshots:

The OP first tries to use netcat against port 443 and gets Connection Reset: This is because the OP tries to send a plain HTTP request to a HTTPS port and the server is closing the connection since plain HTTP is obviously not a valid start of a TLS handshake.
The OP then tries to use netcat against port 80. The OP actually gets a valid HTTP response which also clearly states Server: nginx - i.e. fingerprinting is actually successful. The status code of the response is 404, i.e. file not found. If basic auth would be involved the status code instead would be 401.


Signature hash algorithm SHA256 (Certificate) vs Peer signing digest: SHA1

What is the relation of Peer signing digest with Signature hash
  algorithm (Certificate)?

Peer signing digest is the algorithm used by the peer when signing things during the TLS handshake - see What is the Peer Signing digest on an OpenSSL s_client connection?. This is independent of the certificate.  Signature hash
algorithm (Certificate) is instead the digest algorithm used by the issuer of the certificate to sign the certificate.

  Why it is connected with SHA1 when in https://www.ssllabs.com/ssltest/ gets A.

The security requirements for both cases differ. The Peer signing digest must be strong enough to not be breakable during the TLS handshake which takes at most a few seconds. The Signature hash algorithm (Certificate) should not be breakable as long as the key of the issuer certificate is valid, which is usually several years. This means for now SHA-1 is probably sufficient for protecting the TLS handshake but not for a certificate signature.

  Can I do something as client?

In TLS 1.2 the client can send which digest algorithms are supported for the handshake. If the client does not offer SHA-1 the server should not use SHA-1, which means that it might use other algorithms offered by the client or that the connection fails. See the -sigalgs option for openssl s_client. Note that the server might simply ignore the information from the client about the supported algorithms - which seems to be the case in your setup. In this case there is nothing you can do as a client.

  If no what should they change in their servers?

Nothing is known about the server so no recommendations can be done here. Depending on the server there might be an option to setup the signature algorithms for the TLS handshake or there might be no such option.


Filtering of port 3306 and opening only in times of need - The ultimate defence from DB hacking? (question had major update)

tl;dr: Absolutely not.

It takes less than 3 hours for someone to completely destroy your Database. I'll say that again - your idea in its current form is a terrible practice, and is NOT a substitute for input sanitization

~~Even if you'd said "We'll put the DB behind a firewall and whitelist IPs, it might have been a better idea.~~ - I see you updated your post, and can't do this.

Here are a couple of reasons why I feel this is not viable:

Scenario: I'm a nasty person watching your network for any sort of weakness. I'm very, very patient.

What happens: You mention that you are unable to use an IP whitelist. This means that I can now attack your server in a multitude of ways and not worry about having to spoof my location. How would I do it?

Set up a script to scan your site every, say hour - just try to resolve /phpmyadmin and watch if it resolves. If it does, I begin my intelligent bruteforce. Not very clean and very noisy, but hey - it almost always works.
None of your current solutions will prevent me from actually breaking your site in daily operations - SQL injection isn't only performed on one page - it'll work anywhere in your site where you haven't bothered to sanitize your inputs and are calling or pushing data to your DB. I'll start methodically attacking each of these areas throughout the year.

This should give you a pretty good idea why this isn't viable.

2nd tl;dr: Don't do it.


In Windows How to determine encryption algorithm used in certificate

we run a vulnerability scan against our servers. It flagged a few
  certs we use are using 3DES symmetric encryption method, which is a
  weak encryption algorithm. It is unclear how this was determined, so I
  am hoping to be able to see if there is a way to determine this my own
  without having to run a scan every time to find out

Is TLS, the server has a list of cipher suites that it is willing to use when speaking to the client.  This is completely independent of the Certificate.  The vulnerability scanner connects multiple times, each time asking to use a single cipher, and determines which ciphers are or are not in the allowed cipher suite.

You will want to alter your server configuration so that it removes weak ciphers from its cipher suite.  Windows offers a number of ways to manipulate its cipher suites.

The best way to test is to repeat what the vulnerability scanner did.  You can do this for a single cipher using OpenSSL.  You can test the full suite with a single command using the sslscan tool.  And if your server is on the Internet, SSL Labs will test your cipher suite and other aspects of your server configuration as well.


Is JWT secure to use as session identifier?

A JWT consists of three parts. The header, the payload and the signature. The header specifies which signature method is used, so it the signature can not be verified before reading the header. Note that this is an implementation error; the header should not be able to change the signature algorithm.

  Send a header that specifies the "none" algorithm be used

In this case there is no signature, so the attacker can modify the message at will.

  Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key.

In this case the attacker needs to know the secret. However, RS256 uses asymetric cryptography, in which the public key is often published. If the attacker succeeds in changing this to HS256, the public key is used as symmetric key instead. So the attacker knows the secret because it is the public key.


You have not understood FTP Bounce attacks.

FTP Bounce attacks does not let a FTP connect to another one, but to request access to ports by using the command PORT.
It's mostly used to make a port-scan without being detected (as you are not the one doing it, but the FTP server for you), or even for D.o.S. attacks.

Turning this FTP-bounce to upload a file from a FTP server to another (as it seems you want to do, sorry if i misunderstood you) requires much more than this.

So PORT command may work, but not RETR


Can a hacker pretend his IP as my IP in order to send requests to my server?

Spoofing IPs is one thing, getting the replies back is quite another. To spoof a packet the attacker just needs to find an ISP that is sloppy about ingress filtering. To get a reply back the attacker needs to inject routes into the network which is hard to do and especially hard to do without getting noticed. It does happen from time to time though, search for BGP hijacking to find examples.

So the first thing you need to do is make sure that your server requires some kind of session establishment (for example TCP) before acting on a request.

Beyond that you should not be using IP filtering as your sole defense mechanism but as only one part in a stack of security measures, so in the event that the attacker does manage to perform a BGP hijack they still face other security measures.


Open ID, Storing card details, and PCI compliance

For use by consumers, I believe you should be ok, but for use by employee's you'd potentially run afoul of PCI-DSS requirement 8.5.  OpenID provides an authentication mechanism independent of data and validates a user matches with the unique ID assigned to the user within your system.  For non-consumer users there are additional requirements for password complexity and changes that might not be enforced by a third party OpenID system, however for the consumer users (whose information is being protected), it seems to be allowable to let them use an OpenID to authenticate.


Implications of the security model of HTTP cookies on HTTPS connections

Generally speaking, a server shall consider every incoming data element as being potentially hostile. There is, here, a definition issue when you talk about "site integrity": this can be about integrity of the site as the user sees it, or the integrity of the site as other users see it. If all the server does is to send back the cookie back to the client who said it, as a script to execute, then the problem is simpler.

As I understand it, you fear the following scenario:

The site allows a user U to upload some Javascript, that your server will "store" and serve back to the same user U. This uploading goes through a properly secured process (HTTPS, user authentication...). The storage is not actually done in the server, but as a cookie value in the user's own browser.
By exploiting the user's gullibility, or hijacking the user's network access, the attacker succeeds in pushing some hostile Javascript H into the user's browser, attached (as a cookie value) to your server name.
When the user U next connects to your server, the hostile Javascript H is sent to your server (as a coookie) and the server sends it back to the client, to be executed.

Described that way, then your problem really is one of recognizing "official" cookies that have been pushed to your server through the normal process (with HTTPS and user authentication). Cryptography can help, with a MAC: you want to tag a cookie value, such that only your server can compute a proper tag, and can verify it. That way, your server would reject cookie values that have not been previously recorded through the secured registration process. In the scenario above, the hostile Javascript H value would lack a proper MAC value (because the attacker does not know the MAC key used by the server), so the server would refuse to send back the cookie contents as a script to execute.

In all generality, what you are trying to do is to offload server state onto clients. This can be done with:

a MAC to preserve integrity (against clients who modify their cookies, willingly or not);
encryption, if the state contents must not be shown to the user (this does not apply to your specific case, as you describe it).

See this question for some details.

Take care that the size of an individual cookie, and the number of cookies recorded by a browser for a given site, are both subject to browser-specific limitations.


Can exploit vulnerability if program started with gdb, but segfaults if started without gdb

This will almost always happen. When you load a program into gdb, things get shifted around a bit - not much, but enough to make an address overwrite wrong.

You have a couple of options, you can use tools (such as metasploit's pattern_create.rb) to determine the actual address of your buffer in memory when the program is run outside the debugger. This is achieved simply by passing a non-repeating pattern to your program, and seeing at which address the segfault occurs (core dump), that way you can determine how far into your buffer lies the section that is written into the return address. ignore my rambling, this is completely unrelated, go with the nop sled

Or you can just extend your NOP sled a little and start guessing addresses. It usually doesn't take more than a dozen or so attempts on a small program.


I think the OP is after the DRM protection built into SD cards:
http://en.wikipedia.org/wiki/Secure_Digital

Thats why they're called "SD" as in "Secure Digital".

The access to the DRM encoding Equipment for SD cards is limited to those buying a license, so I would suggest you Contact the SD Association for purchasing a license:
http://www.sdcard.org/

This DRM protection can perform a challenge-response type of authentication before allowing access to the content on SD-card, which will be encrypted during transmission. Preferably, your GPS device will contain a "smart card chip" containing keys, and your map SD card will communicate with this chip to create a encrypted channel. Then you could generate symmetric keys using a secret algorithm based on the GPS device's serial number + a secret master key as input. The master key is only stored in your production equipment.

When a customer wants to purchase a map, they will have to specify the GPS device serial number, they will then be sent a SD card tailored for that GPS device.


Is my BCrypt variant ($2a$) fine, up to date and secure?

This is from the wiki page:

  $2a$ – The current key used to identify this scheme. Since a major security flaw was discovered in 2011 in a third-party implementation of the algorithm,[15] hashes indicated by this string are now ambiguous and might have been generated by the flawed implementation, or a subsequent fixed, implementation. The flaw may be triggered by some password strings containing non-ASCII characters, such as specially crafted password strings.

In case you'll be looking for alternatives, I'd recommend PBKDF2 with SHA512 and 5k - 10k iteration rounds. Should be enough to make brute-forcing too costly and still run your apps without notable delay. Here is an off-the-shelf c# implementation.


Which WYSIWYG editor has the best security reputation?

The problem isn't the WYSIWYG editor. They are clientside code. The problem with such editors is when they are integrated with the serverside to post content or perform an image upload.

Much of the bad reputation comes from when they are included in a CMS plugin. Those integrate with the serverside code base and either aren't always coded securely or the exploit is found in code unrelated to the WYSIWYG editor. Since the attack to the serverside originates from the WYSIWYG editor it gets the blame even though the same attack could of been done from a text area or a POST request to the vulnerable script.

Keep in mind they might provide tutorials for integrating with a serverside language. But these are just examples and shouldn't be used as production ready scripts. Unfortunately people take these scripts and run with them. So again, the blame gets put on the WYSIWYG editor despite the fault needing to be placed on a lazy developer.

Both of the editors you mentioned are pretty well maintained and you can't go wrong with either. However if you aren't using a CMS plugin the secure coding is up to you.

Edit: With the mention of XSS attacks on the clientside the same applies. Your serverside is pushing that data to the WYSIWYG editor. It expects whatever you send it is what you wish for it to display. Sanitation of malicious code needs to be done on your side before it is fed clientside.