Is username and password needed to register and authenticate user in zero knowledge guillou quisquater?

Username and password is an authentication system where you would transmit the pair trough (encrypted) channel and use it to prove to the server that client is who it claims to be (knowledge of the password is the proof). In contrast, Zero Knowledge authentication protocols never transmit a password over the channel. They work on challenge-response scheme.

Since you are designing a zero knowledge solution based on Guillou Quisquater authentication protocol, having username and password will defeat the purpose. This would in turn answer your first question: no, you will not have username and password on the registration. The purpose of registration is to introduce the client to the server as a registered client. During registration, a user will provide some means for the server to verify the client in the future (authentication). In username and password authentication scheme, this would be the password. It would be later used to prove to the server that the client is the one who registered and the knowledge of the password is the proof of this. Registration in a zero knowledge authentication protocol would be a bit different.

On purely theoretical level, without going into details on any specific point, here are the steps needed to design such a scheme:

Registration

Client will generate public and private key pair
Client will present it's public key to the server (who also assumes trusted authority role)
Server will make the public key into a certificate and send it to client
Client is responsible for storing the certificate and private key corresponding to this certificate securely. Certificate is in turn the username and the private key would be the password even though it would never be transmitted over the wire.

Authentication

Client will present it's certificate to the server
Server will check the certificate and reject it if it is not valid (not issued by the server).
Taken directly from article you linked:

  Prover chooses random k ∈ Zn∗
  Prover sends verifier Cert(prover), γ = kb mod n
  Verifier checks certificate, rejecting if verTA(ID(prover) || v, s)≠true.

If check is successful, server will continue with the authentication scheme as you described in your question.

Answers to your questions

  When the user register, the scheme said that the server select 2
  primes p and q. Should I generate the 2 primes on each user
  registration? or should I generate the 2 prime numbers once and use
  those primes for every user?

These two numbers are not generated on user registration but on initial set up. You would generate them once and use them on every user registration.

  Is there any PHP library that can compute z = vr yb mod n fast?
  because it takes up to 3 minutes when computing this equation (I
  tested with p=337 and q=357)

You will need to ask this specific question on another SE, probably on stackoverflow.SE. You will also need to do mathematical (RSA) calculations on the client side and will need similar toolkit there. Even though all this is purely theoretical, please bear in mind doing cryptography in the browser is tricky at best. Also, you will need to solve the storage of the client credentials (certificate and private key) on the client side too. This is not trivial!

  In the registration scheme (the bold sentence), should I save the p
  and q value in the server database?

Since all of this is for your thesis, you need to decide the scope. If safe storage of these two numbers is out of scope, you can declare a database as a safe enough storage and save them there. The other extreme is to use HSM.


Parabolic Denial Of Service -- Would it work?

Yes, it works. it's often called a reflection DDoS attack. Variants include sending DNS queries off with the (spoofed) address of the target in them. That's a DNS reflection or DNS amplification attack. Vern Paxson wrote a paper about reflection attacks and possible defenses in 2001.

UPDATE

Cloudflare blog entry about DNS Amplification DDoS, and follow-up with details about how Cloudflare deals with such things..


I am always Hibernating my System, is there any risk for my Encrypted drive with BitLocker?

Using the old martial  art of  Google-Fu I managed to find these two comments on the first and second page after providing the search parameters: "Bitlocker hibernation".
From the Microsoft website:

What are the implications of using the sleep or hibernate power
management options? BitLocker on operating system drives in its
basic configuration (with a TPM but without advanced authentication)
provides additional security for the hibernate mode. However,
BitLocker provides greater security when it is configured to use an
advanced authentication mode (TPM+PIN, TPM+USB, or TPM+PIN+USB) with
the hibernate mode. This method is more secure because returning from
hibernation requires BitLocker authentication. As a best practice, we
recommend that sleep mode be disabled and that you use TPM+PIN for the
authentication method.

From the msdn website:

Use BitLocker Advanced Modes with Hibernation
Note: This is the
primary and most effective way to protect your system from DRAM
remanence and other platform attacks.
Platform attacks that access
encryption keys in DRAM obviously rely on those keys to be present in
DRAM.  As with all practical disk encryption approaches, these
encryption keys must exist in system memory in order to provide the
performance that makes disk encryption usable.
When BitLocker is
configured in its advanced modes, encryption keys are not loaded into
system memory until after the authorized user has provided credentials
like a PIN, dongle, or both.  An attacker without these credentials
will not be able to boot the system to a state where confidential
information – including encryption keys – are in DRAM.
There are some
caveats though; one is a very practical threat, the other less so. If
an attacker gains access to the system after the authorized user has
authenticated with their BitLocker credentials, but before its owner
turns it off or hibernates, the encryption keys are in DRAM and an
attacker could use one of the Princeton researchers’ ‘DRAM remanence’
attacks or other platform attacks such as direct memory access (DMA)
to gain access to those keys.
This is why it’s important when using
BitLocker’s advanced modes to use ‘hibernation’ rather than ‘sleep’.
To provide high-performance for sleep transitions, BitLocker does not
encrypt RAM contents nor does it require BitLocker re-authentication
when waking up from sleep. With hibernation, a system is effectively
‘off’, and keys will not be resident in physical memory (I’ll get to
the second caveat that discusses this shortly).  On resume from
hibernation, BitLocker will require the credentials I discussed
earlier, and without those credentials, encryption keys will not be
loaded into DRAM.
During design and implementation, the BitLocker
team worked with other teams within Microsoft to enable complete
control of system-suspend settings by local and domain administrators
through group policy. Instructions on how to configure this and other
BitLocker settings can be found in the design and deployment guides
available in BitLocker's online documentation.
Now let me address the
second caveat, which is less of a practical threat.  As described in
the Princeton researchers’ paper and elsewhere, DRAM may retain state
under normal temperatures for several seconds or a few minutes. If an
attacker gains access to a laptop within this window, they may be able
to access information located in DRAM. Again, the risk of an attacker
exploiting this is low relative to other platform threats.
Again, this
is the primary and most effective way to protect your system from DRAM
remanence and other platform attacks.


First, you need to understand that OpenID connect is built on top of OAuth 2. That is, you need to understand the differences of the Authorization server, the resource server, the client and the user.

In general the idea is:

a user wants to use a client application but he/she has to login first
the client application trusts an authorization server,
the authorization server knows the user, and asks him/her about the data he/she wants to share with the client application,
if you allow to share the data, the authorization server responds to the client application with an id_token
The client application now can verify the id_token and check the user information contained inside (such as user_id, first_name, last_name, etc.)
the client application now allows you to access (knowing who the user is)

The flow can be slightly different if you are using authorization code or implicit grant, but that should give you a rough idea.

If you are the one implementing the identity provider and/or authorization server then you must allow a client application to be able to register himself in your system. Usually this includes, name of the client and redirect urls to respond when the user clicked login.

hope it helps,


How to prevent getting locked out of gmail with a dynamic IP?

I would suggest you try using a device in which you are already authenticated. Such as a phone which is using your 3/4G network for example. Once accessing the Google account area you should be able to configure your security settings from their (i.e. correctly update your multi-factor authentication options)

Might be worth once access is gained taking a copy of the printable one time use access codes they offer. They are ideal for situations like the one you have.


Web application penetration testing resources?

Sans has a Web Penetration Testing and Ethical Hacking: Capture the Flag class you might be interested at

https://www.sans.org/security-training/web-penetration-testing-ethical-hacking-capture-flag-day-6-13632-cid

Another place to practice would be the sites listed at

http://captf.com/practice-ctf/


Store a file on a harddisk without root having access to it

Ye cannot defeat root !

The root user can have complete control of the machine. The best that you can hope for is encryption: use GnuPG to encrypt the data with a sufficiently strong random password, that, of course, you won't reveal to the root user.

However, as soon as you decrypt the file on the machine, wherever you put it, root will be able to see it. Similarly, root has all the required power to plant a keylogger (and thus grab your password) or modify the gpg binary so as to recover a copy of your precious data as soon as you encrypt or decrypt it. The best you can hope for is the following:

You may hope to "fly under the radar" by making your file inconspicuous, not to be detected through some massive scans that the administrator runs regularly. This requires that you delete the decrypted file as soon as possible; this assumes that root activity is indeed a nightly scan or something like that.

On a general basis, this concept is known as steganography.
You could encrypt and decrypt the file elsewhere, e.g. on your own laptop computer, using the machine-with-hostile-root only as storage space. That way, the root will only ever see the encrypted data, and not know the contents.


What are the side effects of recompiling OpenSSL with -DOPENSSL_NO_HEARTBEATS?

If you compilte OpenSSL with -DOPENSSL_NO_HEARTBEATS then you get an OpenSSL library and tools which can do anything that "normal" OpenSSL can do, except for the support of the SSL/TLS extension called "Heartbeat". That extension is described in RFC 6520. It is a pretty recent extension.

As with all extensions, its use in any given SSL connections is subject to a negotiation which occurs in the early steps of the handshake. Basically, the extension may be used only if the client claims that it supports it and wants to use it (in the ClientHello) and the server responds that it supports it and is OK with using it (in the ServerHello). If your SSL library was compiled without Heartbeat support, then it will not advertise Heartbeat support; if it is involved in a handshake where that extension appears, it will handle it as an "unknown extension", i.e. ignore it altogether.

Apart from that, your newly-compiled OpenSSL will behave just like the previous one, and things will work. What will break is if a specific application insists on using the Heartbeat extension: that extension will try to activate the extension and use it, and it will not work.

