Cracking a truncated hash of type sha256(salt+pw+salt)

The way I solved this is by editing an already present dynamic config in john the ripper jumbo. I opened dynamic.conf and edited dynamic_1029 to look like this:
[List.Generic:dynamic_1029]
Expression=sha256($p.$s) (hash truncated to length 32)
Flag=MGF_FLAT_BUFFERS
Flag=MGF_SALTED
SaltLen=16
MaxInputLen=110
MaxInputLenX86=110
Func=DynamicFunc__clean_input
Func=DynamicFunc__append_keys
Func=DynamicFunc__append_salt
Func=DynamicFunc__SHA256_crypt_input1_to_output1_FINAL
Test=$dynamic_1029$698e7b93568798660235091abcb7883e$8ec3937e0c5068eb:Salver

So now it includes a salt and truncates the hash. Then the constant salt was achieved using the --mask command line parameter as well as the new format as such:
john --mask='[constant salt]?w' --format=dynamic_1029 hashlist.txt

The hash files must now be formatted like this:
username:hash$salt


What do I need to do to secure log-in and registration for my website?

CSRF - You need to have protection in place to prevent cross site request forgery - or requests to login, signup, or other actions from other sites. This can be used to trick users into performing actions they didn't intend to.

CAPTCHA on signup - It's often recommended to use a CAPTCHA on your sigh-up form to reduce automated signups. How important this is depends on your threat model.

Secure login - The login needs to happen over HTTPS to reduce the risk of the user's credentials being captured via a MiTM attack.

Cookies - While login over HTTPS should be seen as a minimum, everything else really should be over SSL as well to protect the cookies (remember Firesheep?). Though just using SSL isn't enough, you need to set the Secure flag and HttpOnly flag whenever possible.

Email Confirmation - You need to make sure that you verify a user's email address as part of the sign-up process (I'd suggest not letting them login until it's confirmed). You'll need to have this for use in password resets.

Bruteforce protection - You need to protect against an attacker bruteforcing user accounts. There are various ways to do this, locking accounts (which can be used as a DoS attack by locking out large number of users), limiting failed attempts from a given IP (either via ban, or additional CAPTCHA). There are pros and cons to each method, but it's important that you have some form of protection in place.

Secure password reset - You need to make sure that you have a secure method for resetting passwords. This one is more complicated than most people think, and is easy to get wrong (as Apple recently found). The biggest risk is that an attacker finds a way to abuse the feature to reset accounts that they don't own.

I'd strongly suggest that you read the OWSAP Authentication Cheat Sheet, it goes into detail on these and many other potential issues; and as always, when building new systems, it's a good time to take another look at the OWASP Top 10 and make sure you have taken the proper precautions.


How does a security countermeasure failure impact a system?

You are asking a quite open question, and I think you are in a too-theoretical situation, whereas in the outside world you would probably find that the critical system is using a Windows XP that hasn't been patched in the last 15 years.

Obviously more security checks will lead to “more complexity” in the code/design, which means a larger surface where things could go wrong. But actually, the extra checks should benefit the whole system.

If the countermeasure is properly designed, it should be clear what the status would be on failure. For instance, a system that was available through plain HTTP may have been updated (the security countermeasures) to use HTTPS. Then there was a failure on this countermeasure (the certificate expired). The result is that the system is no longer available (it fails-closed).
It could instead have been designed to fail deadly. Different systems may have different goals. The important thing is that such goal is documented and a conscious decision. Not just that, "nobody thought that if the countermeasure we added failed, everyone would die".¹

Note that I don't think the case "if an encryption mechanism fails, it flips a bit in a message" is a suitable scenario. There may be bits that get erroneously flipped, and an encryption layer could amplify it (rather than getting one bit wrong, you get a whole block of garbage). However, if the security countermeasure only added encryption (confidentiality), I would consider it as being badly implemented, since you also need to authenticate that what you received is the right message (integrity), which is what you should be detecting in such failure and whose output situation should be defined in some way (stop the car, drop the internet connection...).

As a non-IT security countermeasure "failing", see the following real-life scenario:

Initial state: Terrorists can enter into the plane cockpit and hijack planes
Security countermeasure: a security door is added that can only be opened from the cockpit, in order to protect the pilots.
Final state: One of the pilots can hijack the plane with the "good" crew members not being able to stop him due to the security door.

Here it is not really a "failure" of the security countermeasure, as it is working as intended (not allowing external access to the cabin). Actually the issue is that it is working so well that it then creates a different problem in the system as a whole.

The problematic part would be to detect that in the design phase of the countermeasure. (And then figure out how to mitigate it)

¹ Even if it is done on purpose, the people that would be killed may still object to that design, though.