Looking at the OpenSSL source code, it appears that the SSL_heartbeat() function (used to send a "beat" by an Heartbeat-aware application) is a macro, which invokes the generic SSL_ctrl() function with some numeric parameters. This implies that if an application really wants to use that functionality, and you provide it with your no-heartbeat OpenSSL library, then there will be no link error; the code will run; but any beat-sending call will result in an error status. How the application will react depends on the application. In fact, from the application point of view, things will be as if the peer did not support Heartbeat.

Fortunately, this extension is very recent, and there must not be many application which are aware of Heartbeat, let alone use it. Chances are that your recompiled OpenSSL will not break anything at all, so the answer to your question is: yes, it is quite probably fine to recompile.


Does this Google Android Note4 activity look legit?

I can vouch that the activity is "normal" at least as "normal" as Google's hive mind panopticon can be.  I have a device running 6.0 and a device running 7.0 (they are unrooted Samsung with minimal apps and no sideloads or Knox triggers which pretty well assures that there's not anything malicious running) and they both also show the 3:00 a.m. activity similar to yours, not every day and not each type but both do show it a few times over the past week.


Diceware as a passphrase for online accounts

The reason why you need a strong password for an online service is in case their database is compromised, and the attacker gets hold of the password hashes. Then the attacker can indeed make a trillion attempts per second (if the hashing algorithm is weak and the attacker has good hardware) against your hash. A database compromise won’t necessarily also give the attacker complete access to the front-end servers and network to be able to capture actual passwords as they’re entered.


Why does my openssl connection fail with elliptic curve cipher ECDH-RSA-AES128-SHA?

That's because you are trying to use an ECDH cipher suite, and not and ECDHE cipher suite.

ECDHE-RSA: the server's certificate contains an RSA public key; the server generates on-the-fly a new elliptic curve Diffie-Hellman key pair, and signs the public part, that the server sends to the client.
ECDH-RSA: the server's certificate already contains an elliptic curve Diffie-Hellman public key; it is not generated on-the-fly; the Certificate Authority that issued (signed) the server's certificate used RSA.

Since your server's certificate contains a RSA key, you cannot use any "ECDH" cipher suite, only "ECHDE" cipher suites. (And that's fine ! ECDHE cipher suites actually provide Forward Secrecy, which is a good thing to have, and ECDH cipher suites don't do that.)


Is Browser based flows required for most IdP based Authentication standards?

The SSO protocols redirect the browser to the IdP because the browser must receive the WebSSO session cookie from the IdP's web server (same origin). Otherwise it would not be single sign-on and the user would have to type in the password for each application login.

There are two variants regarding the actual session data provided when redirecting the browser back to the application (service provider, short SP):
  - mostly older protocols only provide a one-time session-ID and the SP checks that against the IdP, optionally retrieving some more user attributes
  - newer protocols also include user attributes in a integrity-protected message (e.g. digitally signed) during redirect to SP


Is there a place where we can see which Microsoft's KB replaces which Microsoft's KB?

There used to be a file you could download, mssecure.xml which contained all this info. It was used by Microsoft Baseline Security Analyser 1, which is now long retired. Unfortunately, there is no replacement from Microsoft (info).

The information you need is contained in the Nessus plugins and you could probably write a script to parse them and summarise the info. Although doing that may be a violation of the Nessus license.


How self signed certificate works in https connection establishment

The certificate contains the public key.

How the certificate is carried depends of HTTPS/HTTP2.


My website redirects to an unknown website

additional, to what RyPeck said, you should check, if a .htaccess - file might be found in your docroot, containing malicious redirects (if so, the attacker has write-access to your docroot and your server is probably hacked)

is this url you mentioned (mywebsite.com/smth) a valid url for your site?
what are your running for a software? (eg wordpress, drupal'n'such)
is it static (html) or dynamic (php), is content loaded from a database?


I don't see anything obviously wrong with the rules.

Did you happen to capture your pcaps on either the attacking or target system?  If so, checksums may be incorrect.  As a quick test, run snort with the "-k none" flag to ignore checksums but the correct way to do it would be to use tcprewrite to fix tcp checksums (or some other utility to reach the same goal).

Thanks,

~Patrick


Alternatives to basic and digest authentication in HTTP when resources are constrained

A common use case for old systems with few resources was to use a login form that was the only page served as HTTPS. It is not as secure as a fully HTTPS service, but at least the password is only transmitted in encrypted format and only a hash is stored on server. And as only the login page is served in HTTPS the overload on the server is still low.

But this still forces to setup a SSL configuration on the server.


What happens when intermediate certificates are installed in the wrong order?

As per the SSL/TLS standard:

  This is a sequence (chain) of certificates.  The sender's
  certificate MUST come first in the list.  Each following
  certificate MUST directly certify the one preceding it.

What may happen depends on the client: some will simply disregard the chain and simply revalidate the server's certificate, using the provided certificate as an unordered bag of "potentially useful certificates". Others will reject the chain and refuse to connect. A sub-case is when the certificates are so out-of-order that the first certificate in the chain is not the server's actual certificate: in that case, clients who did not rejected the chain will try to use the wrong certificate, and this ought to trigger a "name mismatch" warning (i.e. the client is trying to use the certificate of an intermediate CA, and the CA name does not match the expected server name); and it would ultimately lead to a handshake failure since the CA public key is not the server's public key.

In any case, the SSL handshake ends with a pair of Finished messages which are used to check that everything went well. If the client does not use the correct public key, the key exchange will fail, or (at worst) the Finished messages won't match, and no application data will be sent or received. There will not be any "incorrectly encrypted request/response".


Let's start with eh two examples you gave:

Accessing a compromised website means you may be browsing malicious web pages. If your web browser is vulnerable and the attackers have modified the web pages to take advantage of that, you may be pwned.
Recently, we had an OpenSSH vulnerability that allowed an attacker to potentially steal your private key by using a "roaming" feature. Essentially, it lets a malicious server begin siphoning memory from your machine if you connect to it. If your client is vulnerable to this you may be pwned.

More info on the roaming vulnerability in OpenSSH


Storing third party auth info; Is this secure?

It's hard to tell from how you worded it, but it sounds like there may be a few areas that can be improved.  You don't want they key to be derived from some hashed version of the password, but rather want to use a secure key derivation function to derive an encryption key for the user's keyring.

Derived keys have limited security, so you want to limit how much you encrypt with the derived key.  My recommendation is to produce a truly random encryption key to use for the user's e-mail credentials.  That key (symmetric) is then encrypted with the derived key from the user's password and stored in the database.  When the user logs in, their password should be used to determine their derived key and the data key should be decrypted and stored in the user's session.  When the user needs to access the e-mail configuration, the key is available to be used for decryption, however as soon as the session ends, the credentials will be cleared from memory and be unavailable until the user re-enters their password.

The use of a separate key for encrypting the e-mail credentials also means that you can use asymmetric cryptography to encrypt the configuration key so that it can be used by a separate server for sending e-mails when the user is offline (if you end up needing that feature).  Since this e-mail server could be isolated from input from the outside world, it would have a much higher degree of security and the private key wouldn't be available to the outside world so it would be very difficult to compromise the account details.


System image that does not allow for recovery of deleted files?

An image created with the dd command would allow for recovery of deleted files.
A bit-for-bit copy (dd style) is the only way you'll get something that is likely the only forensically useful approach for law enforcement / court.

While there are ways to compact all the files on a system and copy over / update the boot record, this is not forensic. The only valid forensic approach is to copy everything exactly as it is and preserve that. You may be able to copy everything and then zero out all unallocated space (freespace wipe), but that might limit your ability to use it for anything other than trying to find out what happened. Even then it will limit your ability to discover certain types of attacks.

If your goal is to seek criminal or civil action, you have an uphill battle to show that any kind of modification to the system state is appropriate for evidence in any jurisdiction. From an expert witnesses position for the opposing side, I'd rain hell all over it. This is akin to cleaning the walls before investigating a murder scene.


What are the requirements to sniff UDP packets in a Wireless Ad-Hoc network?

Why are you using iptables rather than using good old Wireshark which is specifically made for this? Wireshark is a free and open-source packet analyzer and the ideal tool for performing these types of analysis.

EDIT

If you need to reinject the packets I would have a look at scapy in python.


Is it possible to locate a cellphone's location just by ringing it?

The phone does not need to be rung or even on in some cases.  (This is why in some secure facilities, the battery is removed from uncertified phones.)  Phones are constantly in communication with their local radio towers when on and some will even periodically poll when off.  It is also possible for commands to be remote issued to the radio's on the phones to gather additional information.

At a minimum, the radio towers that it communicates with are known as is the relative signal strength which gives a rough approximation.  In some cases, it may even be possible to get a GPS location depending on how things are implemented in the phone's radio.


SQL - using String concatenation, how can I exploit this procedure?

where JobTitle like '%' + @str +'%'

This is not an SQL-injection vulnerability. It isn't injecting content into the query from a higher level of control such as a string EXEC or a call from C#.

There is an injection error here, however it is not SQL-injection. The concatenation that is being done is a search term into a LIKE query pattern. Metacharacters in LIKE patterns are %, _ and, in SQL Server, [ (non-ANSI-standard).

The upshot of this is that if anyone does a search for, say, 50%, they will get results that contain the substring 50 and not only ones that contain 50%. Use of [ can also probably result in a syntax error. That's undesirable, but it doesn't allow any of the traditional security attacks that SQL injections do.

To fix LIKE-injections, you need to nominate a custom LIKE-escape character, and use it to replace any LIKE-metacharacters, eg:

SET @liketerm = REPLACE(REPLACE(REPLACE(REPLACE(@str, '!', '!!'), '%', '!%'), '_', '!_'), '[', '![');

... WHERE jobtitle LIKE '%'+@liketerm+'%' ESCAPE '!';


Convert a DER encoded Certificate to PEM encoded Certificate

Your .p7b file is probably a PKCS#7 encoded certificate chain.

For Java code to pull a single public key from that file, see Extracting individual .cer certificate from a .p7b file in java.

To use keytool to import one or more of the public keys, try Import PKCS7 (Chained Certificate) using KeyTool command to JKS. As noted, you might have to separate the public keys into individual files and just loop through them.


How to see whether the pcap contains RTP traffic?

Some Issues to consider

Are you sure that you captured all the traffic on the network interface ?
Are you running the latest version of Wireshark ?
Are you sure you didn't try to decode SIP traffic as RTP traffic ?

My advice would be to download some pcaps that contain known RTP traffic from Pcapr ie the following PCAP SIP PCAP . Once your more comfortable with what RTP traffic should look like, you will have a better chance of spotting it on your own network.

note I have no connection with pcapr


Cable modem/router hidden internal ISP network?

The IP addresses beginning with 172.21 are in the "172.16/12" block, reserved for private networks by RFC 1918. It is plausible that:

The routers from the ISP are indeed part of an ISP-maintained private network.
The ISP uses that private network to talk to the routers, e.g. to reboot or configure them remotely.
The routers are configured not to route packets between that private network and the rest of the world, including the Internet, and the local network on the customer side (the 192.168.*.*). This is not surprising, since that network is supposed to be private.

How exactly the router prevents packet exchanges between the ISP network (172.21) and the local network (192.168) is an open question. It is possible that the router is very basic in that respect. Most such routers run on a Unix-like OS, often a VxWorks or Linux derivative. Let's suppose a Linux. Linux maintains a routing table, which would tell him something like:

There is a local network with IP addresses 172.21.X.Y/21 on interface eth0; when a packet is for such an address, send it on eth0.
There is a local network with IP addresses 192.168.1.Z/24 on interface eth1.

(Use netstat -rn on a Linux machine to see that table.)

If you configure your PC to assume a 172.21.U.V address, but still connected on eth1, then you may bring an ICMP request targeted to another 172.21.X.Y address to the attention of the router; but even if the router accepts to forward it to the target machine, and the target machine responds, the response will be for 172.21.U.V, and the router won't re-emit it, or only on eth0, so you would not see it. This is why configure your PC with an internal address will not allow you to see anything in that respect.

Similarly, if you keep your machine with its 192.168.1.Z address, and send your ping request from that, then the router will see it, and possibly forward it on the 172.21.X.Y network. But then, the response will be sent to 192.168.1.Z as seen from the target machine, which will not be your machine, but possibly a machine on the internal network of another client. Or maybe it will go to the default gateway of that target machine, i.e. to the Internet. The Internet does not know that 192.168.1.Z is in your home, so you will not see the response anyway.

If you reflash your router with something like DD-WRT, then you might be able to access that network, except if the reflashing destroyed some credentials which the router was using to connect to the ISP network in the first place. You may have better luck if you find an exploitable hole in the router, allowing you to hijack it without rebooting it: in that case, it seems highly plausible that this would give you network access to all other systems on this private network, including (probably) the routers of other customers. At that point, risks depend a lot on how the ISP people authenticate themselves with the routers when they want to run administrative things (e.g. firmware updates). Right now you have zero information on the subject. For an attacker, using this private network may be useful in that a target home router (the one in the home of someone else) is nominally accessible from the Internet but through the ISP firewalls, and the private network might allow for working around the said firewalls.

A noteworthy point is that your router sees a netmask of 255.255.248.0 on that 172.21.X.Y network: that's room for about 2000 IP addresses at most. So this private network is probably used for only a small subset of the cable routers from that ISP.


Debating between architecture options for offline updating of Linux machines in a vertically segregated network

My personal vote is that those are pretty much equivalent. Presumably in both cases only the ubuntu mirror host is allowed to reach out, and only to the official mirror site. Whether the B mirror is allowed to reach out directly, or has to proxy off the cache in A seems like splitting hairs. Either way it's getting the same cryptographically signed data from the same source.

I feel like you almost certainly have better things to spend your time locking down than this -- how's your VPN setup? Have you manually verified the GPG keys in APT? Are there packages / services on those machines that don't actually need to be there? etc.


Can I use the same ssl cert to protect my web site and sign my app?

No.

The long version follows. I simplified a few things, so don't take every single statement as gospel, but the basic principles are correct.

You can't use the same certificate. You may be technically able to use the same private key, but it won't make your life easier and it would be bad for security.

From a technical point of view, the operations involved in securing a TLS connection and in signing some code for distribution are the same. Your server stores a private key, which nobody else knows. The server uses this private key to sign a {TLS connection handshake message}/{zip file containing your code}. Anybody who receives the signed data can verify that it was signed by someone who knows the private key corresponding to a certain public key K.

They know that the holder of the private key corresponding to K has signed something, but this is not useful unless they also know that you are the holder of this key. A certificate authority issues you a certificate, which says: ”I, undersigned, certificate authority, guarantee that raddevus.com is the holder of the private key corresponding to K“. Only, they say it in math and X.509 rather than in legalese. All this business of saying (in cryptographic language) who someone else is is called a public key infrastructure (PKI).

In addition to establishing a link between "raddevus.com" and K, the certificate states a number of restrictions on its usage. A certificate without restrictions could be dangerous. For example, this certificate doesn't allow you to, in turn, say, “I, undersigned, guarantee that google.com is the holder of the private key corresponding to K”. Well, you can say it, but browsers won't believe you, because your certificate doesn't allow you to make such claims. In technical terms, your certificate doesn't allow you to be a certificate authority. Your browser trusts the certificate authority when it claims that you are raddevus.com because its own certificate says that it's allowed to make such claims, and the reason it can get such a certificate is that it's satisfied the the certificate authority authorities. And your browser has a built-in list of certificate authority authorities that it's willing to accept.

You can look at what's inside a certificate to get a feeling. Modern browsers have an interface for this. In Chrome, open the developer tools and go to the “Security” tab. In Firefox, click on the padlock icon in your browser and follow the directions, e.g. click the padlock then “> (Follow connection details)” then “More Information” in Firefox. Navigate to the certificate details. Let's take https://www.smarterasp.net/ as an example; some highlights are:

The “Subject” field lists *.smarterasp.net. This is the website(s) that the certificate is valid for. If the website responded to requests for https://notsmartasp.example.com/ using this certificate, a browser would close the connection because the certificate is not valid for that host name.
The “Certificate Subject Alt Name” field also lists *.smarterasp.net, and smarterasp.net. This is the modern way of defining names, not supported by antique browsers.
The “Certificate Basic Constraints” field states “not a certificate authority”. It also says “Critical”, that only means that an application that doesn't understand what a “Certificate Key Usage” is should treat the certificate as invalid; “Not Critical” would tell such an application to ignore the field.
The “Certificate Key Usage” states “Signing” and “Key Encipherment”. If the server tried to use the key for something else, applications that use the certificate to verify something should reject it.
The “Extended Key Usage” states “TLS Web Server Authentication” and “TLS Web Client Authentication”. (These are the English translations of the ASN.1 OID 1.3.6.1.5.5.7.3.1.) This is more precise than “Signing” from the other key usage field.
Up above, the “Certificate Hierarchy” shows the chain from the trusted-by-your-browser certificate authority authority, down to the CA and the website.

If you want to sign some code, you need a certificate whose extended key usage includes the OID 1.3.6.1.5.5.7.3.3, which in English is known as “Code Signing”. To do this, follow the steps described in Microsoft's documentation. If you want to know more about how these tools work (I guess you do, or you wouldn't be reading this), read the old instructions. Note that the documentation mentions the requisite extended key usage (they call it “enhanced key usage”, but it's the same thing). The documentation also mentions a few other constraints on the certificate.

If you want to go further and establish the link between that certificate and raddevus.com, you need to get it signed in the Microsoft application distribution PKI, rather than in the TLS PKI. I'm not familiar with this PKI, I don't know how you get into it. I think it involves going through an application store.

While you may in theory use the same private key and generate different certificates from it, one for the web and one for code signing, it would be more work converting between formats than generating two keys. And using the same key would be a bad idea for security. Your web server's private key has to be on the web server because it is needed on each connection (to authenticate the website to the browser). On the other hand, your application signing key only needs to be used when you deploy a new release version of your application. If your server gets breached, you need to revoke its key, get a new one, and people attempting to visit your website and being attacked by a man-in-the-middle (who redirects connections that should go to your site, to their own site) will suffer. If your code signing key is compromised, then until people receive the revocation information, they will be at risk whenever they receive an application package signed with your key; that attack (distributing a dodgy executable) is rather easier to arrange than a man-in-the-middle. So you really should protect your code signing key better than your website authentication key.

Note that you can get a website .


The word size can be 16, 32, or 64 bits, and it determines the block size.  "The algorithm assumes that the input block is given in two w-bit registers A and B..."  This allows for optimization based on the target architecture.

Reference: The RC5 Encryption Algorithm (PDF)


Can employer see home network usage on personal device

First of all, monitoring your personal usage, on your personal network seems highly illegal (IANAL). So there's that, your employer is unlikely to spy this way.

Then, monitoring your home network is possible in a variety of ways when having an other device on it, but not everything would show : only your DNS queries (say, you went to facebook.com or google.com), but then since most of the web is moving to HTTPS, what happens between your computer and the remote website can't be read, so no reading your queries to Google or your Facebook posts. Also, since the computer can't really know easily if it is on your home network, or say a government building wifi, the legal ramifications are big, and your employer would probably not risk it.

I can't say for sure when using your phone. If it is a VPN app, that routes all your traffic through your employers network, then it is possible to check what websites you went to, not necessarily what you did there (HTTPS again), and so on. Again, this seems highly unlikely, and potentially illegal.

In short, using an untrusted device is almost always "game-over", but you have to estimate your threat model. If your "adversary" has more to lose than to gain, he is unlikely to "attack" you. So I'd say you're fine, unless you signed some charter explicitely barring you from using your phone in such way.

Edit: typo


You can't really go wrong with the PCI Security Standards Council document library:

PCI SSC document library

The standard itself is thorough and contains plenty of guidance for each of the controls.

There are also a handful of other specific guidance documents, for example currently the list includes cloud computing guidance, guide to risk assessment etc.

Your relevant SAQ could form the basis of a quick reference.


How can I stop fraudulent credit card submissions on a donation site?

According to prowebscraper.com cracking 1.000 reCaptcha's costs around $2 so it is just factored into the business case of the fraudsters.
Your only chance is to make your site less attractive than other websites, e.g. by requiring a registration and e-mail activation for visitors from outside your region and limiting the amount of times an account and IP-adres can be used each day


DAB+ (Digital audio broadcasting) privacy

DAB+ is a one-way signal transmission. A big, high-powered sender sends data encoded according to the standard, and the small, low-powered receiver receives the data, decodes it and plays the audio stream back.

Does that mean my radio is 100% private?

Most likely, yes. The DAB+ standard describes no signal sent from the radio and received by the base station.

This does not mean that there could not be a "smart radio" that transmits somewhere what you are listening to. It just means that it's not part of the standard.

So if you wish to remain as private as possible with your choice of radio station, don't buy a "smart" radio.


Why do I need an own certificate to encrypt a S/MIME message?

When a sender uses Thunderbird to send an S/MIME encrypted message to a recipient, Thunderbird requires the sender's certificate in addition to the recipient's certificate, so that Thunderbird can send the sender's certificate along with the message to the recipient.  This is done for two reasons:

1)  So that the recipient can verify the sender's digital signature on the message, which is made using the sender's private key that corresponds with the sender's public key in the sender's certificate.

2)  So that the recipient can reply with an encrypted message back to the sender.