As you're using Splunk, check out FSChange. It's been deprecated in Splunk 5 (though it's still there), but it might do what you want.

An alternative to FSChange might be something like Samhain's file integrity monitoring, coupled with Splunk.


The problem here is not so much with CBC, but with alternatives that are easier to implement safely, without losing mathematical security.In fact, AES-CBC turned out to be notoriously difficult to implement correctly. I recall that older implementations of transport layer security don't have cryptographically secure initialization vectors, which are a must-have for CBC mode

A lot of recent attacks are padding oracle attacks, like the Bleichenbacher attack. These especially depend on old modes kept for support. POODLE is a downgrade vulnerability. LOGJAM is downgrading TLS to old, export-grade (read NSA-sabotaged) crypto suites.

For CBC mode, there is the Vaudenay attack.
These attacks depend on the server explicitly saying "invalid padding", thereby leaking 1 bit of information on each transaction. Error messages were removed, but the problem of timing remained. The server still used more time before responding if the padding was valid.

In response they were forced to come up with the peculiar workaround of generating a dummy key, and using that for decryption so it would fail in another part of the implementation. In every implementation. So they decided to no longer force that on developers by supporting it in the specs.

Cryptography is a very broad field, and a specialty on its own. History had learned through uncomfortable experience, that doing it perfectly is almost never guaranteed, even for the best in the field. For example MD5, created by Ron Rivest, co-inventor (and part-namesake) of RSA was widely used, then broken in 2013 . Its collision resistance was circumvented in 2^18 time, less than a second on a desktop computer for 128 bit hashes.


Executing arbitrary commands through iptables-restore input

The --modprobe option is part of the command line syntax of the iptables-restore command. It isn't something that iptables-restore parses as input.

So if there's a sudo rule that allows you to run iptables-restore with arbitrary arguments, you can pass --modprobe=/bin/sh or variants thereof. But if all you can do is pass input to iptables-restore, then this particular method doesn't allow arbitrary code execution.

Note that I do not assert that iptables-restore doesn't allow arbitrary code execution in some other way. In particular, if you can control the environment but not the command line options, export MODPROBE_OPTIONS='-d ~/malicious_modules' (in combination with a rule that triggers the loading of a module) looks promising, but I haven't tried it. And of course modifying firewall rules can cause all kinds of havoc (starting from trivial DoSes and building on from there — often services restricted to localhost would be dangerous if exposed to the whole Internet).


Making an API repository private vs public

I think you are okay making this a public repo as long as the following conditions are met:

No application secrets such as keys or certificates are maintained in the repo.
No sensitive or personal identifying information, such as user names, email addresses, passwords, etc. are maintained in the repo.
No algorithms that if reverse engineered could lead to the exposure or exfiltration of any of the above in the runtime system. For example, reverse engineering an encryption routine or a protocol that could expose a user name and password.

Assuming these are met one important factor that shouldn't be overlooked is ensuring that your app is architected to protect itself from intrusion. This would include user authentication, ensuring that the front-end only communicates to the backend through the API (i.e. no direct use of backend services like making a db call from the frontend), using secure protocols (like HTTPS) to protect the communications channel, and ensuring that the OS and any other services you are using are regularly up-to-date on security patches.


Most of the time these events are noisy in a large user environment with a password change policy. Most of the time this happens when an account's password is expired and it is tied with some application/service/task which keeps trying login again and again.

If you have SIEM or log management solution, you can create a rule to ignore 4771 events for account's password was recently reset 4723/4724 (say in the last 24hrs).


Online shops SSL certificates and VISA/MasterCard

No, it is not (and hasn't been for years).  Use of a SHA-1 certificate will trigger a failure in any current compliance audit.

U.S. NIST and PCI regulations currently require the use SHA-2.

Or for more detail:

  PCI compliance scanners currently require their clients to use SHA-2-compatible SSL certificates. In order to validate PCI DSS compliance, you must ensure that Web server(s) in the PCI environment are configured to disallow SSL (Secure Sockets Layer) Version 2, as well as weak ciphers and hashes. PCI network scanners finding SHA-1 certificates will fail a compliance audit.


Executing perl scripts without actual file on a cpanel account

gbfcii.pl It is not a file name. It is a portion of the command. You may not find the file in filesystem. After you kill the perl shell this PID's parent changed to root process.


Abnormal SYN traffic from Blackhole DNS servers

Is this a spoofed SYN flood?

At first glance, this may look like an attack. An attacker can initiate a SYN Flood without using his real IP address. An attacker crafts a packet with an origin IP of a known IP such as that of a blackhole dns server. Your server may exhaust resources while attempting to respond with a SYN-ACK packet.

How can I tell

If your server does respond with a SYN-ACK packet, then the original packet is likely spoofed if the server doesn't respond with a final ACK packet.

Why am I seeing TCP traffic for DNS?

Per RFC6305

  A request sent to one of these servers will result in a response being returned to the client.  The response will typically be a UDP datagram, although it's perfectly valid for requests to be made over TCP. In both cases, the source port of packets returning to the site that originated the DNS request will be 53.

Explanations provided by RFC6305

Section 6 of RFC6305 provides further explanations of why you may see this traffic.

  Inbound Traffic from AS112 Servers

  Where firewalls or intrusion detection systems (IDSs) are
  configured    to block traffic received from AS112 servers,
  superficial review of    the traffic may seem alarming to site
  administrators.

  Since requests directed ultimately to AS112 servers are usually
    triggered automatically by applications, review of firewall logs
    may indicate a large number of policy violations occurring over an
    extended period of time.

  Where responses from AS112 servers are blocked by firewalls, hosts
    will often retry, often with a relatively high frequency.  This
    can cause inbound traffic to be misclassified as a denial-of-
    service (DoS) attack.  In some cases, the source ports used by
    individual hosts for successive retries increase in a predictable
    fashion (e.g. monotonically), which can cause the replies from the
    AS112 server to resemble a port scan.

  A site administrator may attempt to perform active measurement of
    the remote host in response to alarms raised by inbound traffic,
    e.g. initiating a port scan in order to gather information about
    the host which is apparently attacking the site.  Such a scan will
    usually result in additional inbound traffic to the site
    performing the measurement, e.g., an apparent flood of ICMP
    messages that may trigger additional firewall alarms and obfuscate
    the process of identifying the originally problematic traffic.


How to implement MySQL query fo RBAC authorization with fine grained business restrictions in role?

I am personally a big fan of PostgreSQL row based security which allows you to entirely decouple security from business logic, and is easy to bake into your data access middleware by mapping user's authentication roles to database roles.


New payment option on Paypal "Enter your online banking ID + password": Any mechanism that could make this safe?

Once you submit that form, the information clearly goes to PayPal. So, yes, your password is definitely sent to PayPal. However, PayPal is saying that that it only uses your bank account credentials to confirm/verify your account.

What seems to happen is that PayPal takes your information then sends it to your online banking provider for verification. What PayPal does with your credentials after that is unknown. They might store it for future payments, or they discard it after the verification process.

In one line: Yes, your bank password goes to PayPal. Is it bad? Well, it depends on how much you trust PayPal.

By comparison, in Finland we have a completely different system with PayPal. When PayPal needs to verify the bank account or withdraw from the bank account, you get redirected directly to the bank's online banking page. You login there, and then you get redirected back to PayPal. They only get a verification token from the bank. The system is called TUPAS.


It seems that these kinds of issues continue to plague Skype.

Best guesses seem to indicate bot scans or poor hygiene on Skype Adverts.

I would certainly suggest installing ad blocking on all of your browsers. I also install it on my router too.

If you haven't changed passwords on your Microsoft account recently, that couldn't hurt and you should certainly turn on two-factor authentication for the account.


How to disable cipher RC4 in ubuntu 12.04

There are still some RC4 ciphers in your list. To check which ciphers are offered by the server enter your list into 'openssl ciphers -V', i.e.

  $ openssl ciphers -V 'ALL:!ADH:!RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT' | grep RC4
      0xC0,0x11 - ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
      0xC0,0x07 - ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
      0xC0,0x16 - AECDH-RC4-SHA           SSLv3 Kx=ECDH     Au=None Enc=RC4(128)  Mac=SHA1
      0xC0,0x0C - ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
      0xC0,0x02 - ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
      0x00,0x8A - PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1

A good source for how to configure your server correctly is ssllabs.com. For examples of useful cipher settings see https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy.


Is this a legitimate Microsoft email or is this a Phishing email and how can I tell?

The aim of phishing is to obtain information about the victim, to which the attacker is not entitled.

There are two typical ways a phisher would obtain that information:

The victim supplies it by including it in a reply to the phishing email, i.e. by sending the information to an email address controlled by the attacker.
The victim supplies it by first following a link in the phishing email, which takes them to a web page controlled by the attacker, and by then entering the information into that web page.

Regardless of the mechanism, the aim is the same: to persuade the victim to send that information to some external resource (email address or web page) controlled by the attacker.

Therefore, to identify a phishing email, follow these steps:

Establish which mechanism the email is asking you to use: is it asking you to reply by email, or to click a link to a web page?
Establish whether the external resource is owned by a legitimate entity. Here's how:

View the source code of the email you received. If you don't know how to do this, look in your email client's menus for a "View source" or "View original" menu item, or look online for help with this step.
If the email you received asks you to send an email:

Read through the source code to find the email address it is asking you to reply to (e.g. the "reply-to" address). Make a note of the domain name for that email address (typically but not always the whole part after the "@" symbol). For instance, in the case of phisher@example.com, the domain name is example.com.

If the email you received asks you to click a link:

Read through the source code to find the URL it is asking you to visit. Depending upon how the email you received was formatted, this URL might be in an href attribute of an HTML a element. Make a note of the relevant part of the domain name for that URL. The relevant part consists of: the top-level domain or country-code second-level domain (i.e. the rightmost part), and the word and dot preceeding that. Examples:

URL: https://microsoft.odd.com/form/. Relevant part: odd.com.
URL: https://microsoft.odd.co.uk/form/. Relevant part: odd.co.uk.
URL: https://odd.microsoft.com/form/. Relevant part: microsoft.com.
URL: https://www.microsoft.com/form/. Relevant part: microsoft.com.
URL: https://microsoft.com/form/. Relevant part: microsoft.com.

Now that you have the domain name, or at least the relevant part of it, check whether it matches the ostensible sender of the email.

If the domain bears no apparent relation to the ostensible sender, the email is probably phishing. (E.g. email is ostensibly from Microsoft, yet domain is v5fld7s5d1g.com.)
If the domain bears some apparent relation to the ostensible sender, but is not their primary domain, the the email might be phishing. (E.g. email is ostensibly from Microsoft, yet domain is emailsfrommicrosoft.com.) In this case, perform a WHOIS lookup on the domain in order to establish the domain's owner. If WHOIS reports an owner that doesn't match the ostensible sender, the email is probably phishing.
If the domain matches the ostensible sender's primary domain name, then the email is probably not phishing. (E.g. email is ostensibly from Microsoft, and domain is microsoft.com.)

If you are still in doubt, contact the organisation in question after obtaining their contact information from some other, more trusted route (i.e. not using any contact information in the email). For example, in your case, you could look for Azure's customer service team's contact information on the Azure website and contact them to ask whether they sent you the email.


How do I deploy AD in a hostile location? What are the security implications between Domains, Forests vs RODC's in Active Directory?

Your best option is probably going to be a RODC if you want to be able to have full control over the domain(s).

A RODC is not any regular domain controller. By default all authentication requests are forwarded to a writable DC. RODC's will only store credentials if two conditions are met:

Credential caching is enabled (default is disabled)
A user has logged in from within the RODC's site

So enterprise admin accounts cannot be compromised unless an EA has logged into the RODC's site. I want to say that account credentials with administrative privileges will never be cached either, but I can't corroborate that. In theory you don't need to ever have an EA log into that site because you can set up RODC-specific administrative users. These users can have admin privileges, but cannot touch anything else on any of the other DC's.

See here: http://technet.microsoft.com/en-us/library/cc732801(WS.10).aspx


Suspect Exchange Server appears to be hacked. How to determine if it was a false positive?

Any good system administrator is going to know what files are on his company's server and what are in those files.

The first thing you want to do is use a program or write a script to take note of all the files on the hard drive.  The safest way to do this would to mount the hard drive on a known working OS so the OS doesn't hide any files from you.  You make note of this and keep it in a safe place.

The next thing you do is create a checksum for each of those files listed and keep that in a safe place as well.

This process will go well with your server backups because you'll know where to restore from.

Whenever you suspect and intrusion you will check to see what files have been added to the system and verify the integrity of the files with the checksum.  There will be certain files that will always fail of course, such as log files.  But you will want to flag files that have changed without your knowledge such as the boot files or system files.

An additional resource would be to analyze the traffic from the server.  Gather any information you can to be helpful such out going server port, where the traffic is going, etc.

Typically a compromised system is going to try and send things out to the internet.  Being that it was an exchange server, it may be used to spam emails so that it wouldn't look to peculiar.

A lot of intrusions can be detected with anti virus as well, but of course, that doesn't mean your safe!


Why does initial encryption take so long?

Veracrypt and it's predecessor Truecrypt transform plaintext disk content to cyphertext disk content on the fly.

There is a one-off process to convert the plaintext to cyphertext when commissioning the hard disk.

So this is a full disk re-write which is limited primarily by the speed of the hard disk. A spinning hard disk is the slowest part of the typical memory hierarchy (CPU Cache, Main Memory, SSD Cache, Hard Disk) and there are very few ways to optimise this process (i.e. the cache will not speed it up).

The on-the-fly rewriting of content is practically unnoticeable in comparison, especially on modern CPU's.


Identify malicious hosts in our network by sending valid domain credentials

AFAIK Cisco switches base their forwarding decisions based on MAC; regardless of what authentication occurred first.

You can use port-security to enforce MAC auth, but as discussed that is easy to spoof.

A better option is 802.1X  (Cisco just refers to it as dot1x);
whereby as a port comes up it asks the client to authenticate, back-hauls that auth to a radius/TACACS server, and based on the response enables traffic forwarding on that port (on server defined VLAN)

This can also be used for NAC -- if a legitimate host doesn't pass health checks (up2date AV/Windows updates) it can be quarantined to a remediation VLAN to update itself before being allowed to join the main network.

Ultimately, however, if a host has passed dot1X authentication, any frames sourced on that port, with the expected MAC address will be forwarded without further authentication.

A much more resilient option ( which also covers remote Layer3 traffic ) is IPSEC; My main experience with this is Windows, though Linux is capable (Racoon? - though more complex to administer) you can enforce IPSEC traffic policies whereby the individual IP packets have an authentication header to prove the identity of the sender (computer, user, or both); and if the receiver cannot validate that info the packet is dropped even before passing up the stack to (possibly vulnerable) application.
It does by definition cause inter-operability problems with external or non-domain devices (eg. printers)- which can be addressed with domain trusts (given similar IPSEC policy) or device certificates (from trusted chain)

You can configure IPSEC policy not only to authenticate connections, but to encrypt the data; which renders most MitM attacks useless.

You could identify attempts at non-IPSEC secured connections (or those that fail authentication) in event logs.


Antivirus settings: delete or quarantine the file?

I choose for quarantine because of false positives: the AV software can incorrectly flag a file as maliciuous or unwanted.

If it's quarantined, you can retrieve if from the quarantine and usually tell the AV to ignore the file from then on.
You could not do that if the file has been deleted.


You can define a system as provably secure if the security of the system ultimately relies upon a mechanism or rule which has some logical or mathematical proof.

For example, we can logically say that given a + b = c, it isn't possible to know the value of the other two values if you only know one, e.g. c=40 could mean a=20, b=20, or a=10, b=30, or a=-100, b=140, or an infinite number of other possibilities. This means that it's very, very hard to work out the values of a and b from just knowing c. If you can build a security system upon this premise, you have a provably secure system.

This concept is extended, in the case of RSA, to factorisation of semiprimes. Semiprimes are numbers which can be represented as the product of two primes, i.e. n = p * q. Given only n, it is relatively computationally difficult to work out the values of p and q. For example, it is trivial to multiply the primes 1009 and 6121 in a calculator to get 6176089, but it's much harder to guess which primes I used to get an answer of 27116399. I, as a legitimate user, can trivially multiply the primes, but you, as an attacker, must do some difficult work to guess which primes I used.

The way I would phrase it for RSA is as follows:

RSA relies upon the semiprime factorisation problem for security.
Semiprime factorisation is a known-hard problem (specifically, no general solution exists which can factor semiprimes in polynomial time or better) and as such requires significant computational work to resolve.
RSA therefore has the property that, assuming you pick a large enough pair of primes (and adhere to some other RSA-specific requirements, such as not making them too close), it will be computationally infeasible for an adversary to break RSA given most common threat models.

An important factor here is that the problem scales. If your threat model includes threat actors with significant resources, you can scale your prime sizes to make their work much harder, at the cost of increased computation time on your own system.


How to make a simple file integrity checker

You can place the file checker outside the web directory and deny read/write permissions for the account that is running the web server.  In other words do not allow the account running the web server to modify the file checker or the expected values for the file(s). Furthermore, make sure that the account running the web server does not have permissions to change the permissions of the file checker and expected values.

You could also do this from a remote machine, which runs the script and has the expected values, using either the Windows administrator shared folders (e.g. \PC\D$\www\file.php), or SSH on a Unix based system.

It comes down to permissions, as longest the account running the web server has the least permission required to run, and does not have permission to change the script file and expected values it will not render the file checker useless.

If you are interested on a heavy duty file integrity checker, for free, I recommend OSSEC.


How wireless routers are turned into a FlyTrap?

I'll tackle your second question first and then go back to the first.

No, firmware is not necessarily signed. Some vendors do, some don't.

  Most hardware makers don't cryptographically sign the firmware embedded in their systems nor include authentication features in their devices that can recognize signed firmware even if they did. [1]

My guess is that, in some cases, it's a matter of cost/benefit for the manufacturers. Adding cryptographic and authentication layers for their hardware just doesn't seem like it's worth the effort, even if considered in their threat model. As you see, it takes a very sophisticated entity to pull this type of exploit. Think about a cheap WLAN card manufacturer, chances are they are not going to go above and beyond to prevent it from being attacked by an entity like the NSA.

Other hardware vendors do care. Apple for example does sign their firmware. Or hardware used in smart grid applications are usually more cryptographically secure. Again, it just depends on how far (think cost) you want to go to protect your device.

Regarding your question about wi-fi open/closed. A password protection on a wi-fi hotspot doesn't make it invulnerable. There can be numerous ways to attack it; it just depends on the type of access that you have to the router (e.g. physical, remote, etc.) and the security protocols in place. In the end it's just a matter of how hard/easy it is going to be. How many individuals actually use strong passwords for their routers and admin controls? Most people don't want to type "3Vaz8d$#2!29bcSASxL%" as their router password, for example, and opt to go for more generic ones such as "we_dem_boys_2017"

Sources and Further Reading

[1] WIRED: Why Firmware is so Vulnerable to
Hacking
[2] WIRED: Hot the NSA Firmware Hacking
Works


You could use a scanner to guide you, but you need start with secure coding.  Use a scanner to test for verification after you have implemented the secure coding concepts.  First rule of secure coding is See input as evil.

The first step to not trusting input in a web application is to encode (not filter) all user input.  So, your input example will be HTML encoded to

&lt;script type=&quot;text/javascript&quot;&gt;
alert(&quot;This is an example of what will happen&quot;); &lt;/script&gt;

Which will be interpreted by your browser as text and not as code.

Also see the OWASP Secure coding cheat sheet.


Does manipulating a random password significantly reduce its entropy?

Any question about password entropy needs to start with a discussion of what "password entropy" really means, and what kind of attack you are trying to protect yourself from.

In a nutshell, password entropy is an estimate of how many incorrect guesses an attacker will have to make before they stumble onto your password. These estimates are based on standard brute-forcing dictionaries that are available online.

If you type your password into a password entropy estimator and it gives you a very long crack time, then you're probably ok against "drive-by" cracking attempts. By "drive-by" I mean that you are not being targeted in particular, you are just part of a large set of accounts that are being attacked. (As a side note, beware of typing the password you're about to use into an online entropy estimator, unless you've checked the source code for that site you have no guarantee that they will not add your password to the dictionary!)

What other people are going to answer is that if an attacker knows that you like to cluster your uppercase characters and they build a custom dictionary for you (or many people start doing this and the "drive-by" dictionaries start including that pattern), then your password loses roughly half its entropy. Fine, but is that really what you should be worried about?

If you're doing something non-standard (like clustering your uppers) and we make the assumption that the attacker knows that, then we're already out the domain of "drive-by" attacks and we should also consider things like:

Have any of your accounts been previously hacked? Do your passwords appear in leaked password databases [1] [2]? If so, how much information can they gain about the "patterns" that you use?
Do they have access to your emails, sms, blog posts, etc, to see what kinds of words you use?
Can they craft targeted phishing emails for you?
Do you always check the certificate info of a page before typing in your password?
Do you download software off the internet?

As you can see, once we're out of the domain of "drive-by" attacks, the theoretical entropy of your password very quickly stops being the important point.

I'm a strong advocate of the idea that once an attacker is spending effort to learn things about you, the whole idea of password entropy no longer makes sense.

Bottom line: Since you're starting from a random password and only applying a very mild pattern, you still have plenty of entropy. If you are worried about attacks other than drive-by dictionary attacks, then the entropy of your password is largely irrelevant because other factors become much more important.


What is the difference between "unknown" and "undefined" trust?

The options 2 to 5 (never, marginally, fully and ultimately trusted) correspond to a definite decision made by you on the trust level which influences validity calculation.

Unknown says, you haven't made any decision at all and thus is special, indicating no value at all (you might consider it some kind of NULL value).
Option 1, undefined is similar and has similar outcome regarding validity caluclation, but is a statement you can issue on not wanting to decide on the key's trust level. You might want to use it as future reference instead of not setting any trust value.


Are we safe from phone-to-phone-spreading BlueBorne malware horror case?

I guess BlueBorne is a big thread but is still a "ghost". At the moment, there is no public exploit published. The author of the paper used eight different zero-day vulnerabilities (four in android bluedroid , two in linux BlueZ, one in windows and one in iOS) to perform the hack and to perform this, a lot of knowledge is required. Only very skilled hackers can do it. The probability of being hacked is still very low. But I guess soon there will be public exploits available and the thread will be real.

You can see here an awesome video of the hack pwning a Google Pixel device:

BlueBorne on YouTube

There is available an app to check if your device is vulnerable to this hack:

https://play.google.com/store/apps/details?id=com.armis.blueborne_detector

Regarding the spreading. I'm not sure if it can be a big problem (this is purely opinion based).

Anyway, remember best practices. Only to turn on Bluetooth if you really are going to use it (at car or however). Bluetooth has a very short range. The probability of being hacked at car is almost none :)


Are all SQL injections exploitable through time-based attacks?

There are definitely exceptions. While sleep may eg work for injections into order by, it doesn't work easily in limit:

select * from pages limit 1,sleep(1); // doesn't work

Obviously, you can still formulate an injection which contains sleep, but I'm guessing sqlmap doesn't have it as default when scanning.

You would also miss injections where the server filters all SQL keywords but still allows inputs like ' -- -.

As noted in the comments, it will also not work if the DBMS does not support a sleep-like function or if you are using the wrong function.

It will also be rather slow (which may or may not be fine) and error-prone (sometimes requests just take some time, especially if you are sending out a lot at a time).


ManicTime records video of session activities and indexes the video with the time sequence of active applications. It is free for personal use but not for commercial use. It is not a keylogger. If this category of software would meet your requirements, you can find a few similar products at alternativeto.net.

There is also the category of software designed to enable employers to monitor employees' acceptable use of computers. A recent answer here on security.se uses the example of the "SPECTOR PRO" product.

Returning to ManicTime, it is primarily designed for one to track one's own use of one machine. However, I see that it has several features that may be useful for monitoring an untrusted user, or multiple machines, or both. It has options to suppress its system tray icon, encrypt its data with a password, and schedule local or remote backups of its data. It can be used in combination with a cost-free server product that aggregates data from ManicTime application instances. It can reportedly store 20 years' worth of data in one gigabyte.


Is it possible to exploit computer vision to achieve remote code execution?

Buffer overflows don't just occur with text, so it may be possible to pass an 'image' that exploits something in the image processing.  Bad code always exists though...using OWASP has a good example page, and we can construct a simple function which could overflow:

int main(int argc, char **argv)
{
    char items = imageprocessor(); // process image seen
    char buf[8]; // buffer for eight characters
    strcpy (buf, items); // cause the overflow
    printf("Items seen are: %s\n", buf); // print out data stored in buf
    return 0; // 0 as return value
}

Now, let's suggest the computer vision algorithm is identifying items and returns a char array with those items separated by a comma.  If our algorithm identifies a car, a box, and an elephant, we cause an overflow.  If our algorithm identifies text characters we could potentially control the input to that overflow.

You already identified adversarial inputs and software such as Apple's FaceID has been bypassed in the past, but these exploit the verification method used by Windows, such as WBF in Windows, rather than any ML method.


Who is the target for bot nets?

A lot of botnets use consumer devices that are insecure by default, or are shipped with vulnerable software.

Imagine you buy the ACME HomeLink™ wireless router, which comes with a neat administrative console for customer comfort. If you have a problem, all that customer service has to do is connect to your router on port 32123 and use the password shibb0l33t and they will be able to fix your problem remotely.

Of course, this is highly insecure, so a botnet could just scan certain parts of the web for an open port 32123 and attempt to log in with the publicly known password. They can then remotely flash your router with a custom firmware, which makes it also part of the botnet.

I'm using a router here as an example, because it's a delicious target for bot nets. They are by nature externally accessible and always online. This makes them very lucrative. Of course, other devices can become part of bot nets, such as IoT devices, unpatched servers, etc.

Doesn't this all require user interaction?

The way you framed your question seems to suggest that networking primarily serves the purpose of user interaction. This is false. In fact, the overwhelming majority of network traffic is automated and happens without any user interaction at all. An example of this are software updates, which happen completely without the user's interaction at all.

Furthermore, you suggest that botnets are primarily created by using malicious downloads or links. This is not the case, as personal computers aren't really that good as a "bot". As I mentioned before, the ideal bot is easily accessible and always online. A personal computer is usually not online all the time. Most people use their computer only for a few hours per day, and then turn it off when they do something else or go to sleep.

Personal computers, of course, can be abused otherwise by malicious actors. Other categories of malware are more prominent on our personal computers than on routers for the following reasons:

Computers usually have more personal and thus valuable data on them, whereas routers rarely have any personal data at all. As such, Ransomware targets this by encrypting such valuable files and exploiting our desire to keep them. If a router stops working, I could just buy a new one.
Computers are usually much more powerful than routers, and as such makes crypto miners more efficient on a PC than on a router. Even though the uptime is limited, the extreme difference in computational power of a laptop compared to a home router makes the computer more desirable of a target.
Computers are used to connect to valuable services such as online banking, PayPal, etc. This allows malware to get access to passwords used with these services, or to interact with them directly (e.g. send money from PayPal to an account used by the attacker).

What can a bot do once it gains control?

That heavily depends on the software. Some botnets communicate via P2P systems, meaning that any bot could forward an instruction to any other bot. That means an infected bot does not necessarily need to directly link to the "master" server. It's enough if the master tells one bot what to do, and this bot then propagates the information.

Other bot nets are designed to communicate to a "Command and Control" server, which simply tells the bots what to do.

The actions of the bots vary from botnet to botnet. Some are used to send spam emails, others are used to DDoS a web server, others are used to mine Bitcoin. Basically, if you asked yourself what you'd do if you had control over 100000 machines anonymously, I'm sure you could think of some more examples.

What about home devices?

Botnets are usually rather limited in the kind of devices they can infect. In fact, the operator of a bot net does not care in the slightest about attacking you or every device you own. If they can get enough bots by just exploiting the insecure configuration of the ACME HomeLink™ routers, then that's all they will do. Sure, the bot may attempt to connect to port 32123 on all your devices, but since they don't offer the same functionality, it won't work. Even if your home devices were vulnerable in some way, the botnet would not infect them if they were not previously designed to do so.


Preventing access to encrypted files at all

Here is what you asked: "I want to hand the encrypted data to this party to store and process, but I don't want them to see the encrypted data."
That's not possible or realistic.
If you don't want them to have access to the data, then don't give them access. Don't give it to them.
You could try multiple levels of different encryption, but that's just encrypting in layers. They still see the encrypted data, just higher levels of it.
You could hide the encrypted data in other data so that they don't notice the data, but they could still notice it, if they looked for it.


Sequential identifying string that can't be reverse engineered (the "invoice number" problem)

The standard approach to this kind of issue is to create a UUID  (Universally Unique Identifier) for each picture. This is generally a random 128-bit identifier which you can assign to each picture without any particular concern that it would be possible to enumerate the pictures via a brute-force attack on the namespace.

For example in .NET you can use the GUID structure for this kind of purpose. Since Windows 2000 (source), Guid.NewGuid generates random (version 4) UUID. (Ancient versions generated a version 1 UUID which reveals the date when it was generated, doing nothing to protect you from the "invoice number" problem.)


As a contractor how do I work on multiple client networks without data leakage?

You could use a very small VM for each one, but keep the IDE on the host, not on the guests. Share a folder from the VM to the host, so you use the host and its resources to develop, and use the VM networking to access the client environment.
Most of the VPN software can run on Linux, so you could create a very light Linux guest with 256MB of memory and install only the VPN client and ssh server. To access the environment from the host, use SSH Tunneling to create a proxy (putty, for example, works very well) so you don't need VPN on the host.


Is the double submit cookie pattern still effective?

Double-submit cookies was always a relatively weak CSRF protection, at least as typically implemented. Any attacker who can set a cookie - either via a cookie injection vulnerability in the app or via man-in-the-middle (MitM) attack - can defeat the typical implementation of double-submit cookies; this has been known for many years. It also requires that the CSRF-protection cookie be Secure-flagged, or a MitM attacker can usually steal it.

There is actually at least one thing that changed in recent years to make double-submit cookies less insecure than before. HSTS (HTTP Strict Transport Security) is a big help; with every major browser supporting HSTS and TLS performance becoming essentially a non-issue, there's less excuse than ever for not using HSTS. HSTS prevents most ways an attacker could steal or set cookies. You can also use the SameSite flag on your session cookies (with most browsers) to block most CSRF attacks; although not directly related to double-submit cookies, these techniques can be combined for additional defense in depth.

If you want to use double-submit cookies for CSRF protection, I recommend cryptographically tying the anti-CSRF token to the session token. A really simple way to do this is just to make your anti-CSRF token (sent in the request body) be an HMAC of the session token (using a secret key stored only on the server or in a hardware security module). This avoids even setting a second cookie specifically for CSRF protection, but an attacker cannot meaningfully spoof the token because changing the session cookie will break the user out of their own session. Alternatively, you can set an anti-CSRF cookie, and then have the token value be an HMAC of the cookie and some user identity data (such as a username or user ID); this means that your users will not need to update their anti-CSRF tokens every time their session token changes (which might be frequent, if using a short-lived JWT or similar) but an attacker won't be able to log in themselves, find a valid CSRF-cookie + CSRF-token combo, and plant those values in a victim's browser session (or rather, it won't work if they do, because it will be for the wrong user). Additionally, use HSTS (on all sites, including subdomains, and add it to the preload list) and, if you can, also use at least the "lax" SameSite flag. Neither of these will protect users on IE10- (or similarly old browsers), but you probably don't have many such users.


Should we protect web application source code from being stolen by web hosts through obfuscation?

A malicious hosting provider can do a lot more than simply steal your code. They can modify it to introduce backdoors, they can steal your clients' data, and ruin your whole business. Trust must exist between you and the host.

About the source code. If the attacker is trying to gain access to your source code, they will gain access to your source code, obfuscated or not, compiled or interpreted.

There is a value in obfuscating your code, in that you'll probably make it just a liiiiitle bit more difficult to be obtained by the occasional opportunistic attacker. But if your host is out to get you, they'll get you.

The solution? The law. Sign a contract with them and agree on some form of NDA.


It's incredibly hard nowadays to intercept and attack device bluetooth. It's constantly changing channels as well as it's encrypted and, especially with a mouse, there's a low attack plain with the device. The most they could intercept from your mouse, worst case scenario, is the movements.


Vulnerability scan scheduling approach on demand versus change?

There are a few times you should do vulnerability scanning, and a configuration audit, each having their own purpose:

When a new system or application is being introduced into the environment.  This is to evaluate the risk posed by introducing the new element into your environment.
When a change has been made to existing systems or applications in the environment.  This is to assess the risks introduced by the change.
Periodic scans of all systems, according to a regular schedule.  This is arguably the most important of these three.  It serves a few purposes:

Maintain an up-to-date baseline of the security posture of your environment.
Detect unexpected and/or unauthorized changes to the environment.
Identify systems which are vulnerable to newly-discovered exploits which would not have been covered in previous scans.

All of the above serve their own purpose as outlined here.  Each has their place in a proper risk management and discovery policy.  You should be including all of these in your process, and to do without any one could potentially leave an unnecessary window in which you may be oblivious to vulnerabilities that you could otherwise have discovered early on.


Hidden digital watermark in a website which can survive .jpg screenshots?

You could take your screenshots as .PNGs? But if you mean you want a secret watermark to survive someone else taking a copy and choosing their compression then I'm afraid nothing will help, because pixels (see the image attached). Then you would need a big old banner at the bottom and they can still blur it out.


Is my information secure when using Private Tunnel?

I don't know the refered VPN, but, if it matches what the website says, i think you're good.
The only way i'm seeing you're not safe is that if you're using a wireless connection, the data can be intercepted, it would still be encrypted, but you never know... better safe than sorry.

And as @Johnny said, if you're using HTTPS, and SSL you're safe, don't be worried.


Link between Cipher suites and certificate key

The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite uses RSA for both authentication and key exchange.  Key length is not specified, but the current standard is 2048 bit RSA keys, so that is likely what is used in this case.

For other ciphersuites, you may see components that differentiate between the key exchange algorithm and the authentication algorithm. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 would be an example of this, where ECDHE (Elliptic Curve Diffe Hellman Ephemeral) is the key exchange algorithm, but the key in the certificate is for the Elliptic Curve Digital Signature Algorithm.

So, if the ciphersuite being used for your TLS session was TLS_RSA_WITH_AES_128_CBC_SHA, it was for an RSA certificate, not an ECDSA certificate.  You would have needed to use a different ciphersuite in that case.


Which access rights should be chosen for doku wiki?

Generally the best practice for web site permissions are to give the web user, in your case www-data, read, but not write, access to the data files. That is, something similar to:

chown root:www-data -R /var/www/html
find /var/www/html -type d -exec chmod 750 {} \;
find /var/www/html -type f -exec chmod 640 {} \;

The goal is to allow the web server application to read the files, but not be able to write anywhere. That way if the web service itself is compromised we have limited a malicious user's ability to drop arbitrary files. (Read up on chroot as a corollary, but is outside the scope of this answer).

Wikis, by their nature, must violate this practice for them to properly function. However, the key is to understand exactly which parts of the wiki software need higher privileges. In order to really decide, you have a choice:

Use the web interface for creating/editing pages only.
Use the web interface for creating/editing pages, as well as managing configurations.

Option 1
This will set up all of the file level permissions such that users can edit/create pages, but it will require you to manage configurations manually. If you (or whomever manages the wiki) feel comfortable with PHP syntax, and don't mind working on the config files then this is probably your best bet. So your permission set should look like:

chown root:www-data -R /var/www/wiki
chmod 750 /var/www/wiki -R
chmod 770 /var/www/wiki/data -R
chmod 750 /var/www/lib -R
chmod 750 /var/www/conf -R
find /var/www -type f -exec chmod -x {} \;

So what we've done here is given root read/write and www-data read only to all wiki files. Then given www-data the additional rights to write to the user data section.

Option 2
If you also want to manage the configs through the web interface then use the same setup as above, except swap out line 5 for:

chmod 770 /var/www/conf -R

Disclaimer: I've never run DokuWiki setup like this, but I don't see any reason why it won't work. Test it out first, eh?


Replace hashing function with asymmetric cryptography when password authentication

... hash value(as ECC private key) -> generate public key from private key

You are assuming that an arbitrary key (output of a hash) can be used as an ECC private key and that the public key can be derived from this. This is not how it works though. If you want to derive a key pair from an existing random string or passphrase you would need to use some deterministic random generator in the key generation process - see  How can one securely generate an asymmetric key pair from a short passphrase?.
If you see the conflict between the words deterministic and random in the last sentence you might realize that this is maybe not such a great idea to do. It should be doable though.
I'm pretty sure that there is a better way to solve the actual problem you have. But currently I see only particular technical aspects in your question and not a real description of the underlying problem you are trying to solve at the end, so it is hard to tell how a better approach to the (unknown) underlying problem would be. It might be useful though that you check (and document in your question) existing approaches to your problem in more detail first before determining that you need to invent your own approach - see Why shouldn't we roll our own?.


To understand this, we must understand how crawlers find the email. While steering away from the technicals, the basic idea is this (today's algorithms are, of course, smarter than that):

Find @ in the page.
Is there a dot within 255 characters after the @?
Grab what's behind the @ until you reach a space or the beginning of the line.
Grab the . and what's behind it until you reach the @.
Grab what's after the . until your reach the end of the line or a space.

Now, an easy countermeasure would be to replace the @ with at and the . with dot. The most intuitive counter-countermeasure would be to teach the crawler that at is actually @. Well, it's not that simple. Take the following text:

  We climbed into the attic and found a dotted piece of wood. Please email us: adnan at gmail dot com.

Now let's run our new crawler on it. First it will find the at in attic, then it will find the dot in dotted. The resulting email would be the@ticandfounda.ted, then it will find the second email adnan@gmail.com. Then spammers started teaching crawlers about finding certain domains, ignoring spaces, taking spaces into account, considering certain domain names, etc.

Then we started using images, spammers used OCR. We started using JavaScript tricks, inserting comments, URL-encide, etc. and always the spammers found a way to get around them. It's a race.

Having that said, the most basic techniques usually give good enough results (apparently, in some place in the world, that link is NSFW. Personally, I disagree), and the more obfuscate, the better results you get.

So, to directly answer your question: Is using 'dot' and 'at' in email addresses in public text still useful? Yes, I think so, at least to some degree. But this solution has been around long enough for us to assume that some crawlers have already found a way around it.

My advice? Either use some fancy advanced munger, or simply use images.


How can illegal downloads (not file sharing) be detected?

If you use a public hosting service, that service could of course also keep track of what it's hosting and who uploaded and downloaded it.

If the filehost is not a honeypot, if you use an unsecured or semisecured connection with a known protocol to transfer your files, the ISP could track whenever you initiate a file transfer. If the protocol works with an open checksum, the ISP could take that checksum and compare it to one of its databases. If they find a match, they have strong evidence that something that wasn't supposed to be shared was shared.

Now this could also work for encrypted file sharing systems such as the one hosted by MEGA, if the ISP got a hold of the keys and inspected the file, deemed it illegal, and then started tracking whoever is downloading it. (this is not hard considering most people leave the keys in the link - the ISP could backtrace your steps and inspect the pages for the hashtag keys, or defer that task to a crawling service (would probably be faster))

Alternatively, a shill (cop, digital rights holder, etc) could transfer you the files or request that you transfer the files and then rat you out.

Beyond that, a spying agency, a bored hacker or anyone being able to install software on your device (e.g. the company you have your operating system from) could have installed spyware on your computer to track what you are doing.

Finally, somebody could be looking over your shoulder.


How can I test my spamfilter under real world conditions?

A good way to test your spam-filter is by actually spamming it yourself. Try to spam it yourself by using the techniques spammers use, on smaller scale. If your protection works on small scale, you can also assume it works on bigger scale.

There are also various of tools which allow reliable testing:

SpamAssasin - GTUBE
EmailSecurityCheck
Litmus

Especially GTUBE (Generic Test for Unsolicited Bulk Email) is often used and works similar like EICAR for testing Anti-Virus setups.

However, lot of those filters also work with blacklisting. So the best testing-method is throwing your service online and see if you receive real-world spam.


What should I check on temporarily lost computer?

It depends on your level of paranoia

Depending on the skills and maliciousness of this stranger there are many things he might have done.

Login to any account with credentials stored in your browser (easy)
Read your emails looking for sensitive info (easy)
Send spam emails to all of your contacts (easy)
Copy your documents to a USB drive (easy)
Clone your entire hard drive to extract things like credit card numbers and other sensitive info (intermediate)
Install some sort of virus to gain control of your laptop and spy on you at a later date (OS X can get viruses, they are just much rarer than Windows) (intermediate)

After changing passwords, you should probably scan for viruses. Apple's Customer Support can help you with this. If you're a really paranoid person, you might even want to reinstall OS X. Also, watch out for your identity being stolen in case Mr. Stranger found your credit card number or something similar when he potentially searched your hard drive.

IPv6

Many ISPs have already begun to partially implement IPv6. I have Comcast and I have IPv6 up here in Minnesota.


Exploit-db like websites, where people can search for security bugs

Try these for a start:

http://www.securityfocus.com

http://osvdb.org

http://web.nvd.nist.gov

http://secunia.com


Can email be secured by the receiver only, without action by the sender?

No, email in general is insecure. Each server that relays an email necessarily gets a copy, and encryption is opportunistic, so you can't even guarantee that it'll be encrypted between relays.

Deleting it from your sent items would only help if your account gets compromised.


1) During connection process server sends his certificate to the client. Certificate contains his public key and digital signature. How is this digital signature formed? Is it static or generated independly for each connection?

The digital signature contained in the certificate sent by the server is generated by a Root CA which the client trust (your browser). This means that a Certificate Authority that you trust has signed the certificate that you are validating. In real world, a Root CA has sign an intermediate CA certificate that has sign the server certificate. The digital signature is a Hash of the server certificate signed with the CA private key.

  2) When client receives this digital signature he has to decrypt it. Which public key is used for it? Public key of the server or public key of the CA?

This process is called Certificate Chain Verification. You verificate the digital signature of the server certificate using the public key of the CA that has sign the server certificate. If it's correct, then now you must verificate the digital signature of that CA with the public key of the next CA, until you hit the Root CA that you must trust in order to validate successfully the certificate (along with other checks that are performed).


Trying to create safe website where security is handled by the website and not the user

Don't do it

If you are targeting unsafe regimes, the consequences can be severe. For example, in Iran, condemned homosexuals are usually sentenced to death by hanging.

It would only take the slightest lapse on the part of your site, or one of your users for this to be incriminating evidence. Can you imagine the guilt you would feel that your well-intentioned site ended up being evidence that led to an execution?

To operate online subversively in a repressive regime takes extreme skill and caution. Simply using Tor would be a red flag in itself. While hacker groups like anonymous may be able to get away with this, normal users cannot.

There have been comments on other answers saying (roughly) "use HTTPS, it's fine". I cannot stress strongly enough how that is dangerous advice. HTTPS reveals the domain name the user is accessing, it leaves trace on the client computer, and it's likely that nation-states (including Iran) can produce fake certificates and intercept all HTTPS traffic.


Is it possilbe to use an OpenPGP private key to sign a file via OpenSSL?

While OpenPGP and X.509 mostly share the same cryptographic algorithms, they have completely different representations of the key material. GnuPG (or to be more specific, gpg; gpgsm implements S/MIME and X.509 but not OpenPGP and is also part of GnuPG) does not "speak" X.509, OpenSSL does not support OpenPGP.

While you could well extract the numbers forming the keys and then construct a new key of the other format, these would still seem like different keys: due to the different protocols you cannot read messages encrypted in the other system, you cannot verify signatures issued by this. Even the keys are not obviously comparable, key identifiers are constructed differently, and finally the two systems share different trust systems.

To wrap up: theoretically you could construct a new key (not really convert it, as meta information is lost and other information is missing). There is no actual use in doing so, thus nobody cared about writing proper tooling for the process.


why do they call packet filter firewall a PACKET filter firewall

You are correct in that ports are part of layer 4, but packet filtering firewalls, even though they operate mostly on layer 3, also inspect the port numbers.

Even the simplest firewalls will do this, but because they do not make decisions based on the rest of the layer 4 data, "packet filtering" is appropriate. You could think of it as "enhanced packet" filtering.


What happens if multiple Strict-Transport-Security headers are set in the HTTP response?

According to RFC 6797, 8.1, the browser must only process the first header:

If a UA receives more than one STS header field in an HTTP
response message over secure transport, then the UA MUST process
only the first such header field.


Is taking social networking details legitimate for a credit card?

Normal? No, not right now. But, we are going to see far more of this level of personal verification in the near future.

One of the difficult things for any company (or government) to do is to verify the 'identity' of a person online. It is an exceedingly complex problem with no clear solution. National identity cards (or government-backed official online profiles for people) are being considered, but there are huge privacy concerns. The approach taken by verifi.me is a compromise.

The one thing that is very, very difficult to fake or counterfeit is one's online life. There is so much detail being generated in normal use, that a fake profile will be evident. So, companies like verifi.me request access to your email and social media life to run an analysis. They then sign off that 1) you are a real person, and 2) that the details you provided in your bank application are likely true.

Creepy? Oh, yes. Privacy invading? Absolutely! But it is also a very real, and very effective means of verifying a person. It solves a very real problem in the world today.

Would I let a service like that crawl all over my personal details and private communications? Absolutely not. In fact, knowing that this type of thing is coming, I'm considering a process where I have a shadow set of online profiles where I programmatically send less sensitive copies of my real communications so that it is a subset of my online life. That way, services like this (and governments) have real data to go over, just not all of it. But, that's another topic.


it should be available offline, and it should be secured in a way that a user should not be able to take the application content and give it/sell it to a competitor

This is not in general possible. The user controls his computer, and can bypass any security mechanism if he is motivated to do so. For example he could use a debugger to halt your program and read the keys from memory.

Complete prevention by technical means is not possible, so is the wrong goal. Suitable goals are:

Keep honest people honest
Provide tamper-evidence/audit trail.

The first can be achieved relatively easily be obfuscating or encrypting local files in some way. However your scheme is over the top. You need only issue each user a unique key (which the app stores) and issue the documents/resources encrypted to that key. Of course they can easily decrypt it if they put in a little effort.

The second needs to be achieved using some sort of watermarking scheme. There are many, but if you are for example supplying the content as PDF files, you can watermark these easily with for example "This copy issued to username@example.com on 2014-01-21" on every page - this will be visible to the user. (In light grey, running up the left hand edge of the page is a popular choice). You might also want to include a second "secret" watermark, to attempt to catch those who go to the lengths of erasing the obvious one.

https://en.wikipedia.org/wiki/Digital_watermarking

Watermarking requires you to issue an individual copy to each user. This is not technically difficult of course, but may be inconvenient.


ISAAC says it is based on RC4 (even if it is better than RC4), so AES-CTR will be more secure. Plain RC4 has been disallowed in all secure communication for good reasons. Also, RC4 is only 0.460GB/sec/core, but it shouldn't be used even if it's fast.

On my laptop, AES-128-CTR can run at 4.8 GB/sec/core (openssl speed -evp aes-128-ctr) and ChaCha20 can run at 2.5 GB/sec/core (openssl speed -evp chacha20). Both are random enough for any purpose, though in theory ChaCha20 is more secure.

My linux 5.0.0 kernel gives me 0.161 GB/sec/core read from /dev/urandom (reading 1MB at a time), even though it uses ChaCha. Investigation below.

Disks have block remapping and SSD disks have very complicated garbage collection, overwriting the user-visible blocks might not be enough. So you should try to use the disk's firmware's "secure erase" features. For example, some disks actually use AES encryption even if it is not enabled by the user, just to ensure data stored on the disk has about equal number of 1s and 0s. Then, clearing just the AES key erases all data (you just have to make sure it really cleared the key, which might be complicated).

I tried perf to see what linux is doing:

      - 99.83% read
         - 99.81% entry_SYSCALL_64_after_hwframe
            - do_syscall_64
               - 99.81% __x64_sys_read
                  - 99.81% ksys_read
                     - 99.80% vfs_read
                        - 99.77% __vfs_read
                           - 99.26% urandom_read
                              - 90.55% extract_crng
                                 - 89.44% _extract_crng
                                    - 39.99% chacha_block
                                         chacha_permute
                                      2.85% _raw_spin_lock_irqsave
                                      1.46% _raw_spin_unlock_irqrestore
                                   0.53% _raw_spin_unlock_irqrestore
                                4.63% copy_user_generic_unrolled
                              - 1.62% __check_object_size
                                   0.77% check_stack_object
                                0.76% _copy_to_user

_extract_crng is spending all its time waiting for rdrand (called arch_get_random_long).

The chacha_permute, which takes less than 40% of the time, uses the slow non-vectorized version for some reason, when a vectorized version is available (and even an AVX2 version). Loading the module chacha_x86_64 didn't help. My guess was that the random char device driver is linked with the generic chacha implementation and will only use the fast chacha implementation if that is built linked into the kernel and not as a module, but after compiling a 5.3.0 kernel with vectorized chacha (CONFIG_CRYPTO_CHACHA20=y, CONFIG_CRYPTO_CHACHA20_X86_64=y) no dice - urandom is still using slow chacha. I don't know why.


Because it adds security without any significant burden on users.

Before CVV2 was introduced (around 2000), most transaction records contained all the information someone needed to commit fraud. These could be receipts, till logs, transaction databases, etc. With CVV2, merchants are banned from storing it, so it reduces a lot of sources of fraud. The CVV2 is not on the mag stripe, but there is another code (CVV1) that is.

You probably also have a PIN for your card, but that's a different security mechanism. For example, I would never input my card PIN when making an online transaction.


When accepting an SSL certificate, can I limit for which domains I accept it?

Nope.
At least not in a way which is fun or scales well.
While technically what you want is absolutely possible, practically the infrastructure to cut down permissions from the regular binary "complete unconditional trust"/"no trust at all" to something in between the two extremes is not really there.
While it's a relatively straightforward idea there is just no interface that I know if that would allow you to apply name constraints or other constraints to a CA (or anywhere else on the certificate path).
What you COULD do is manually PIN things. Which is a way of whitelisting exactly what you expect of a certificate chain before you accept an end-entity certificate that is part of that chain. Typically the idea is to PIN (explicitly whitelist) the public key of a cert on the cert chain. -- That's the idea at least. Again there is no great UI. -- However I have come across a Firefox extension in the past that tried to do something roughly similar. However I found it very cumbersome and unpractical. Also I don't know if it's still supported. But if you're really, really determined, you might give it a try: "Certificate Patrol": http://patrol.psyced.org/


Should admin user be visible to regular users

What can you do when the only information you have is a username ? You can conduct a brute-force attack in the hope of finding the password. So you should have 1) a strong password and 2) a mechanism to detect and thwart attacks. Why not add 3) 2FA is the stakes are high enough.