Android / CyanogenMod encryption vs GNU/Linux

Android implements the device encryption in a module of Vold (Volume Daemon) called cryptfs that makes the calls to the kernel which actually encrypt the device. When a user encrypts the device, Vold reboots the device and begins encrypting the data partition. During the encryption process Vold disables everything that is not a core service on the device. Android requires that the user create a passcode if they have not already set one at the beginning of the encryption process, which is one of the criticisms of the implementation since the decryption process is tied to the users screen unlock passcode which isn't super complex. Once the device is encrypted, according to the documentation at the AOSP page, the encrypted master key is stored in the footer of the data partition. As far as I know Android's implementation only encrypts the data partition, which would be user and app data. Once the device is encrypted the user will have to enter their passcode whenever the phone is locked. Before they can access their data, the kernel mounts a tmpfs/data that reads from the actually encrypted block devices. Your screen unlock passcode hashed and used to decrypt the master key. This is the description on the Notes on the encryption implementation.

  The crypto footer contains details on the type of encryption, and an encrypted copy of the master key to decrypt the filesystem. The master key is a 128 bit number created by reading from /dev/urandom. It is encrypted with a hash of the user password created with the PBKDF2 function from the SSL library. The footer also contains a random salt (also read from /dev/urandom) used to add entropy to the hash from PBKDF2, and prevent rainbow table attacks on the password. Also, the flag CRYPT_ENCRYPTION_IN_PROGRESS is set in the crypto footer to detect failure to complete the encryption process. See the file cryptfs.h for details on the crypto footer layout. The crypto footer is kept in the last 16 Kbytes of the partition, and the /data filesystem cannot extend into that part of the partition.

Once the device is encrypted, the only way to undo it is to wipe data. I don't think that the default implementation you get in the AOSP source encrypts the SD card since not all android devices have a removable card, like the Galaxy Nexus, but I guess device manufacturers could add support in for that. The AOSP documentation on the FDE implementation is available here, Android Notes on Encryption Implementation. It's pretty thorough compared to some of the other AOSP docs. You might be interested to check out this blog post, Cold-boot encryption key recovery on an Android phone that has some information on attempting key recovery with CyanogenMod7.

His conclusions were:

  The key is fully recoverable if the phone reboots itself. It may be recoverable if the soft reset keychord is used. It may be partially recoverable if rebooted by power-pull (there may be an error in the experiments here.) It appears to not be recoverable if the phone powers itself off. Variables such as rebooting directly to fastboot or doing a normal reboot while holding the fastboot key, or leaving it connected to USB or not, appear to be irrelevant.

But he was running CyanogenMod7 so I don't know if that is generally applicable to stock ROMs on devices or ROMs built straight from AOSP, but maybe there is some more information and research out there about the potential for key recovery.

Hope this helps some.


Staying anonymous vs a Five Eyes adversary?

If you really have sensitive information to transmit, seems to me that learning PGP is a must-do.
when Edward Snowden contacted journalists he actually had to train them to PGP in order to establish a secure channel for further correspondence.
I am talking about end to end encryption here, not relying on some third party like Protonmail to encrypt your original plain text materials.
Even if the person is not under targeted surveillance, the intelligence agencies tap into Internet traffic and sniffing keywords off plain E-mail for data mining purposes is routine for them. There is a chance that your correspondence will trigger some alarm, depending on the keywords. Anyway, E-mail is mostly in the clear unlike web traffic. In short E-mail is not a good way to send sensitive/confidential information.
It is perfectly plausible that your E-mail could be reviewed by an analyst at some 3-letter agency before the intended recipient actually reads it.
Obviously using PGP is a sign that both parties "have something to hide" or just take their privacy seriously, and that can attract further scrutiny. But with proper opsec on both ends nosy governments should not be able to figure out the contents of the mails. What you don't want is Big Brother being alerted and terminating the conversation before you've had a chance to deliver your message.
Tails should be sufficient for your purpose, using a public wifi connection, preferably in a place where there are no cameras and no footage of your presence.
Note that Tails will spoof your MAC addresses, so in theory it cannot be proven that your laptop was even used on a given wifi hotspot, provided that the connection can actually traced back to the place of origin.
The critical part in this setup is that when your correspondent sends you their public PGP key, you have to trust that it is really theirs and not that of a man in the middle. But if it comes to that your correspondent is already compromised.


Does sending email with TLS help to not being flaged as spam?

There are two sides of sending email encrypted via TLS:

Between the sender and the email provider
Between the email provider of the sender and the receiver's email provider (spam filters typically sit here)

The security of the first connection has no impact on the spam rating on the receiver's side.

However, the spam filter on the receiver side might consider the encryption of the inbound connection in his spam rating or even completely deny unencrypted emails.

As tlng05 mentions in his comment, commercial email providers typically don't talk about how their spam filters work in detail. However, as Gmail (just as an example) marks every email that came in through an unencrypted connection with a red lock, it is quite save to assume that encryption has at least a little impact on the spam score - if not technically, then psychologically (at least for Gmail users).


Does a malware in an android phone have permission to read/modify/delete data of all the apps?

Most android malware will steal information or spam your phone with aggressive ads. But they do not necessarily modify any installed apps on the phone. If a phone is rooted, the malware can, however, uninstall apps and replace them with malicious app copies. The following link gives an overview of many of the known android malware capabilities.

http://forensics.spreitzenbarth.de/android-malware/


Has networking using multiple "unrelated" connections to share an encrypted data stream been researched?

The network technique of establishing single logical connections over multiple links is called inverse multiplexing. Channel bonding and VCAT are specific examples of inverse multiplexing. It's been use for a long time for various reasons.

Generally, I've seen inverse multiplexing used as a performance or operational enhancement, not as a security tool.


Have there been any case studies on intentional vulnerabilities or malware in open source projects?

Though your question is well formed and specific, the answers to them do tend to border on the 'generating discussion' side of things. I'm going to try and answer you as directly as possible.

  Successful malicious contributions to prevalent open source software

There does not appear to be much at all in the way of documented evidence of this. Surely it has happened, but due to the very nature of OpenSource, where anyone with any amount of knowledge can submit a request to update the codebase there will always be the question of whether something that ends up being malicious was intentional or simply a mistake. The Heartbleed vulnerability in OpenSSL went unnoticed for 2 years, but was ultimately reported as a slip up by the user who uploaded the change and the admin that approved it.

  Reports of foul play on attempted contributions

Back in 2003, there was an attempt by an unknown attacker to force a backdoor into the Linux kernel. They exploited the source-control practices at the time to insert the code directly into a secondary code repository rather than attempt to try and submit the code for peer review.