One possible strategy would be to have multiple levels of access rights.
For example you could have a public helpdesk user with limited rights, and another, unpublished user account (preferably not one that is predictable/easy to guess) with admin rights to work behind the scenes.

In this setup the users will always interact with the helpdesk account and never with the admin, that they don't know. Thus, even if the helpdesk user account is compromised, the damage is contained.

That means your application has to have a feature for hiding accounts somehow. I would weigh the pros and the cons. If you have to tweak an existing architecture a lot to achieve this goal, this may not be worth it.
When it comes to security, simplicity is better than complexity. That means don't break stuff to fix a mundane problem.


How to store Oauth2 Access Token in a Cookie correctly?

You don't want to store access token in a cookie. Depending on the application, you want:

typical web application: store the tokens in your backend (database...)
native mobile application: store the refresh token in the Keychain / Keystore, and the access tokens in-memory
SPA (Single Page Application): store the access token in the localStorage or in the sessionStorage (beware of new risks involved)

And then, when requesting APIs, you insert the access token in the request, preferably in the Authorization header as specified in RFC6750. Example:

GET /api/somedata HTTP/1.1
Host: example.com
Authorization: Bearer NLdtYEY8Y4Q09kKBUnsYy9mExGQnBy


Is my passwordless auth (magic link OTPW) system secure?

What you describe is a token authentication system. Is is not so bad, and as it has been said in comments it a the common way to implement a forgotten password feature.
Some well know applications such as redmine natively offer such an authentication system to smooth the implementation of automatic operations using an API.
One problem is the duration of the token what you call the session GUID. Here you force the user to connect at least every three days which is really intensive. If it is for professional reasons, employees are generally allowed to take holidays longer that 3 days, and for non professional task doing them every 3 days is enthusiam (from the silver badge in SE network for visiting a site for 30 consecutive days). What is a user goes for a track in mountain without network access? That means that you will have to intensively use the password generation that only relies on username+email which is not enough secure for a generalized use. But you also know that the longer the session GUID is used, the more risk of being stolen exists.
Another weakness is the handling of a permanent cookie client side to store the token. That is more or less storing a password in clear text on the client which is known to be bad. This alone should scare any security aware user. For example in redmine, the token is generated and stored in the app, and the user generated one just before using it for its API requests.
Now for your questions:

A database call is made for each request, that can't be good
No problem here. Caches are meant for mitigate that problem. Do not even try to do it by hand but just rely on a well known cache. Also as you speak of a browser client side, you can just rely on HTTP (or HTTPS) sessions once a user is authenticated

Handling user roles would be really difficult with this method
User roles shall not be handled client side. You should have a table describing the roles allowed to a user: User_ID | Role_ID. When you find a user, you search its roles and store them server side in the session. Or rely on the cache if you use a non connected API.