Because absolutely anyone can request a change to OpenSource code, there are going to be a huge amount of foul-play cases - Except all of the drama and reports of this happening will be within the message-boards and other communities for that software. The sort that you are looking for - news-worthy reported cases are much less likely. If the application is big enough to report on, then there tends to be plenty of approval steps in place to review the code first.

The bigger the application becomes the more 'potential' eyes on the code becomes. As a hacker, if you submit malicious code into a peer-review-based source-control such as Github, your going all-in and saying 'I hope you aren't reviewing this thoroughly, because I'm trying to do something nasty'. It would be much safer and less likely for you to be caught out (immediately, anyway) to try and get your malicious code out in other ways that aren't going to be audited such as a Man-in-the-Middle attack deploying a modified version of the application out to someone trying to download it. You would have greater control over the entire code-base and thus be able to hide your intentions all the better and - as you suggested yourself - very eager developers and users are much less likely to compare the digital signatures of what they are downloading than the app rovers who are the party that are the most-invested in the security of the code.

TL;DR - As an attacker, it's more reliable to push malicious code to an over-eager end-user than hoping that the admins who are passionate about their product aren't on the ball.


What means that the same ciphersuite is both enabled and disabled in Java JSSE?

The duplicate lines must be an editting or perhaps text-generation glitch of some kind, because in that format the ciphersuite should be a unique key. There are also four lines for TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 -- all wrong!

You aren't specific, and I certainly see some other errors in the page you link, but differences about JSSE across different JDK versions could be correct. In particular:

Java 6 JSSE supported some suites using EC (Elliptic Curve) algorithms, though not the one you name, and they were even enabled in the sense of being in JSSE's 'enabledCiphers' list. But they were actually used in the protocol only if the JVM included a cryptoprovider with EC (including ECDH and ECDSA) primitives, as described in the note above table 4-11 on the page you link, and Sun-then-Oracle j6 did not include such a provider out of the box, but it could be added, and other builds could be different (which was a major point of the JCA design way back to its beginning).

Java 7 JSSE implemented TLS 1.1 and 1.2, which adds some additional suites including the one you name (since it uses AES-CBC and SHA384); by default it enabled these protocols (and thus this suite) only on server side not client side, but this could be overridden. Oracle j7 added an EC provider (SunEC) so that 'enabled' EC suites could actually be used; again other builds could differ. (RedHat OpenJDK in particular removed EC for several years.) However the free Oracle versions of j7 (like j6 and earlier) were subject to the 'limited crypto policy' restrictions originally created to satisfy arms export regulations in the 1990s, which primarily disabled all AES-256 suites by default; this could be fixed by downloading and installing the 'unlimited jurisdiction crypto policy' jars, about which you can find many stackexchange Qs dating from before 2018. The then-separate OpenJDK releases did not have the limited-crypto restrictions, and I believe some of the Oracle paid-support versions (after 7u80 in 2015) also changed this, but I don't pay for support.

Java 8 added some more TLS1.2 suites (using AES-GCM), and enabled TLS1.2 (and thus the SHA384 suite you name) on client by default. Starting with 8u151 in late 2017, it also removed the limited-crypto restriction so that AES-256 is enabled without an additional download.

Java 9 and 10 started out with TLS1.2 enabled and no limited-crypto, and did not make significant changes in this area TTBOMK. Java 11 adds TLS1.3, which radically changes the whole concept of ciphersuites; instead of specifying the whole range of keyexchange, server auth, cipher and MAC and PRF, they now specify only cipher-and-MAC (always combined because now only AEAD ciphers are allowed) and PRF.

RC4 used to be trusted, and suites using it enabled; for a while during BEAST in 2011 they were even recommended. But advances in cryptanalysis made them insecure and they were officially forbidden by rfc7465 in 2015. This just missed the last free release of Oracle j7 (7u80) but to my understanding later paid-support Oracle versions, and OpenJDK versions, did disable RC4. Java 8 (IINM both Oracle and OpenJDK) disabled it starting with 8u51, and 9 10 11 from their first releases.

Similarly SSLv3 was badly broken by POODLE in 2014, and thus disabled in 7 from 7u75, 8 from 8u31, and 9 10 11 from outset. (SSLv2 is not a security issue; the pseudoprotocol SSLv2Hello implemented by JSSE is not actual SSLv2 and JSSE has never implemented actual SSLv2. However, SSLv2Hello was a good idea only in the early 2000s when there were still v2 servers in the wild; nowadays it it is not needed and should not be used because it restricts features that use hello extensions like SNI and sigalgs, which are now more and more important.)

If there are any inconsistencies that does not explain, please feel free to ask a more specific question.

PS: note that Oracle 9 and 10 are officially no longer supported, because they were not designated 'long-term' under the new model and 11 has now been out for several months. And Oracle 8 similarly is now officially paid-support-only for commercial. But they still actually work, and of course the source is still available so open-source builds are not affected.


Network Access Control for Wireless Network

There is no such feature included in the operating system for sure. Your idea is also not really practicable for a variety of reasons. First of all you would need a secured data channel which is available all the time to give you the possibility to communicate with these laptops (which you don't have) and you would also need to be approachable 24/7 which you will likely not be.

You can whitelist and blacklist specific WLANs by group policy as described in this article. The problem there is that it relies on the SSID (The Name) of the given wireless network which is by no means unique or reliable.


How can I protect my data/privacy against rule 41

This answer covers only the recent changes to Rule 41, which I assume from your links is what you are asking about. It also assumes you and/or your equipment is in the US; if you're a non-citizen and you and your equipment are outside the US, the 4th Amendment rights that are clarified by Rule 41 wouldn't apply to you anyway

The changes primarily affect the (geographic) scope of what law enforcement is legally allowed to search with a warrant. So it's worth pointing out that you're asking for information on how to prevent agents of the government from legally obtaining information from your system that they have been explicitly (via a warrant) been given permission to have.

From a technical perspective, there's no difference between

a) what law enforcement from within your jurisdiction is allowed to do (and has been allowed to do) regardless of Rule 41 changes,
b) what law enforcement from a different jurisdiction is now allowed to do under Rule 41, and
c) what criminals can do outside the law to hack your computer.

So from a technical perspective, this question is just, "how do I secure my computer from access by people who were not personally authorized by me to access it," and the Rule 41 part of your question is irrelevant.

Finally, it's probably worth noting that the changes to Rule 41 include allowing a judge from outside your jurisdiction to issue a warrant if "the district where the media or information is located has been concealed through technological means," so using Tor would actually bring you into the scope of the Rule 41 changes; if you don't hack (damage) someone else's computer and don't try to hide your location then you are not affected by the changes to Rule 41.


You need to read the Talos blog about the vulnerability and the source code.

mcc is an internal reference to Multiple Component Collection (line 1040).

A Multiple Component Transformation is a colour transform for images in JPEG2000.

This is not something you can edit in metadata. It's about how you craft the image itself to create an index reference error when it tries to process the colours.

Please make sure you read the CVEs for the vulnerabilities that you come across, and read the source code and bug reports so that you can understand the context for the issues.


How many times does a DNS server need to sign?