This seems susceptible to XSS/CRSF attacks
It may or not be a problem. But you should at least ensure that the token cookie is associated only with your own domain! And also rely on common mitigation ways on forms.

TL/DR: This is a token authentication system. It can be used as a complement of a main authentication system but do has serious weaknesses in the described implementations if used alone. In the opposite, the remaining questions are not really a problem and can be answered in the common way.


Does recent Intel hardware mitigate Meltdown at the hardware level?

Recent Intel CPUs have PCID.  PCID helps a lot with the performance hit because without it, you have to completely separate the kernel TLB from the userspace TLB. (* Ok, not completely, but mostly).  If you have PCID, then the hardware has an extra feature to avoid the performance penalty from the cache misses that would normally happen when you do that.

To answer your main question, PCID does help with the performance issues of the workaround for Meltdown, but it doesn't fix Meltdown itself.  You still need to make sure you have a kernel with KPTI on Linux, or the similar kernel fixes in other operating systems.

References:
https://en.wikipedia.org/wiki/Translation_lookaside_buffer#PCID
https://groups.google.com/forum/#!topic/mechanical-sympathy/L9mHTbeQLNU
https://en.wikipedia.org/wiki/Kernel_page-table_isolation


To find out, look at the WP source code.

Nonces are generated by the wp_create_nonce function in pluggable.php. The real deal is this:

substr( wp_hash( $i . '|' . $action . '|' . $uid . '|' . $token, 'nonce' ), -12, 10 )

Where:

$i is a form of timestamp (it increases by one at a fixed time interval, and a nonce has a lifetime of two such intervals).
$action specifies what action the nonce is for (defaults to -1).
$uid is the user ID (special rules apply if the user is logged out).
$token is the session ID for the current session.

Taking a closer look at the wp_hash function (located in the same file), we find this:

function wp_hash( $data, $scheme = 'auth' ) {
    $salt = wp_salt( $scheme );
    return hash_hmac( 'md5', $data, $salt );
}

So it's a MD5 HMAC. The hash_hmac function is a PHP core function. The variable that for some reason is called $salt is the HMAC key.

So what is the $salt? Clearly it's dependent on $scheme that is "nonce" in our case. For more info, take a look at the wp_salt function. In the comments, you'll find this:

  Salts are created using secret keys. Secret keys are located in two places: in the database and in the wp-config.php file. The secret key in the database is randomly generated and will be appended to the secret keys in wp-config.php.

For more details on exactly where it reads the keys, see the actual code. As far as I can tell, it's completely unrelated to any cookies.

TL;DR: The nonce is a MD5 HMAC of a timestamp, the action, the user id and the session id, keyed with a secrets stored in wp-config.php and the database.