The DNS server is free to do it as often as it wants/needs: signatures liftetime is a policy issue, covered by a DPS (DNSSEC Policy Statement). You can find examples and good practices, but if a server wants to create signatures even on the fly, it can (see https://doc.powerdns.com/authoritative/dnssec/modes-of-operation.html "In PowerDNS live signing mode, signatures, as served through RRSIG records, are calculated on the fly, and heavily cached." or https://www.cloudflare.com/dns/dnssec/dnssec-complexities-and-considerations/ "Cloudflare’s DNSSEC implementation leverages ECDSA’s efficient signature generation to sign DNSSEC records on-the-fly.")

Signatures in RRSIG records have two dates: a beginning of validity and an end.

This has nothing to do with the TTL value, nor the zone changes (signatures will change even if the zone does not change).

See for example in A Framework for DNSSEC Policies and DNSSEC Practice Statements section 4.6.5. "Signature Lifetime and Re-Signing Frequency" that mandates a good policy document to have:

  This subcomponent describes the life cycle of the Resource Record
     Signature (RRSIG) record.

Now let us look at some published DPS:

.BE

  17.6 Signature Life-time and Resigning Frequency:
  The KSK signatures of the TLD zone DNSKEY RRset will have a validity period of 40 days.
  The ZSK signatures of the TLD zone authoritative data will have a validity period of 10 days

(default TTL: 86400s aka 1 day)

RIPE NCC

  We re-sign our zones daily with a signature lifetime of 30 days.

(default TTL: 3600s aka 1 hour)

.NL

  RR sets are signed with ZSKs with a validity period of fourteen days and are resigned every two days.
  Zone file generation and the signing of new records takes place every hour.

(default TTL: 3600s)

.COM

  The signing practice of the COM Zone is divided into quarterly continuous time cycles of approximately 90 days. Time cycles begin at the following dates each year:
  January 15th
  April 15th
  July 15th
  October 15th

  The time cycle will never be less than 90 days, except in emergency situations (in which a key has been compromised) or if Verisign decides to begin using different key lengths.

(default TTL: 172800s aka 2 days)

etc.

Also, take into account this part from RFC 4035 (section 5.3.3):

If the resolver accepts the RRset as authentic, the validator MUST
   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
   a value no greater than the minimum of:

   o  the RRset's TTL as received in the response;

   o  the RRSIG RR's TTL as received in the response;

   o  the value in the RRSIG RR's Original TTL field; and

   o  the difference of the RRSIG RR's Signature Expiration time and the
      current time.


What are private key cryptography and public key cryptography, and where are they useful?

Wikipedia has a good article on public/private-key cryptography. To summarize public/private-key cryptography is one concept, not two. The alternative to public/private-key cryptography is using symmetric cryptography which has one key per pair of communication partner.

In asymmetric cryptography a person/computer has a keypair. One key is kept secret and called private key. The other one is given to communication partners. Anything that is encrypted using the public key can only be decrypted using the matching private key.

Symmetric cryptography is a lot simpler and more performant, but it does not scale to a large number of communication partners (10 people need 45 keys for each one to talk securely to every one else).

So as a result both systems are often used in conjunction in the real world: The actual data is encrypted using a symmetric session key, which is only valid for one session. This key (or some information from which it can be derived) is transmitted using public/private-key cryptography at the beginning of the session.

Encryption

Anything that is encrypted using a public key can only be decrypted by using the private key.

The most common example is HTTPS. When you connect to an HTTPS server, it will send you a certificate. A certificate is just a public key with some identity information attached to it. Using this public key the browser can send information to the server that only the server can decrypt, using its private key. Building up on that, a symmetric session key is negotiated between the browser and the server, which is used to encrypt the traffic.

Signatures

Using a private key information can be signed and this signature can be verified by using the public key. The most common use case is to sign certificate to tell the world that you trust that certificate to contain correct identity information. There is a number of certification authorities out there which are by default trusted by the common browsers.

Other use cases

Public/Private key cryptography can be used for many different things. The standard example is email, but this is not really widespread because it's too complicated for average computer users. Smartcards are a better example: They store the private key and have a little processor that can do the encryption and signing. So the private key never leaves the device.


How can I use many LiveIDs (or Microsoft Accounts) at the same time?

Internet Explorer (IE8 or IE9 or newer)

Internet Explorer 8 (IE8) and newer version comes with a New Session option that allows user to start a new browser window as new session, which has separate cookies management system.

To open a new IE browser window in new session, press “Alt” key to reveal menu bar, and go to “File” -> “New Session”.

Users who prefer to run each IE browser from Start Menu, Taskbar or Desktop as new session automatically can append NoMerge switch to the end of IE’s shortcut.

IE InPrivate Browsing

In IE which supports InPrivate Browsing, click on “Safety”, and select “InPrivate Browsing” to open a new privacy browser window to login to second account. Note that the browsing history, cookies and session won’t be saved while using this option.

Mozilla Firefox

There are a few add-ons for Firefox which can be used to maintain different cookie storage for different tabs or windows, allowing separate instance of cookies to be created for each logins in different tabs or windows in parallel.

Install Multifox extension for Firefox
Install CookiePie extension for Firefox (no more supported and may conflict with some extensions)
Install IE Tab add-on for Firefox (provided IE is not in use to login)

To use CookiePie, open a new tab, and then right click on the tab to “Toggle On/Off CookiePie” (a cookie icon on the tab mean it’s on). To use Multifox, right click on the links or bookmarks and select “Open in a New Identity Profile” in the context menu, or select “New Identity Profile” in “File” menu.

Google Chrome

In Google Chrome, click on Tools (Wrench) icon, and select “New Incognito Window” (or press Ctrl+Shift+N), and sign onto the second account of the same site.

Chrome Incognito mode is a privacy feature which allows creation of two different instances of cookies, effectively treat Chrome Incognito mode as multi-login feature. Note that the browsing history, cookies and session won’t be saved while using this option.

Web Browser Profiles

Firefox and Google Chrome supports multiple profiles creation which allows web browser to start with different profile with different storage location of information, including cookies which stores the sign in credentials.

Guide on using profiles in Firefox is available at mozilla.com.
Guide on using profiles in Chrome is available at google.com.

Stainless Web Browser

Mac OS X operating system users can use Stainless web browser instead. Stainless has built-in support for parallel sessions, which allow you to log into a site using different credentials in separate tabs at the same time. This new technology is woven throughout Stainless, from the private cookie storage system, to session-aware bookmarks that remember the session in which they were saved.

Download Stainless for Mac: Stainless.zip

Source


Do I have to harden IE if I'm only using Firefox?

I'm guessing that uninstalling IE is impossible or impractical.

Go to Control Panel -> Uninstall a program -> Turn Windows features on or off. There you can deselect Internet Explorer.

You need to harden IE as well. An application could launch or embed an IE window that could then be used to gain control of the system. Consider this attack: an attacker serves a web page that uses a 0-day remote code execution exploit in Firefox to launch an IE window that visits a page hosting a privilege-escalation exploit in IE.


Downsides of allowing multiple emails per user?

This is a fairly common practice for a some popular sites. Disclaimer, I've never done this for my applications, but from what I can tell, not really security-wise, other than what you mentioned. It's really the implementation that will take some thought as there are fewer packages out there that are going to support such behavior out of the box. Think about things like limiting the number of email addresses a person can use, communication procedures (ex. do password resets go to just the primary email, or would you allow any attached email), database schema, etc.

Here's an example of a couple of sites that do allow users to have and log in with multiple emails: github.com, facebook.com and internet.bs.


Where to store an important private key?

Check out the HSM products of Nitrokey and Yubikey. They are explicitly produced for this kind of use-case, where you need to sign with a key, while keeping it on-device.


Is it possible to find the encryption key from an already decrypted file

No.
Imagine you have a text file with some content M. The attacker then encrypts M with a key K, resulting in an encrypted file C.
By sending you back M, they don't directly prove that they have K, but since M is really what you are after anyways, that's alright.
The reason why it's not possible to tell anything about K is because M was created before K even existed. As such, it cannot possibly contain any information about K.
What you can do now
If you have a backup
Completely nuke your PC, re-install your OS from scratch and load your data from your backup. It might take a while, but it's better than paying ransom.
If you don't have a backup
The site No More Ransom might be able to help identify whether or not the particular ransomware used has flaws that can help recover the encryption key.
If you're lucky, then make a backup of your data now and then re-install your OS. That ransomware could have left behind some backdoors for future infections. Since you already paid once, you might pay again.
If you're not lucky, either pay the ransom or live with the fact that your data is gone. And even if you pay, you might be out of luck. Let that be a lesson to you to make proper backups.


Could EA know my password across multiple sites?

Both are game related sites, therefore it makes sense that once one gets access to a steam account login and password, it will try it on related sites too, even if he is not sure about it.

What kind of evidence would you expect to find that someone got into tour EA account? EA claims to have blocked the suspicious activity, maybe based on geo location or other parameters as you suggested, and this email looks like the first sign that they gave you that something happened.

The text is pretty standard for this. They are not claiming that they are forcing you to change the password because of that, but that the suspicious activity they noticed may be becaus of that kind of thing, and reusing email is really one of the top common causes for it.


Using the formulas in the book, "IT Security Metrics", you can staff your organization with application security professionals matched to the predictable number of incidents per quarter using a Poisson distribution. You could figure 100k US dollars per year for salary (doubled in most cases because of benefits and cost of business), 180k US dollars per year for 3 commercial SAST and 25k US dollars per year for 1 DAST (per person). The people and tools are very expensive. Make sure that you're not spending more than 37 percent of the assets that you are trying to protect. Remember that Veracode costs about 5-6k US dollars per app (apps in 100MB package size increments) that you send them -- and that competitor pricing is not far off from that number as well.

If you want to use an approximation, such as the ones used in regular information security, there is the Gartner-approved "6-7 percent" of total IT assets formula. For application security, you simply apply these numbers against the application development assets of an organization.


There are some commercial schemes, e.g. GridGuard from SyferLock that claim to do this, but I have never used them (I have no affiliation). This relies on the user choosing correctly from multiple options during authentication rather than a typical time or counter based OTP (which means no mental arithmetic).

Solitaire (Schneier), is often cited for a human-computable cryptosystem, it would need some adaption for authentication purposes though. A challenge-response authentication with shared key would be practical, but does not fulfill your description of the OTP.

What should work (with the usual caveat) would be an implementation of TOTP (RFC6238) or HOTP (RFC4226), using an alternate HMAC hash such as Blum's HCMU (Human Computable Machine Unbreakable, description here) mentally computable hash (see also the more generalised OCRA (RFC6287).

TOTP/HOTP are basically the (truncated) output of a HMAC using SHA-1, the input being a shared secret and timestamp or counter. You would need to use a strictly alphabetic representation of the input though, as Blum's algorithm applies only to alphabetic input.

Blum also co-authored a paper Towards Human Computable passwords (on ArXiv), though large parts of it are heavily mathematical. It doesn't briefly covers OTP in §7.2.

See also:

https://crypto.stackexchange.com/questions/9787/are-there-cryptographic-hash-functions-that-can-be-computed-using-only-paper-and
https://crypto.stackexchange.com/questions/844/is-there-a-secure-cryptosystem-that-can-be-performed-mentally


is set to an IP in China. Any reason why this wouldn't be the sign of some backdoor ?

If you are located in China then this would be probably fine.
If you are located elsewhere then it might be a backdoor or some malware like DNSChanger.


How do Message Authentication Codes provide source authentication

The client would take a piece of data, typically the body of your message itself and use a hashing algorithm that takes two inputs - your input and a long random secret pre-shared key, normally the key would be concatenated to the message before hashing to make it harder to determine the key from a block of cipher text.

This creates a HMAC - hashed message authentication code, it can be created with many hashing algorithms such as md5 or the SHA family. The HMAC offers a guarantee of data integrity as the hash would would not match if any part of the message has been modified.

The client performs an operation in the form MAC = Hash(key, data) and sends this with the message.

On receipt, the server which knows the key is able to perform the same operation and verify it came from the claimed source. To be more accurate, it only proves it came from a source that knows the secret key.

The HMAC security is dependant on the algorithm chosen and key length, common attacks are brute force attempts on the key.

Further info

RFC 2104 HMAC

Wiki - Message authentication code

Security Stackexchange question


This is a working SQL-injection. What could the server side query string look like?

In MySQL, the # symbol can be used as a comment marker.  Quote marks in comments don't have to balance.

Not all SQL instances run on Microsoft databases.


OWASP ZAP bruteforce by password not username

tl;dr -- Use ZAP to find the username and password parameters, and then Hydra with the -u switch to brute force logins, iterating through users instead of passwords as you asked.

EDIT: you can also use Burp Intruder using Cluster Bomb to cycle through. Works pretty well but not quite as fast as Hydra if memory serves correctly. There may be a similar feature in ZAP but I'm not as familiar. See the last Attack Type on Burp's site here.

Detail --

I would use THC Hydra with the '-u' switch. The tool is very simple and accomplishes what you're looking at by default. It comes pre-installed on Kali, and you can install the package on most Unix-based systems.

From the Hydra man page, the -u switch will "loop around users, not passwords". This will try pass01 for all 200 users before trying pass02 for each user. Here is a sample of what your command should look like:

hydra www.target-url.com http-form-post -L usernames.txt -P passwords.txt "/path/to/login:username=^USER^&password=^PASS^:Incorrect Login" -u -V -o hydra_output.txt

Breakdown: "hydra" is the name of the program. "www.target-url.com" is the address of the target, but you can alternatively use an IP (and specify a port). "Http-form-post" is the service you are trying to brute force. "-L" and "-P" are pretty self-explanatory, they are your login username and password files.

The next portion in the double quotes has 3 parameters you can capture with the ZAP proxy or by viewing the source code, and they are separated by the ":". First is the path, followed by a colon and the username and password parameters identified by ZAP (I like Burp, but ZAP will do the trick). Hydra will replace the "^USER^" and "^PASS^" strings with the values from your user/pass files.

Finally, the -u, as said before, will iterate through usernames, rather than passwords. "-V" will show you every password guess in stdout so you can verify it's working as it should, and -o will output the successful password guesses to the hydra_output.txt file.

I hope this helped. I am not super familiar with ZAP, but the free edition of Burp Suite is a counterpart product as far as I know, and Burp Intruder should have the functionality you desire if you must use a proxy.


Best way to encrypt a username in a database?

There is a standard solution to defeating rainbow tables: Add a salt to what you are hashing. A salt is a random value which you generate separately for each password hash and store together with that hash.

This, however, requires that you have to know which hash you are checking against (unless you want to try every single entry in your database until you found one which matches, of course. When your solution doesn't need to scale to a large number of accounts, this might be a viable option). So you will need to know which account the user wants to log into before you can check if their password is correct. What you could do is to have three columns in your database:

hash(username)
salt
hash(password + salt)

When someone tries to log in with the credentials admin : hunter2, you generate the hash of admin. use it to retrieve the salt, calculate the hash of hunter2salt and see if it matches.

Now it is of course possible to brute-force usernames, and do it even faster with a rainbow-table. But usernames should usually not be nearly as sensitive as passwords. You can make that less convenient by using a slow has function and by using a pepper (a salt which is the same for every entry - works against pre-calculated rainbow tables).


When brute-forcing a private-key stored as binary how do you know you found a solution?

How would the attacker know if a guess is successful?

There are only so many formats in which private keys are stored. As an attacker, if I could assume that you didn't store your private key in your own, home-grown format, I'd just see if my brute-force guess decrypted the private key to any one of the formats I'd expect a private key to be in.

For example, if I assumed that your private key was an ASCII-armored PGP key, I'd simply check whether the first few bytes decrypted to

-----BEGIN PGP PRIVATE KEY BLOCK-----

and vice versa for other formats.

If the attacker had a list of possible public key candidates for the private key, he could also compare the modulus of the resulting decrypted private key against the modulus of the public keys and if one matched, he'd know he had a correct decryption.

  Besides the brute force, are there other approaches to decrypt the private key given the above information?

None I know of, as long as you use a strong symmetric cipher. Other avenues of attack would mean there were serious weaknesses in the symmetric cipher you use to encrypt the private key.

  Are there significant differences between PBKDF2 and bcrypt in this scenario?

Probably not. Both are considered strong for key derivation, even though opinions differ on the exact advantages and disadvantages. One disadvantage they both share is that they don't use very much memory to derive keys, so they can be implemented on very fast, highly parallel processors (think GPUs and FPGAs).

(edit: added the part about comparing with the public key modulus to confirm a correct decryption)


In theory, can x509 certificates use Accumulator-based revocation schemes? How do these schemes work?

To put things simply, one of the goals of U-Prove is to provide some kind of anonymity (in their words, "preventing unwanted user tracking"). This makes revocation harder. In an X.509 context, where there is no user anonymity (a certificate contains the owner's name in plain words), revocation is simple: the authority who decides who is revoked and who is not simply issues signed statements about the revocation status of a given certificate. This can be an OCSP response, which talks about a single certificate, or a CRL, which lists all revoked certificate (from a given issuer or set of issuers), and thus implicitly lists all non-revoked certificates as well.

If you try to do the same thing in U-Prove, then you have invented a way to track users, and that's not good. So revocation in U-Prove must use more complex protocols, e.g. a cryptographic accumulator. Mainly, this allows each token owner to compute a verifiable proof of a token not being revoked at a given time, without opening the possibility of tracking the token owner. Revocation is still asserted by a specialized authority, so there must be some regular communication from the authority to the token owners; these are the witnesses. Each token owner must obtain a fresh witness from the authority, in order to compute the verifiable proof that the specific token is not revoked at some time.

This is not an optimization over X.509 CRL/OCSP. In an X.509 world, each certificate owner can obtain a fresh OCSP response from the CA and then show that response to third parties; this mimics the system of witness propagation but with shorter elements and less CPU cost. Moreover, in X.509, it is not necessary that the certificate owner be involved at all; each entity who wants to validate a certificate can obtain the CRL or OCSP response directly from the CA.

In other words, cryptographic accumulators don't make classic revocation more efficient. In fact, they make it less efficient. But they add a new feature, which is the possibility to maintain revocation while still pursuing a non-tracking anonymity goal. This goal makes no sense in X.509. Therefore, no cryptographic accumulators in X.509. You could try to design and implement a revocation system for X.509 which uses cryptographic accumulator, but it would provide no extra feature, and would just make the system more complex, expensive, and restricted.

(In shorter words, there is no revocation scheme for X.509 which uses cryptographic accumulators because it would be a stupid thing to do. It would be like adding an extra gasoline tank to power a horse-drawn cart: it would not help the horses go farther, even though it would have helped if the horses had not been horses, but a combustion engine.)


Tor is better for you than it is for people in countries whose intelligence services run lots of Tor exit nodes and sniff the traffic.  However, all you should assume when using Tor is that, if someone's not doing heavy statistical traffic analysis, they can't directly correlate your IP with the IP requesting resources at the server.

That leaves many, many methods of compromising your identity still open.  For instance, if you check your normal email while using Tor, the bad guys can know that that address is correlated with other Tor activity.  If, as @Geek said, your computer is infected with malware, that malware can broadcast your identity outside the Tor tunnel.  If you even hit a webpage with an XSS or CSRF flaw, any other web services you're logged into could have their credentials stolen.

Bottom line, Tor is better than nothing; but if your life is on the line, use a well-secured computer for accessing Twitter and WordPress using it, and don't use that computer for anything else.


Appropriate defense for 404s in my logs - persistent web scans from one region

This is pretty well the background noise of the Internet. Since phpMyAdmin had such a poor security history it is not uncommon to see systems looking for instances of it running on the network. Chances are, that is exactly what is happening. There are a few things you could do to take action on such an activity, though which one, or ones, you choose will depend wildly on how your site is used.

Block It Entirely
Depending on who needs to access your web site, you could insert firewall rules to only allow access from specific addresses or address ranges. For example:

-A INPUT  -s 198.51.100.50-m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT  -s 203.0.113.0/24 -m tcp -p tcp --dport 80 -j ACCEPT

This will specifically allow address from the host 198.51.100.50 and the network 203.0.113.0/24. Here the benefit is limiting your scope of access to a relatively small set, however you need to know every where access is required.

Rate Limit Connections
IPtables has built in support for rate-limiting. As an example take these firewall rules:

-A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW -m recent --set --name WEB
-A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name WEB -j DROP

What this will do is limit each source address to only 8 connections within 60 seconds. These values may need tweaking, depending on your environment, but will certainly slow down any kind of brute force or fast scan.

Dynamic Detection and Blocking
There are a number of applications for doing this, but they all basically work the same way:

Read specific log files for actionable events
Compare events against some kind of scoring system
Take action if meets criteria

One of the most popular (subjectivity alert) is probably an application called fail2ban. It will process a large variety of logs on your system, including SSH and Apache, and issue blocks for those source addresses that are committing "suspicious" behavior. Typically this would be adding a source IP drop rule in your host firewall. You mention that you are using Nginx as your web server, so you would have to research whether or not fail2ban, or what other product, would work for you.


ISPs are now adding unique header identifiers to web traffic. Can this be avoided? If so, how?

The easiest way to avoid interception/modification of your web traffic is one that you mention in the question which is to use a VPN.  This will encrypt traffic between your device and the VPN endpoint and should prevent your ISP from being able to modify web headers or other aspects of your use.

There are VPN clients for most modern mobile operating systems (e.g. OpenVPN which has clients for android and iOS).

One thing to note though is that is using a VPN you are trusting the VPN provider to an extent so it's worth spending some time looking at VPN providers to find one that you're comfortable with.  In particular I'd be a bit suspicious of providers who are free as there is a question of how they make money from the service if it's not directly from their customers.


The point of zero-day attacks is that they use vulnerabilities which are not known at the time they get exploited. You can thus not create a policy specifically for zero-days. But hardening the security in general also reduces the risk or at least the impact of a zero-day. Because the zero-day exploit is just the way the attacker enters the network or takes over a system or account. The actual harm against the network is not done by the exploit itself, but by the attacker using other tools and methods from its achieved privileges on the computer and in the network for espionage, sabotage, ransom etc.

Therefore the protection you add must be based on the assumption that the attacker has already successfully entered your network using the zero-day exploit, i.e. that he is actually inside your network and that you need to reduce the harm he can do there.

This means of course being up-to-date with patching since otherwise you likely have problems already with the way more common known attacks than just with the uncommon zero-day attacks. This means monitoring your infrastructure for suspicious activity, which of course means that you know what should be normal and what is suspicious in the first place. Strict and narrow separation and segmentation at network and application level and proper user permissions can help a lot to restrict the harm a successful attacker could do in your network - no matter if he came in by using a zero-day or not. And for the harm you could not prevent you need recovery strategies, like having a backup with a working restore.

In other words: know what should happen in your network and implement techniques (like microsegmentation, zero-trust, ...) to enforce and monitor the expected behavior. Expect some harm and be able to recover from it. The better you understand what should happen and the better you enforce it, the less harm an attacker can do in your network even if he has successfully infiltrated some computer/user in the network. It is not that firewalls, IDS, antivirus, SIEM etc don't help - but these are tools to enforce and monitor expected behavior and not magic wands you just need to wave. Don't expect to successfully fight zero-days by adding security on top of a chaotic network you don't understand or which behaves differently than you believe.


Do I need to keep certificate signing requests and public keys?

There's no need to keep either. Of course, you may want to store your public key for convenience (should you ever need to use it directly). For example, I keep my SSH public keys even though I can regenerate them whenever I want -- If I need to copy a specific key to a server, it's more convenient to not have to generate it.

The CSR is also something you can regenerate given the private key. The CSR itself has no power after the certificate is signed. It's OK to release it publicly or to delete it.


First of all realize when talking about an IDS we are talking about a passive device. With a passive device they commonly log/alert and nothing else. On the other hand if this device was an IPS that is where the active "shunning" blocking or whatever else it was built to do happens.

Much like anti-virus technologies there are two types of network sensing  technologies signature based (e.g. Snort), and heuristic based (e.g. Fireye kinda!).

As for detecting anomalous activity at layer 2 it is uncommon for the IDS/IPS to usually take care of this. This however does not mean that something on the network else could monitor this instead. That something is usually a NAC (Network Access Control) solution (e.g. FreeNAC) and it is possible there is a suite of tools that may run together with the IPC/IDS and does this but as a different part of a product (see palo alto).

With all that said at the internet touch points there are many ways to passively finger print a device based of its traffic. In fact Nessus actually does this very good, and additionally, if you have ever played with pOf you have already done this yourself. Things like web requests, smb connection attempts, and other bits of traffic help those systems pull together quite a bit of information passively.

See this Nessus page explaining more.

http://www.tenable.com/blog/enhanced-operating-system-identification-with-nessus


SMBRelay Attack - Mount Share instead of Code Execution

Yes, but for mounting shares you only need to use the NTLM Relay aka NTLM Reflection attack, not the full SMB Relay code-execution attack.

Due to the fleeting nature of NET-NTLMv2 authentication, I suggest the use of the -- https://github.com/purpleteam/snarf -- tool because it will hold the connection to the server, unlike Responder.py or InveighRelay which will only grab the NET-NTLM credentials on the wire (while BunnyTap and Quickcreds only require physical access with a USB drive). However, NET-NTLMv2 creds can be compared to stored-NTLMv2 creds, although wdigest, warm-boot memory acquisition, and other factors can easily widen the capabilities of stored-password attacks.

There are quite a lot of tweaks to these attacks as well as defenses that come into play. Feel free to bring up issues you run into, but the snarf tool above is one of the best starting points.


Is it more secure encrypting 3 times with GPG?

You may be surprised to learn the answer is "you are probably less secure."

Security isn't simply asking "can someone else hack my crypto?" Security is a big picture for protecting yourself and your data that includes three main attributes: Confidentiality, Integrity, and Availability (the CIA triangle.)  What your proposed solution does is it adds a lot of complexity.  A year from now when you try to remember all three pass phrases, and what order you have to decrypt them in, and did you get all the file types and options on the command lines correct, you might find yourself unable to get to your own data.  And because you're doing this on your own, you're not following a standard that other people use; this means you can't look up "how to effectively use three different forms of GPG encryption" and hope to find the right answer that works for you.

By creating such a complex, non-standard process, you are adding risk to the availability of your data.  This reduces your security.

Against this added risk, consider ways you can offset that risk with a gain in confidentiality.  Are you aware of any specific threats to GPG using AES-256?  (If you do know of something, don't use it at all!)  Are you aware of any specific threats against a 150 random character passphrase that would be offset by using a second algorithm with another 100 random characters of password? (For what it's worth, the rest of the world is unaware of any such flaws in GPG; if they were even surmised to exist, the code would have been patched.)

Your greatest risk is almost certainly not the cryptography.  Instead, most risks to security come from flaws in operational security (OpSec.)  Most importantly, you want to secure yourself against accidental releases of information.  Is the box secure and malware free?  Is it online?  Is the software and OS patched and current?  Did you download gpg from a reputable repo; did you confirm the hashes?  Did you compile the gpg binary from source yourself?  Did you use a cryptographically secure random number generator to create the 150 character password, or did you generate it using the output of random()?  How and where do you store the 150 random character password string - might you lose it?  Might someone else find it?  After encrypting the original data did you securely delete it, or did you just drop it in the recycle bin?

After taking these kinds of ordinary precautions, then you can consider the possible existence of external threat actors who could be highly motivated to deliberately steal your secrets (depending on their value).  Have you checked for a keylogger hidden in the cable or buried in your hardware?  Is there a camera observing the keyboard?  And are you re-checking all of your security measures every single time you enter the password?

If you don't understand the risks with crypto at a mathematical level, do not try to re-invent ways of stacking it together imagining you are improving security in some unknown way.  Instead, broaden your attention and make sure you are doing all of your security well.


Collecting banking, credit-card statements from users

Credit Card Numbers are property of the VISA, Master Card, American Express and other issuers so you cannot store them without abiding their rules even if you are not a merchant.
If the card passes in clear text in your system you will have to comply with their requirements.
You are not forced but if you have a breach you will not be able to prove that you had due diligence in protecting all the data if you do not follow their requirements.
I think the same is valid for the Private data.

I am no expert but i think in your case it is a risk management issue that you need to validate in order to understand what is best for your business.


Whilst such devices shouldn't be directly exposed, it can happen and not just through sloppy setup or UPnP.

A compromised router, internal malware, driveby malvertising, etc. could all create a gap into the internal network.

In addition, it may happen occasionally that changes made to otherwise secure networks may inadvertently expose internal resources. This is especially likely when people start experimenting with IoT.

Finally, it is possible that consumer devices come with a vendor supplied Internet service to get a "secure" remote connection and that may not be properly secured. For example, many NAS's come with a way to access them remotely without having to create inbound firewall rules. The NAS connects to a vendor server and you also connect to that when remote via some web service or app. Many consumer IoT devices come with similar services that allow access from mobile phones (remote lights, heating controls, etc).


Why AdES -A signatures require TWO timestamps?

As you said, the second timestamp protects all content.
It is there to specify that the revocation data was valid at a certain time, due to the archiving part of this type of signature.
If the revocation values were present without the second timestamp, there would be no way to prove their validity at the time of the signature.

Using CADES-A, the first timestamp theorically could be removed, but as you show it, CADES-A is over CADES-C, which is over CADES-BES. The standards are over each other and each type of signature has to match the standard. For example, CADES-LTA (Long Time Archiving) would be over CADES-A, etc.


What's the meaning of 'the some sort of race condition' here?

A race condition is a bug which only happens when a system executes multiple tasks in parallel and these parallel tasks get finished in a specific order.

In this specific case, the author wants an instance of phantom.js (a headless web browser) to execute a javascript payload and then take a screenshot of the result. This fails because sometimes the screenshot is taken before Phantom.JS is finished executing the javascript payload.


IP addresses starting with 10.* are reserved for local area networks. You seem to be on a LAN which does not allow you to ping any host outside of it. 10.x.0.1 seems to be a border-router which filters your pings.


"Is it possible to have a secure authentication protocol which

doesn't involve trusted third party and encryption of data?"

Yes.

 "Using shared/established" signature key-pairs to skip the "to encrypt messages" part,

where the verifier chooses an unpredictable nonce and the

other party signs the ordered pair    nonce , actual_message  .

(Note:  Some sources inaccurately describe RSA signatures as "encryption".)