First of all, check your browser settings. Make sure your home page is google.com ( for example). After that, download adblock, with that plugin you can block sites, ads, etc... Add adf.ly to blacklist, and i belive problem will be solved.


What is risky about international travel?

It all boils down to one factor: you lose physical and direct control over the storage medium/device. Government inspection (border crossings or otherwise) and spending every minute of the day in environments that you do not control (hotels, restaurants, public spaces, etc.) that an adversary could control weaken your ability to retain or regain control over the storage media.

We could list a hundred things that could go wrong, but they all boil down to that one fundamental factor.


Configuration settings maybe static but new platforms are introduced time and again and you'll need configuration settings specific to those. Sadly CCEs aren't expanding at the same pace as CVEs.

  1) Are CCE's still used at all?

Yes, the CIS benchmarks still use CCEs for reference. Several government and related organizations depend on CIS benchmarks for their configuration monitoring so I would say that CCEs are still used.

  2) Has NIST abandoned this initiative as it hasn't been touched since 2013?

As you can see on this website there was some activity that happened regarding CCEs. But generation of new CCEids hasn't happened in a while.

  3) Are there similar initiatives out there?

If you are looking for something specific in the Configuration enumeration then I am not aware of but there are several different configuration standards in the market which you can look at. Speaking of enumeration systems, CVE (Common Vulnerability Enumeration), CPE(Common Platform Enumeration) etc come to my mind.


Can JavaScript be used to capture the user's screen?

JavaScript has full access to the document object model, so at least in theory, it could capture what's on its own web page (but not anything outside the browser window) and there's a library to do that: http://html2canvas.hertzen.com/  (I haven't tried it.)

The same-origin policy prevents JavaScript from accessing the DOM of another site. Since JavaScript cannot access the DOM of another site, it cannot leak material from the other site.  So, if your question boils down to whether a script running in one tab, or even an iframe, can capture the banking password from elsewhere in the browser, then no, provided same-origin is properly implemented in the browser itself.

Same origin applies to domain from which the page was served, not from which the script was served.  So, my page at hxxp://bbrown.spsu.edu/ (it wasn't interesting, and now it's dead because I've retired) can load a script from google-analytics.com, as it does, and that script has access to the DOM of the page from which it was loaded; it can also send stuff back to Google through a bit of sleight-of-hand.  The point is, it can do that only because I trusted Google Analytics enough to load their script in my page; the code that loads the page is in markup I wrote.  If you load my page into your browser, that script from google-analytics.com can see only the DOM of my page in your browser, and not anything else you may have open in your browser.


Question about compare Bell-LaPadula and Biba models with Chinese wall policy

Chinese Wall Model

This is an access control confidentiality policy. The access control policy states that a subject may access information from any company provided that the subject has never accessed information from a different company in the same conflict class. Consider the following conflict classes:

{Ford, Honda, Toyota}
{Bank of America, Wells Fargo, Chase}
{Microsoft}

If you access a file from Honda, you're prohibited from accessing files from Ford and Toyota, but you can access files from Bank of America, Wells Fargo, Chase, and Microsoft. The policy restricts access according to two properties:

Simple security rule: A subject can be granted access to an object only if the object (a) is in the same company datasets as the objects already accessed by the subject and (b) belongs to a different conflict of interest class
Star property: write access is only permitted if (a) access is permitted by the simple security rule and (b) no object can be read which is (i) in a different company dataset than the one for which write access is requested and (ii) contains sanitized information

The Chinese wall model addresses a specific concern: conflicts of interest by a consultant or contractor.

Biba Model

This model aims at the preservation of data integrity. Data integrity has three goals:

Prevent data modification by unauthorized parties
Prevent unauthorized data modification by authorized parties
Maintain internal and external consistency (i.e. data reflects the real world)

In short, it's characterized by the phrase: "read up, write down." This differs from the Bell-LaPadula model, which is captured by the phrase "read down, write up." In the Biba model, users can create content at or below their integrity level. For instance, a monk can write a prayer book that can be read by the common folk, but not by the high priest. On the other hand, users can only view content at or above their own integrity level. To continue the analogy, a monk may read a book written by a high priest, but may not read something written by a commoner.

The security rules for the Biba model are below. Note that they are the reverse of the Bell LaPadula model:

Simple Integrity Property: a subject at a given level of integrity must not read data at a lower integrity level (read up).
Star Integrity Property: a subject at a given level of integrity must not write to data at a higher level of integrity (write down).
Invocation Property: a process from below cannot request higher access; only with subjects at an equal or lower level.

Chinese Wall vs Bell LaPadula vs Biba

Now, to your questions:

  what the Chinese wall models try to achieve and how it differ from or improve upon the Bell-LaPadula and Biba models

I described what the Chinese wall model and the Biba model try to achieve above. In doing so, I also explained how they are different. The Chinese wall model is an improvement on Bell LaPadula and Biba because it provides confidentiality and integrity of data, whereas Bell LaPadula provides confidentiality, and Biba provides integrity alone.

Please see these sources for additional reading:

https://coronaluo.wordpress.com/2013/10/08/chinese-wall-vs-blp-vs-biba/
https://www.cs.utexas.edu/~byoung/cs361/lecture25.pdf
https://en.wikipedia.org/wiki/Chinese_wall#Computer_security
https://en.wikipedia.org/wiki/Biba_Model


How can two clicks lead to better security in the context of, e.g., Twitter and Facebook share buttons?

This is about personal privacy for users of the site.

Like buttons are advanced web beacons.  Its more than just a simple image,  but JavaScript that identifies if you are a logged into a social network,  and tracks your behavior over a long period of time. Facebook collects this information for targeted advertising.

In this security system, if you don't need the like button,  then don't load that JavaScript widget.  If you want to click like, then you need to load the specific JavaScript widget that you need.

Related:
https://stackoverflow.com/questions/7313037/how-do-google-1-widgets-break-out-of-their-iframe/7313430#7313430


Why not just use the built in Windows Firewall?  It does exactly what you've asked and is extremely lightweight.


Should JWT's be validated on every request?

To directly answer your question: it's necessary to verify the authenticity of a session token every time you receive a new connection. That doesn't necessarily mean every time you receive a request; if your system is never going to combine multiple users' requests into a single connection (which is very rare on client-to-server but relatively common on, say, load-balancer-to-server) then you can verify a connection's token only once and allow multiple requests over it during the lifetime of the session (though this is still riskier than verifying every request, because somebody might manage to cause the client to send a fraudulent request without knowing the token). Even when the risks are acceptable, if the session ends (user logs out, times out, etc.) before the connection breaks, you obviously need to stop trusting the connection.

As I implied in my comment, for a system like yours it really, REALLY depends on what you're storing in the cookie. For example, if you're storing the expiration data in the cookie value without cryptographic integrity, or worse-yet just relying on the expiration feature of browser cookies in general, that's risky because there isn't anything preventing somebody from modifying that expiry. Cookie expiry means almost nothing security-wise, just that the browser will delete the cookie at that point. Anybody who knows the name and value of that cookie can still use it, though. (Perhaps they pulled it out of a log months after the cookie expired; they can still set a cookie with that name and value.) You need to either track which cookies are valid server-side, or you need to include the expiry in the cookie and prevent it from being modified via some form of cryptographic integrity check, such as a digital signature or Message Authentication Code (MAC).

This is, incidentally, how JWTs work. A JWT has three parts. Two of them are data: the header (saying who issued the JWT and how long it's good for and so on) and the claims (saying who the bearer of that JWT is and what privileges they have, according to the issuer). The third part is the signature (which is often an HMAC, because they're usually shorter and cheaper to verify than public key signatures, although in some cases such signatures are more secure) which is based on a cryptographic hash of the other parts and prevents the data parts from being forged or modified without a cryptographic key that is kept secret. When you "verify" a JWT, you're performing a cryptographic operation to ensure that the JWT's signature is correct for the other parts, meaning it hasn't been tampered with.

You say "the cookie is typically the JWT itself", and that's true, but in this case "typically" obviously doesn't apply. If you're storing only part of the JWT - for example, everything except the signature - that's completely insecure; I can just forge a JWT for another user and send it to your server, and the server will think I'm that user who has authenticated and then been handed this truncated JWT as a cookie. Same deal if you're doing things like stripping off the JWT header for the cookie; the signature part is no longer valid, so you can't tell the difference between a legitimate cookie and one I made up (or edited to claim I'm some other user).

It sounds like what you're proposing doing is using the JWT from Cognito to authenticate / authorize the user, and then creating your own session token for subsequent use. This is basically how many single-sign-on (SSO) systems work; there's nothing wrong with the idea in general. However, it relies on you having a secure session token infrastructure.

There are, broadly speaking, two ways to do session tokens safely:

You issue a short-ish token (usually just a cryptographically random string) to every authenticated user, and also store the table of valid tokens (and what users they map to) server-side.

Advantage: the server always knows which tokens are valid; it can store expiry information where the user can't even see (much less edit) it and it can prematurely expire tokens (if the user logs out or requests to end other sessions).
Advantage: no long-term secret that an attacker could steal to be able to forge valid tokens.
Advantage: the only cryptographic operation is the random number generator that creates the tokens.
Disadvantage: if you run a cluster of servers, they all need to be able to check, constantly, whether the token is valid. This requires either a distributed memory cache, some tricky behavior where you bypass load-balancing to lock a user to one server, or a whole lot of database queries.
Verdict: simple, but doesn't scale well.

You create a token that contains the session details (user identity, authorization, session expiry, etc.) and use a secret cryptographic key to sign the token and prevent the user from modifying or forging it. This is how JWTs work.

Advantage: no server-side state at all. So long as every server knows the key needed to verify the tokens, the server doesn't need to remember anything about which sessions are active.
Advantage: a token can be issued by one server and used by another. They don't even need to be owned by the same entity, so long as the validating server trusts the issuing server. Asymmetric (public key) cryptography allows the issuing server to keep secret the "private key" required to create valid tokens, while any server with the corresponding "public key" can verify them.
Disadvantage: it's hard to expire a token early. There are ways to do it but they're messy and don't scale well either. Therefore, the tokens are usually short-lived, and are re-issued periodically (often via a "refresh token" of the first type, which is used rarely enough to not be a scalability problem).
Disadvantage: the signing key is the linchpin of the whole system. If an attacker obtains it, then the attacker can forge valid tokens and the server won't know the difference. Periodic rotation of the signing key can help, but even a very short compromise (the period between the signing key becoming known to the attacker, and it ceasing to be a trusted signing key) can be devastating.
Disadvantage: cryptography is hard to get right. Although this is a pretty simple cryptosystem, it's still got enough moving parts that there's a risk of somebody screwing it up. Also, there's a risk if, say, the cryptographic hash used to create the signature is broken, and somebody can create a different token body which produces the same hash. The work-around here is just to use a well-trusted implementation written and reviewed by people who know what they're doing, keep it up to date, and use modern cryptographic primitives (for example, the SHA2 or SHA3 family, rather than SHA or MD5).
Verdict: usable with every kind and scale of system, but harder to get right and more likely to fail catastrophically.

Looking just at the list of advantages and disadvantages, you might think the first approach is better, but it turns out that the scaling thing is a huge issue for many systems. The hybrid approach (short-lived type-2 access tokens plus session-lifetime type-1 refresh tokens that can be used to get a new access token) works well, at the cost of some additional complexity, but still doesn't remove the need for the signing key to be kept absolutely secret and the access tokens to be verified securely.