If mysql schema is missing, where can I find credentials?

As DarkLighting said in comments, the mysql schema is always available because it's part of the installation, just as information_schema.

If a user can't see the mysql DB, it means he has no privileges. Likely he has the privilege USAGE. So in order to be able to get the users' credentials, first the attacker should leverage some privilege escalation vulnerability to get root access, and hence, gain access to the mysql DB where the credentials are stored.


Is AntiForgeryToken needed for newsletter subscription?

It depends.

You only need protection against CSRF for endpoints that are protected with some sort of authentication. The reason that the attacker needs to fool the victims browser into sending the request (i.e. to "forge" it) is that the attacker doesn't know the session cookie, so she can't just send it from her own machine.

So for an ordinary newsletter form, where theres not authentication and you just enter your email address and hit submit, you don't need CSRF protection. If I want to sign you up against your will I just enter your email and do it myself.

However, if the form is behind authentication and perhaps the email address is fetched from the user database, then it's a different story.


Whether using a fixed IV is acceptable depends on the mode of operation you're using.  Some modes only require that the IV be unique under a given key, such as CTR mode, while others, such as CBC, require an unpredictable IV.  Attacks on CBC are known with predictable IVs.
The adaptive chosen plaintext attack mentioned exposes the plaintext, but not the keys.  In general, a secure block cipher itself should not be vulnerable to exposing the keys even if some correspondence between the plaintext and ciphertext is known, which is usually what happens with IV misuse.  I'm not personally aware of any common AEAD modes which require an unpredictable IV, but in general IV misuse with AEAD modes can compromise both confidentiality (expose the plaintext) and integrity (permit tampering).
The easiest way to avoid reusing an IV in this way is to take the random value you would normally use for the key and run it through a key derivation function (KDF), like HKDF, to derive both a secret key and an IV.  If you're already using a password-based KDF to generate the key, you can also generally generate the IV using the same KDF.  Since this is so easy to do, there's little reason to reuse an IV in a practical environment.


Are there any problems associated with using the same encryption key for multiple systems?

There is often a trad-off to be found between security and usability.

Some times you consent to loose a bit of usability for the sake of security. Some times you agree to loose a bit of security for the sake of usability. All that's matter is to clearly understand the risk you are facing and whether or not you accept to cope with this.

In your case:

Using disk encryption is always better than using no disk encryption. Botting from another media or extracting the disk for instance will not give an immediate access to your data.
Using long passphrases is better than short passwords. The disks will most probably be resistant to brute force attacks, an attacker would therefore need to find another way to get access to your passphrases (software weakness, shoulder surfing, hardware keylogger when appropriate are possible examples of alternative ways to get access to your passphrase).
Using the same passphrase on all of your encrypted device make this passphrase o become a single point of failure. If an attacker manage to get access to the passphrase on one device, he will be able to decipher the content of all other devices.

Knowing this risk, you might find it acceptable.

For instance, if all of your device already share the same content (mail software retrieving mails from the same mailboxes, Firefox synchronization enabled, copies of the same files or access to the same shared location (cloud storage, etc.)), then having separate encryption passphrase might be of little value.

Or if your main concern is about one of your device being stolen, the fact that it's content will be strongly encrypted is a sufficient guaranty. A casual thief will most probably have neither the opportunity to look or film you while typing your password nor proceed with an advanced plan like installing some keylogger on your system to capture the passphrases in prevision of stealing the devices as a next step.

I encourage you to check this thread, you will see that a strong passphrase is not necessary a complex one with strange symbols all over the place, and moreover you will discover "@AviD's rule of usability" I have to highlight here:

  Security at the expense of usability comes at the expense of security.


Security risks in 301/2 redirect HTTPS to HTTP

A redirect to HTTP by itself is not a problem, especially since the Referer (which might contain sensitive information) is not included when redirecting from HTTPS to HTTP.

Of course, there might be problems if sensitive information are included in the URL of the redirect target, but this is not actually a problem of the redirect itself (which is still done with HTTPS) but of the following request which accesses sensitive URL's via plain HTTP. But it is not known if this actually happens in your specific case so it is impossible to say if there is an actual problem or not.


Qubes OS or TENS for security? Is Qubes a good idea for a total beginner?

Summary
I think you want Qubes. I really enjoyed using it (and I miss it a lot while writing this up!). Expect that you'll need to sink a fair amount of time and energy following guides on the Qubes Docs page to do linux-wizard-y stuff like editing config files on the command-line (the price you pay for a hardened OS!).

My experience using Qubes for a year
I've been a linux-only user since about 2006. Last year I put Qubes on my laptop and used it as my primary OS for about a year - everything from web browsing to software development.
Out of the box it worked great for web browsing and basic tasks like opening PDFs, but trying to do more involved tasks like installing new software, connecting to the NAS on my home network, plugging in a USB stick, etc quickly became very complicated and forced me to learn a lot about the internals of linux, networking, and virtualization - Despite being a 10 year linux veteran. That said, for me learning Qubes was a really fun experience and I learned a lot!
My opinion is if you just want a secure way to web-browse then out-of-the-box Qubes will be straight-forward enough. If you want an every-day OS to do all the things you currently do on Windows / Mac, then you're in for a learning-curve (hopefully a fun one :)

Head-to-head comparison Qubes vs Tails vs TENS
I've never personally used Tails or TENS, but here goes at an attempt to compare the three head-to-head.
Qubes OS
TL;DR: Qubes aims at being an everyday OS where you isolate different apps from each other by giving each its own full virtual machine. It gives a nice balance of usability (your data and installed applications persist across reboots, for example) and security (things are isolated from each other, and it's quick and easy to for example, create a clean VM, paste in some sketchy links that you didn't want to open in your banking VM, and then destroy the VM).
Definitely designed to be an every-day OS. It's based around the core idea that you run multiple VMs which (through some clever linux wizardry!) all co-exist in the same desktop so you can interact with them all at the same time, but each VM is unaware of the existence of the others. In the following image the green window and the yellow window belong to separate VMs.

That means that each application can have its own complete complete computer - a pretty good security barrier! For example I gave facebook its own VM (which I set to be destroyed on laptop reboot). Casual web browsing, banking, and each work project also each had their own VM. Qubes supports running different OSes in each VM, so if you want an Ubuntu and, a Debian, and a Fedora, you can do that. In theory, Qubes even supports Windows as a guest VM if you want to keep using Windows apps.

Tails
I have no direct experience, so from its wikipedia page:

Tails or The Amnesic Incognito Live System is a security-focused Debian-based Linux distribution aimed at preserving privacy and anonymity. All its outgoing connections are forced to go through Tor, and non-anonymous connections are blocked. The system is designed to be booted as a live DVD or live USB, and will leave no digital footprint on the machine unless explicitly told to do so.

The list of software that comes pre-installed seems all security and privacy focused. So if you wanted to install your favourite web browser, or a spreadsheet program, or wtv, you'd probably have to jump through some hoops (and of course do it again on each reboot). From quick googling, it looks like Tails can be configured to have persistent storage, but it's definitely designed to wipe itself back to the factory state on reboot, which I would personally find very frustrating.
Because it's designed to use Tor at the network-driver level, I suspect "everyday" things like connecting to a network printer, or your Chromecast, or maybe even streaming youtube or netflix would be very frustrating.

TENS
I have no direct experience, so from its wikipedia page:

Lightweight Portable Security (LPS) is a Linux LiveCD, (or LiveUSB), developed and publicly distributed by the United States Department of Defense’s Software Protection Initiative that is designed to serve as a secure end node. LPS boots only in RAM, creating a pristine, non-persistent end node. It supports DoD-approved Common Access Card (CAC) readers, as required for authenticating users on DoD networks.
As of version 1.7, the distribution was rebranded as Trusted End Node Security, or TENS.

So this is very similar to Tails in that you'll lose all your data on reboot and probably have a fair amount of frustration at installing software that doesn't come pre-installed (which seems limited to DoD internal tools). The networking (streaming, connecting to other devices on your home network, etc) might be easier that Tails.

Summary (same as above)
I think you want Qubes. I really enjoyed using it (and I miss it a lot while writing this up!). Expect that you'll need to sink a fair amount of time and energy following guides on the Qubes Docs page to do linux-wizard-y stuff like editing config files on the command-line (the price you pay for a hardened OS!).


Digital signature using only x509 certificate

No, but.

Yes, technically you sign (or decrypt) with the privatekey, not with the certificate itself. And a publickey certificate never contains the privatekey.

But a lot of software, and thus documentation, and other description, blurs this distinction. We generally use a privatekey with a certificate (with the exception of SSH, where we attach limited metadata -- a host name or address, and sometimes other restrictions -- directly to a publickey), and the certificate part of this combination is more understandable and interesting to humans.

For example, the Microsoft Windows "Certificate Manager" displays things that are labelled "certificates" organized into things labelled "stores". You can have entries that are simply certificates (for someone else, usually a CA) or entries that are certificates with a privatekey attached (for yourself, or someone you are acting on behalf of). The fields of the certificate are displayed and at least some are meaningful to people: the subject name(s), the validity period, the issuer, sometimes the keyusage and/or extendedkeyusage. (Perhaps the transparency SCT(s) -- well, no, probably not. :-) The privatekey when present is not displayed (for security) and if it was it would be weird incomprehensible gibberish to 99.99% of users.

When you want to sign your email with Outlook, you go to a "Certificate Manager" window and select a "Certificate". Outlook includes this certificate in the outgoing email, and when the recipient displays that email their MUA shows it was "signed by the owner of certificate X" often elided to simply "signed by certificate X". Outlook did in fact use the privatekey to sign as well as putting the matching cert in the message, but the users see and identify and focus on the cert not the privatekey.

This is also reflected in the API; to actually do signing (or decryption) in Windows you get an object of type X509Certificate2 either from the store or by loading a PFX/PKCS12 file, which actually contains both the certificate and the privatekey.

MacOS keychain is similar, for certs with or without privatekeys (it also does passwords, which are different).

The same is true for TLS/SSL/HTTPS server and optionally client auth -- the privatekey is used internally, but the user(s) and admin(s) see and choose and think about the certificate. This definitely includes IE and Edge, and Chrome on Windows, and to my understanding Safari and Chrome on Mac. Firefox (and NSS) uses its own "cert database" instead of the system one, but it also describes and displays the entries as certificates whether or not they have privatekeys attached.

We often (IME) do the same for certificates themselves, which are also signed objects. For example, a few years ago people experienced trust issues with Google's (then) internal CA, "Google Internet Authority 2", because of the timing of some cross-CA bridging certs, IIRC between Equifax and Geotrust (or maybe the reverse). In answering some of those Qs I believe I talked about, say "this google cert X signed by this other cert Y". That is technically incorrect; to be exact I should have said "this google cert X signed by the abstract entity which is or at the relevant time was the verified owner of the cert Y using the privatekey which is part of the same keypair as the publickey that is in the cert and owned by the same owner as the owner of the cert and generated as a mathematically related unit". If I had done so, and repeated this 5 or 10 times for all the needed links in the cert chain, I would probably never have completed a single answer because it would have been too much work. To someone who knows how public key crypto works, "cert X signed by cert Y" is easily understood even though technically wrong, and to someone who doesn't know, it doesn't make any difference.

BTW, Java goes the opposite way. It has "keystore" files (or sometimes nonfile storage like a PKCS11 token) that can contain (either) lone certs for others, usually a CA, or privatekey-plus-cert entries for yourself. People get these confused just as easily as they do the Windows/Mac/FF approach; I personally have answered at least a dozen Qs here and related Stacks from people who imported a lone cert to their Java keystore when they needed a privatekey plus cert.

GPG traditionally has a "key ring" which contains publickeys with added metadata and (canonically) signature(s) that are in effect certificates, though not called that, and (matching but separate) "secret" keys which are really privatekeys. (This follows PGP, which was designed back in the 1990s before the privatekey-vs-secretkey terminology was settled.) OTOH its newer GUI Kleopatra calls them (together) certificates. Pick your poison.


In terms of a penetration-test / security review you want to review both components, because both components can have different vulnerabilities. The web service should be secure against things like SQL-injection, path traversal, broken authentication and so on whereas the web app should be secure against cross-site-scripting.

You should check the OWASP Top 10 and dertimine which attack vector can / should be prevented in the backend and which in the frontend.

All in all I would say, a secure backend is way more important than a secure frontend because the frontend can easily be bypassed with tools like burp suite oder ZAP, so focus on the backend. But keep in mind that there are vectors which only apply to the frontend.


With GPG, can 3rd party verify that message has been encrypted by specific public key?

Maybe sort of.

The pk-encrypted-sk packet in PGP (see rfc4880 5.1) normally contains the 64-bit 'long' keyid of the recipient's key; this is intended to help the recipient use the correct decryption key if they have more than one, and to help the recipient identify which tag-1 packet (if any) is for them in a message encrypted to multiple recipients. It may be suppressed by substituting zero if desired.
This can be displayed by any number of PGP analysis/debugging tools, including gpg --list-packets.

If Bob is accused only of a mistake, not of cheating on or lying about sending the message, and did not use GnuPG's --hidden-recipient or similar, this is probably sufficient. If Bob is accused of (even contributory) malfeasance it might help if when the message was sent (or at least prior to any dispute) he signed it, had it timestamped by a TSA, or both, but you'd have to be more specific about the case or range of possible cases to be handled. (ObSecStack: what's your threat model?)

Assuming the key blob is still available or can be obtained e.g. from a keyserver, this almost 'proves' what key Bob used. It is presently difficult, but not impossible, to generate a false key (second-preimage) for a long keyid. (It is easy for 32-bit 'short' keyids often used for manual selection or 'verification', see https://evil32.com .) It is practical to generate collisions for 64-bit, but that would require Alice to knowingly collude in a false claim; see above about threat model.

However, that does not constitute proof the key used was (or still is) Alice's -- it is quite possible that Bob did in fact make a mistake. What reason or evidence did he use in choosing that key to encrypt to?

Just having a key with Alice's name in it is NOT proof it is her key -- those are trivial to fake.
Having a key with Alice's name in it that was signed by trusted other parties is better evidence, but not absolute -- with enough effort someone could have posed as Alice to get a fake key signed.
Even if Alice actually gave Bob this key, can he prove (1) she did so and (2) he at all times thereafter maintained it on device(s) or storage that no one else could have tampered with?

Note: similar to Is it possible to prove which public key was used to encrypt a message? which covers a broader range than just PGP.
Also
Can I check who can decrypt my GPG message after I encrypt it?
What information is leaked from an OpenPGP encrypted file?
Can all the (other) recepients of a PGP encrypted message be identified?
which I didn't see earlier.


Will HTTPS negotiations slow down as more domains are added to the certificate?

The number of names is a very small amount of data overall; if it pushes delivering the certificate over a packet size threshold, the added delay won't perceptibly impact human users that have broadband or other high speed connections. The receiving computer will have up to 14 extra strings to scan; again, an imperceptible amount of overhead to any particular human user.

Qualys SSL Labs did a certificate survey a few years ago, and presented their findings at Blackhat.  They found many issues that contributed to performance problems.  In the case of multiple domain names, they found one certificate with 354 unrelated domain names, and the certificate was 8.2KB long!  So yes, there is a line you probably don't want to cross, and 354 appears to cross it.

Another common problem they found impacting performance was that some validation chains were too long.  A long time ago, some PKI architects were advocating a multi-tiered approach, where every certificate would be signed by a root CA, one or two Subordinate CAs, and one or two Policy CAs.  Running through the RSA math on four different validation steps is what bogged down the clients, much more than the size of the certificates.  (Qualys found 8 certificates that had a signing depth of 6!)  To keep performance as high as possible, keep the signing chain as short as possible.

They also saw 43% of servers were sending too many certificates.  Normally, you would include the server's cert and any intermediate signing certificates needed to validate it up to the root (the root cert is normally contained within the browser, unless it's a self-signed cert.)  Many sites were wasting bandwidth by including additional certificates not needed to validate their site.  One site sent a certificate file back that contained 116 certificates!

Finally, they found lots of certificates that were just plain bad.  They were self-signed, expired, used weak algorithms, or had other flaws that meant their protection was less than optimal.  Of all the things you need to achieve with a certificate, security is number one - performance is not.  So I'd recommend using their analysis tool and finding out what they think of your setup.  https://www.ssllabs.com/ssltest/index.html . I run this check every time I change my server's configuration and after updating my certificate.

UPDATE:  I've switched to using an nmap script to check my server.  Make sure you're running an up-to-date version of nmap, then run nmap --unprivileged -sV --script ssl-enum-ciphers -p 433 example.org.  This will list the ciphers supported by the server, and provide a letter grade indicating the security of each, and an overall grade for your server.  Good for finding things like out of date and insecure versions of SSL/TLS, 64 bit ciphers, etc.  And you can run it on any host and port, so you can test app servers, web services, internal servers that are behind your firewalls, etc.


Do obscure image URLs prevent image harvesting?

Most automatic crawlers don't have time to comply with the registration procedures of all Web sites. If the picture names are not "guessable" then they won't be harvested by crawlers which scan "the whole Web". However, of course, any registered user who can see the pictures will be able to slurp all of them (and not only images, all the Web pages as well). The well-known opensource tool GNU Wget has command-line flags for recursive exploration of Web pages.

Note that the server can know, by construction, who is making each request (that's what it means that a user is "logged in"). You can then implement restrictive rules such as "no more than 10 pictures per user and per minute" or similar constraints. With such rules, a user bent on downloading all your files will have to create many fake accounts, register them all, and use them more or less in parallel. You can also filter on source IP address (if too many requests come from a single IP address in a short time, ban that address temporarily).

All these deterrents are just that: ways to make the task slower and harder for attackers (if we call people who want the pictures "attackers", which is subjective). Motivated attackers will obtain them nonetheless.

Generally speaking, when you publish a piece of data, then it becomes "public" and you cannot really control where it goes. This is the dilemma of all media content providers: once the music file is out, it is out.


The source addresses are not totally unknown: the first one is from canonical.com, which hosts Ubuntu packages (therefore I suppose that your system runs Ubuntu, and currently tries to see whether there are available updates for your installed packages). The second address is stackoverflow.com, a well-known site in these parts. Most probably, these packets are just part of client connections from your computer to the Internet at large, for which your router runs NAT (which is its primary job). Port forwarding is for incoming connections (from outside to your system).

The log shows that the packets go through your eth1 network adapter. On a Linux system, this is the second adapter, the first one being eth0 (possibly, you have an ethernet interface and a WiFi adapter, and you use the latter). tcpdump uses eth0 by default, which would explain why you see no packet with it. Try using the -i option for tcpdump (see the man page).


How to sniff bluetooth traffic to Android app?

Given that you discarded hardware modifications, to sniff the bluetooth packets you would need to either:

Install something like Wireshark on your phone, this would probably require root privileges.
Have some device like Ubertooth that allows you to sniff the communication between the watermeter and the android app

I'm not sure if the Ubertooth device supports every bluetooth version out there. And the wireshark-like app is only possible if you have root privileges on your phone, which may or may not be the case.

I'm not sure what is your objective on this task, but I think that whatever you're trying to do is probably easier to do installing a modified version of the APK, for example to include a Frida gadget and then interact with the app in runtime to log whatever messages are being sent

In this way you can get the information that is being transmited directly from the application if this is the only thing you need. Or if you want to actually decode the bluetooth packets on the fly you can use this to start decoding them using the ubertooth mentioned earlier or another device


The HTTP cookie mechanism allows you to specify the domain a particular cookie is associated with. The domain can be the domain of the page setting the cookie or, more interestingly, one of its superdomains. E.g. foo.bar.example.com is allowed to set cookies on the foo.bar.example.com, bar.example.com and example.com domains.

What does this mean for GitHub Pages? Well, subdomains of the github.com domain are allowed to set cookies on it, meaning they can perform session fixation attacks by providing the browser with an existing session cookie. Here's how a simplified attack scenario would look:

Let's say github.com uses a cookie called SESSION_ID to identify active sessions. This cookie contains a unique hash, long enough to be impossible to to guess. Each hash is associated with server-side session data, i.e. a logged-in user.

Now consider an attacker who sets up a GitHub Page at evil.github.com. They include some of their evil scripts in the page and then trick a victim to visit it. What does the page do? It sets the SESSION_ID cookie on the github.com domain to a valid value known to the attacker. This would cause the victim's browser to effectively log in to GitHub using the credentials provided by the attacker. The attacker could then follow the activity on the account and retrieve any data created by the clueless victim.

Moving GitHub Pages from github.com to github.io fixes the issue, since there are no user accounts or sessions on the new domain.


Any historical precedent for Open-Source libs as an attack vector?

You're right, deliberate injection isn't common in the open source world, in part because the process makes it expensive, but mostly because it's not necessary.

Most open source projects that gain traction have users who exercise lots of use cases and need careful custodians who respond to problems and know their committers, so arbitrary pull requests from new developers go through a vetting process, and in order to get their code in, participants have to be invested in growing a reputation and building trust. This all makes deliberate injection of vulnerabilities difficult.

And it's not necessary because software is vulnerable by default. From an attacker's perspective, there is no reason to go through a trust charade to inject vulnerabilities, because there are already going to be some in any codebase, you just have to look for them. And because the code is open, you can look for them without anyone knowing you are looking for them.

In the closed source/commercial world, injection is much more common, for instance:

https://www.wired.com/2015/12/juniper-networks-hidden-backdoors-show-the-risk-of-government-backdoors/

For those attackers at that scale it makes sense to build and then sacrifice trust, though that is a very expensive exercise. The infamous case of Dual_EC_DRBG is instructive, because it was an injection in a world that resembled open source in terms of dynamics, with the result that a previously trusted actor (NSA) working in a previously unblemished open process (NIST) has forever sacrificed their own and the process' credibility. Check wikipedia for details.

The model you suggest- third parties utilizing a process that does not require trust to inject attacks or vulnerabilities- accurately describes the delivery model for web malware.

Arbitrary, unauditable, and precisely targeted third party code- layers of javascript, flash, and so forth that delivers ads, captures metrics, provides sharing buttons and does tons of other stuff- are loaded into the browser on behalf of the first party domain the user is visiting, usually with very little to no awareness from the first party or from the user. It's highly risky for users and of course catastrophes happen all the time:

https://www.proofpoint.com/us/threat-insight/post/massive-adgholas-malvertising-campaigns-use-steganography-and-file-whitelisting-to-hide-in-plain-sight


What does ssh-keygen's -a option really mean?

This differs between ssh-keygen versions. From this post:

  The original difficulty parameter for bcrypt is the log2 number of
  times to rekey the cipher. bhash fixes this number at 64, and instead
  relies on the PBKDF2 rounds parameter to control difficulty.

My original answer was based on the man page for ssh-keygen which states the following:

  -a rounds
                    When saving a new-format private key (i.e. an ed25519 key or any SSH protocol 2 key when the -o flag is set), this option
  specifies the number of KDF (key derivation function) rounds used.
                   Higher numbers result in slower passphrase verification and increased resistance to brute-force password cracking
  (should the keys be stolen).

Therefore a value of 200 will iterate the KDF 200 times. This is an equivalent of a work factor of 7.64, not 200 as you are expecting.

If you wanted your workfactor of 200 you would have to specify -a
1606938044258990275541962092341162602522202993782792835301376.

This won't work for two reasons:

Invalid number (too large) is returned.
You don't have a few universes of time to spare.

If you wanted to try 20 like in the example, go with this number, 1048576.

Basically you need the following two formulae:

  Work factor = log2(rounds)

  Rounds = 2work factor

Update

Therefore, if using the bhash version, divide the number from my working above by 64.

$ time ssh-keygen -o -a 16384 -f ./testkey -N password123
Generating public/private rsa key pair.
Your identification has been saved in ./testkey.
Your public key has been saved in ./testkey.pub.
The key fingerprint is:
SHA256:eU/T6ex/wDJNsb8soOzGN/uxup0Zdjthvxt1e23wb6c foo@bar
The key's randomart image is:
+---[RSA 2048]----+
|                 |
|              .  |
|               o |
|         .   .o. |
|        S . o++.o|
|         . +o++=*|
|        o . o*==O|
|         = oooB=X|
|        o..+**EBO|
+----[SHA256]-----+

real    2m17.181s
user    2m16.677s
sys 0m0.005s


Your process seems OK to me. Inspecting ARP traffic is the right thing to do, as well as making sure your NIC is setup in promisc mode and there's no firewall rules in the way of the attack. From memory ettercap will change iptables for you. Once everything is in place, you would definitely see your ARP table change according to the attack.

Another point of observation is a simulated victim on the network, whereby you have wireshark running and observe the effects of the attack.

As a proof of concept, however, I would instead make sure I understand the process and make sure it works in a simpler ethernet based network. WiFi technology enables other means by which to control layer 2 access and detect or sometimes deter ARP spoofing attacks.


Are photos on Facebook servers stored with the geotagging metadata in their EXIF headers?

Most big websites do filter out EXIF and geocache data. If you were to take a picture on your phone with geocache on, and then upload it to a ftp server it would still have the EXIF and geocache data. I'm almost positive facebook keeps a original copy of the photo and then just redistributes a copy of it onto their website with different headers etc. At the end of the day, you will not be able to get the data from a facebook photo.


Do you have buffer overflow protection enabled by default? What you are describing sounds like a canary value on your stack.


difference between public key and host key and security of host key

The host has a key pair, consisting of a public key and a private key. (It can have multiple key pairs in different formats; at the beginning of a connection, the client and the server negociate to determine a format that they both support.) There's a host public key and a host private key; there are also other key pairs (public and private keys) which are not host key pairs (in SSH, users also have key pairs, with the private key residing on the client).

At the beginning of a connection, the two parties establish a secure channel with a Diffie-Hellman key exchange, which lets them establish a shared secret key that eavesdroppers cannot find out. At this point, the client and the server have a secure channel (which cannot be tampered with by a man-in-the-middle without being detected), but they do not yet know who is on the other end of the channel.

Then the client sends a random value to the server, a challenge. The server replies by sending its public key as well as a signature of the challenge value. By computing the signature of the challenge value, the server demonstrates that it knows the private key corresponding to the public key that it just sent.
If the client has stored the host's public key in a file, it knows from that point on that the server is the same host that it communicated with before.

This mechanism, where everybody potentially knows the public key, one party sends a challenge and the other party responds to the challenge in a way that proves that it knows the private key (called a proof of possession), is a common use of public-key cryptography. It fully relies on the fact that public-key cryptography is asymmetric: knowing the public key doesn't give enough information to make computations involving the private key.


This sequence:

a  b  a  b  a  b  a  b
H1 E3 B8 W6 Z4 S0 X1 K4

b  b  b  b  b  b  b  b
S8 E3 O2 W6 G6 S0 C0 K4

a  a  a  a  a  a  a  a
H1 L3 B8 H5 Z4 D7 X1 Z8

tells that there is a key being used to scramble the input password, much like XOR, except most uses of XOR would output in hex while this output is base36?

This sequence

A  B  A  B  A  B  A  B
B0 Y1 V6 Q5 T3 I9 R0 E3

A  A  A  A  A  A  A  A
B0 F2 V6 B4 T3 X5 R0 T7

A  A  A  A  A  A  A
J0 B0 F2 V6 B4 T3 X5

A  A  A  A  A  A
D3 J0 B0 F2 V6 B4

makes me think there are different keys for different length strings.

So, I'm guessing the algorithm takes the plaintext 'a', takes the ascii value of 'a' (97) converts it to base36 (2P), XORs it with the respective value in the key and gives the base36 value of H1.

EDIT:  it doesn't appear to be base36.  Whatever the encoding scheme in use, I'm still guessing that it uses XOR.  It would help explain the behavior of zero since zero XORed with X is always X.

If that is true, the process is reversible and the keys can be found, removing the need to brute force or make lookup tables.


Security concept for password management

If I understand correctly, PHP is only ever executed server side. If I’m correct in that, then high value user secrets are going to be transmitted to your server even if encrypt them right after you get them.

At this point I should disclose that I work for a popular password manager, but I’m not trying to discourage competition. But I do recommend that you look at how other password managers work. Some of us document how we do things and why. I’m not telling you not try to build a password manager, but to understand that it is much harder than you might think.

I confess to having not taken close look at your design, as I stopped at PHP, but I also see your mention of CBC mode encryption. While there are legacy systems that still do so today, you should not design anything with an unauthenticated mode, particularly CBC.


How does Windows knows a particular software is an AV?

They need to register themselves with WMI (Windows Management Instrumentation), and store some information in the WMI repository. See here for details on how it works.


How to brute force only username not password?

If the system doesn't return a different response when you try to log in using a username, then in that case no, there's no way to see if the username you just tried is valid or not (if it exists, if it's enabled, etc). In that case, if you want to go at it the good old "bruteforce" way, you'll have to use lists of common usernames and passwords, and throw them at the login form.

As stated by @Rasool Ziafaty, doing a bit of recon about the system you're trying to bruteforce your way in can go a long way. Maybe use credentials from data leaks of services that are related to the one you're logged in, or using certain usernames or passwords that are more likely to be used on that specific system (ie: using Anime character names in usernames and passwords if you try to bruteforce a login form for an Anime forum).

This is why the reconnaissance phase in hacking is important and can be the longest one, because before attacking, you need to know what you're going to be dealing with.


Is it necessary to protect the Oauth2 return URL

By not protecting the return url you open yourself to the flowing scenario

Malicious user A registers with web application
Malicious user A obtains initial OAuth redirect to the third party service. He can do it easily by using user agent that does not follow the redirect automatically
Malicious user A tricks naive user B into opening the redirect url and authenticating with the third party.
Naive user B completes the process - your service gets the callback and assumes it is valid. It obtains access token and associates it with user A (the one that initiated the flow)
User A logs in into the web applications and asks for his data - web application calls service which calls third party and now user A sees the user B data

The third step is the hardest to pull but consider thew fact that third party will tell the user B that it is Your application that is asking for permission so more trustworthy it is the easier the exploit is.

The simplest way around it would be to have the callback url on the web application, authenticate the user and simply forward the call to the service.


How can I test QR Codes on security issues?

The QR code is just a piece of data. It's no different from a bar code - or a text string.

It encodes data. Your question is essentially meaningless, as the QR code will not have security issues. The use of it, the distribution of it, or the content may have security issue.

So the real issue is:

What does the QR code encode?
How are they distributed?
How are they used / read by the end users?

Except for the reading action (there may be security issues in the reader application), they're no different from a link in an e-mail or similar.


I'll try to explain using a few quotes from the OWASP page you linked. First, what is DOM based XSS?

  ...the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser.

Client side XSS does not always fulfill this definition. Even though the data is inserted into the page at the client, the data can come from somewhere else, lika an API response from the server:

  [For client-side XSS, the] source of this data could be from the DOM, or it could have been sent by the server (via an AJAX call, or a page load).

So (my highlight):

  With these new definitions, the definition of DOM Based XSS doesn’t change. DOM Based XSS is simply a subset of Client XSS, where the source of the data is somewhere in the DOM, rather than from the server.

An example of non-DOM client-side XSS would be if the client makes an API call, retrieving some untrusted data, and pass it straight to innerHTML without any sanitation.


Hashing the cookie token for persistent login

So long as your token is sufficiently long enough, I think you would be OK using simply SHA256. I'm not very familiar with PHP, but it looks like you are creating tokens of length 200, which would be more than sufficient. The reason that I would think that SHA256 would be OK is that the search space for a length token is so gigantic that it doesn't really matter how fast the hashing function is. There is no chance that it will be brute forced in any of our lifetimes.

However, from the programming side of things, I might still recommend using bcrypt. I'm not sure about the PHP implementation, but Bcrypt hashing is generally less difficult to screw up that straight SHA256 hashing, which makes it less likely for you to have bugs in your system. If you are using bcrypt elsewhere for password based authentication, then using it consistently instead of having two different methods for hashing makes your system less complicated and therefor also less likely to have critical bugs. If you are worried about speed, be careful not to optimize your system too soon. Implement it with bcrypt first and then do some profiling of your system. If and only if you identify your token hashing system as slowing down things should you think about using SHA256.


This is the simplest way of performing host discovery with nmap.

nmap -sP 192.168.2.1/24

Why does it not work all the time ?

When this command runs nmap tries to ping the given IP address range to check if the hosts are alive. If ping fails it tries to send syn packets to port 80 (SYN scan). This is not hundred percent reliable because modern host based firewalls block ping and port 80. Windows firewall blocks ping by default. The hosts you have on the network are blocking ping and the port 80 is not accepting connections. Hence nmap assumes that the host is not up.

So is there a workaround to this problem?

Yes. One of the options that you have is using the -P0 flag which skips the host discovery process and tries to perform a port scan on all the IP addresses (In this case even vacant IP addresses will be scanned). Obviously this will take a large amount of time to complete the scan even if you are in a  small (20-50 hosts) network. but it will give you the results.

The better option would be to specify custom ports for scanning. Nmap allows you to probe specific ports with SYN/UDP packets. It is generally recommended to probe commonly used ports e.g. TCP-22 (ssh) or TCP-3389 (windows remote desktop) or UDP-161 (SNMP).

sudo nmap -sP -PS22,3389 192.168.2.1/24 #custom TCP SYN scan
sudo nmap -sP -PU161 192.168.2.1/24 #custom UDP scan

N.B. even after specifying custom ports for scanning you may not get an active host. A lot depends on how the host is configured and which services it is using. So you just have keep probing with different combinations.Remember, do not performs scans on a network without proper authorization.

update: When scanning a network you can never be sure that a particular command will give you all the desired results. The approach should be to start with basic ping sweep and if it doesn't work try guessing the applications that may be running on the hosts and probe the corresponding ports. The idea of using Wireshark is also interesting. You may want to try sending ACK packets.

nmap -sP -PA21,22,25,3389 192.168.2.1/24 #21 is used by ftp

update two: The flags -sP and -P0 are now known as -sn and -Pn respectively. However the older flags are still found to be working in the newer versions.


Why does WiFi deauthentication need multiple packets to work?

It could be a layer 1 (physical layer) problem.

It could just be that the victim is receiving too many frames and drops yours, or perhaps the frame doesn't make it all the way to the target (obstacles, interference).

Or, maybe your system isn't staying on the same channel the whole time. If you are transmitting on different channels than the target device, it will not work at all, and if you are hopping channels, it will only work some of the time.


When using PKCE, are the state and nonce parameters still necessary protection from csrf and code injection?

My answer tries to give a short sum up of the most important information, based on Daniel Fett's article "PKCE vs. Nonce: Equivalent or Not?". For a detailed descirption of attacker models and in-depth attack descriptions, please refert to this article.
Protection against CRSF and Code Injection
PKCE and nonce both protect against most CSRF attacks, but there are edge cases where nonce provides less security, c.f. the previous mentioned article.
While Nonce and PKCE provide both safety against code injection for confidential clients, public clients must use PKCE to protect against code injection.
Why you might want to use an additional nonce
You may want to comply with the specification. Following the OpenID Connect Core specification, the nonce is required for hybrid and implicit flow.
Why you might want to use an additional state
The state provides security against attacker-forged error responses, which is not prevented by PKCE specification:

When state is used for CSRF protection, OAuth error responses from the authorization endpoint must contain this parameter as well, providing protection against attacker-forged error responses. If only PKCE or Nonce are used for CSRF protection, error responses can be spoofed. [df20]

However, by simlpy returning the code_challenge on error, PKCE can be hardend against this attack.
Attention using PKCE & state & nonce together!
It is totaly possible to use those three together, but there are some pitfalls regarding the verification.

To avoid sidestepping or downgrading the PKCE and Nonce checks, authorization servers and clients need to agree on and continuously use one of the methods. For deployments with both OAuth and OIDC flows, PKCE should always be used and Nonce can be used additionally for OIDC flows.

The implementation of a combination is more complex and thus might easier lead to implementation errors. The parameter to verify needs to be choosen wisely for every situation and security goal.


What programming language is Stuxnet written in?

According to some analysis, Stuxnet was written "was written in multiple languages, including C, C++ and other object-oriented languages." Source code is not available, but binaries can be found in the right places. You can try Googling around. I suggest confirming the hash with a reputable site.


Is it safe to use this online tool to generate my Windows Answer File?

You could look at the sourcecode of the script behind that website and see that it is completely client-sided and doesn't communicate with a server.

But just because the website delivered this script in that form to me does not mean that it will deliver the same script to you. Websites can easily deliver different content to different users. Also, there is no guarantee that this behaviour won't change tomorrow. But if the website is malicious, why would they target you but not me?

Another sore point is that the website doesn't seem to be available over https. That doesn't help a passive eavesdropper because, as I said, the file doesn't leave your computer. But an active MITM attacker could manipulate it in-transit to add a spying script. But that's a pretty unlikely scenario.

Bottom-line: It's probably safe enough for average people, but not safe enough for the paranoid. When you belong to the latter group and want to be completely sure, you could easily use it offline. Just safe the website to your local machine and open it from there. That way there is no way for the website to alter the script.


Search for the vulnerabilities for Chrome 54.

For example, there's a potential remote code execution on versions earlier than 62. If an attacker sends a specially crafted HTML page to anyone using the vulnerable version, he can execute code remotely, no download required. All your organization will be vulnerable to a Drive-By Download attack.

If the payload includes a ransomware, you have to choose between losing a lot of data and productivity time and paying perhaps a hefty ransom.

In some cases, enterprise products will not run on newer versions for different reasons. In this cases, you must make sure that the computers running the old versions are shielded from the internet and deployed on a quarantined area.

But it's strongly advised to update software as soon as possible, and in case of internet facing software (like browsers and email clients) as soon as any update is available.


Usually this is done by the SMSC.  There are several online services that allow you to specify a "sender" value.  This could be a word, rather than a number.  Some companies, like banks do this (i.e: "Citibank", "HSBC", ...).

For example, using a popular SMS service such as Twilio, they allow you to set the sender ID, number or word.  Obviously with necessary restrictions.


What kind of vulnerability it may have for known ssh-hostkey?

This script retrieves only the fingerprint of the public key (shown in your question) and on request the public key itself.

  Shows the target SSH server's key fingerprint and (with high enough verbosity level) the public key itself. It records the discovered host keys in nmap.registry for use by other scripts. Output can be controlled with the ssh_hostkey script argument.

source nmap.org

As the public key by definition is public this serves only informational purposes on the client and poses no vulnerability/security threat at all.

The informational purposes I mentioned might be in the line of:

prepopulating the list of known host keys for a SSH/SCP-Client
checking if the host keys of servers have changed (to trigger an investigation about the reason, for instance)

The fingerprint of a public key serves to identify that key (make it easier to recognize) because it might be difficult to see when the complete key (2048 bit = 256 characters) has been altered. The fingerprint (normally called a hash) will be completely different even if only a single bit has been changed.


How does Trusteer Rapport make accessing websites more secure?

Https actually doesn't offer the functionality that Trusteer provides. Trusteer has some very useful tricks to help protect you and your bank including:

low level hook in display driver which prevents screen scraping for the data you input to your banking website
validation that the website you think you are at is the one you are at
risk rating your online activity

And quite a few others including malware obfuscation as @paj mentioned. The main impact on the customer is that it really helps prevent an attacker compromising your machine with something like zeus getting all your banking details.


You would be very lucky to find a case where you can directly execute code via a simple coding error in Java. It is possible that a bug in the implementation of the JVM allows memory corruption through benign code, but at worst phenomenally rare.

However, even within the JRE (OpenJDK) a portion of the libraries are written in C, and therefore contain memory corruption vulnerabilities when used with untrusted data. Rendering a malicious JPEG would be the canonical example.

There are lots of non-memory related bugs, such as injection (HTML, SQL, LDAP, HTTP headers, etc), but those in general wont lead you directly to remote code execution.

A far too common situation is where a handy library deliberately executes remote code without deliberate being enabled by the application programmer. Examples given in Secure Coding Guidelines for Java SE (5.0) Guideline 3-8 / INJECT-8: Take care interpreting untrusted code are certain feature in: the scripting API, LiveConnect, XSLT extensions, Long Term Persistence of JavaBeans Components, Java Sound, RMI, LDAP and certain JDBC/SQL implementations. An application may deliberately load mobile code, which leads to a whole other world.


Why is ettercap targetting the whole network?

As explained here, some operating systems ignore some ARP responses. In particular, Linux will ignore unsolicited responses, but will use apparently legit request and replies from other hosts on the network. So the attacker must emit both fake requests and fake answers, and make sure that the target hosts see them nonetheless, which more-or-less implies the use of broadcast ethernet frames. By construction, broadcast frames propagate everywhere, so other hosts on the local network will be affected as well.

If you want to avoid poisoning host B while targeting the router, then you must send fake non-broadcast ARP responses that bear the router's MAC address (so that the router sees them), but they also must NOT bear the router's MAC address (so that the router does not ignore them as unsolicited responses), which is a bit self-contradictory.


There are actually a lot of other ways you can use XSS, for example you can convert characters to either their hex or ASCII equivalents, an example is here:

%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%22%48%69%22%29%3b%3c%2f%73%63%72%69%70%74%3e

which is the equivalent of an alert box that says hi

<script>alert("Hi");</script>

EDIT: This blog can be quite useful for bypassing filters: https://alihassanpenetrationtester.blogspot.ie/2013/01/bypassing-xss-filters-advanced-xss.html


Is this method of hashing passwords good? Node.js

Two issues I see:

the salt size is recommended to be the size of the hash, which would be 64 bytes in this case, however a 10 byte salt isn't terrible.
You only have one iteration of the hash.  You should have a minimum of 10,000 iterations (ideally more) of the hash, to help make it brute force resistant.

Having said that, why are you doing your own password hashing code?  Use PBKDF2, bcrypt, scrypt or Argon2.  You're reinventing the wheel for no good reason.


Why should the OPTIONS method not be allowed on an HTTP server?

An essential part of security is to reduce the attack surface by removing any functionality which is not needed. Usually this is also functionality which is less well tested and thus might be a vector for unexpected attacks. For example there might be restrictions/authorizations in the web application which are specific for GET, POST and which ignore any other methods. On the other hand part of the applications code might ignore the request method and thus access to protected resources might be possible using unprotected request methods. Thus removing OPTIONS, HEAD, TRACE etc makes sense in case these are not used.

But, OPTIONS might be needed in connection with CORS to allow cross origin requests. In this case removing it would impact functionality and thus it should not be removed.

In general it is a bad idea to just black list request methods which might be a problem. Instead white listing should be done, i.e. only allow request methods which are known to be handled properly by the application.


The man page says it:

  Note: there are no ciphersuites specific to TLS v1.1.

TLS 1.1 uses the same cipher suites as TLS 1.0, therefore OpenSSL does not make a distinction between the two. When it supports a cipher suite for TLS 1.1, it also supports it for TLS 1.0, and vice versa.

TLS 1.2 has its own set of cipher suites because these include the definition of the underlying hash function for the "PRF". The PRF is an internal construction in TLS, which is used to derive the master secret into actual encryption and MAC keys, and similar usages. In SSL 3.0, TLS 1.0 and TLS 1.1, the PRF uses a combination of MD5 and SHA-1; in TLS 1.2, the PRF relies on a specific hash function which depends on the cipher suite.

TLS 1.2 also adds support for cipher suites with authenticated encryption, i.e. GCM. These do not work with previous TLS versions.


How can I spoof source ip address while making a ping request from
  windows command prompt?

If you just want to change your local network address (e.g., change from 192.168.1.69 to 192.168.1.70) then you can set a different static IP address in the Windows "Network and Sharing Center". The exact steps depend on what version of Windows you are using, but should be available on google.

If you want to spoof your actual Internet IP address you may have to find and proxy server, log into that proxy server, and then ping from that machine.


Disk write-protection at the hardware level

Yes, it's called a write-blocker, or more officially a "forensic disk controller". The hardware doesn't cache any writes; it simply mounts the disk as completely read-only, with no physical way to write data to the disk.

If what you're looking for is a way to run an OS more traditionally with write capabilities, but restoring to a previous state after you reboot, then the best way to do that is with a live CD image. Alternatively you could set up a VM on read only storage, then boot into that. This could be done with read-only media like a CD or DVD, or with writeable storage through a write-blocker, or with a storage device which has a physical read-only switch.


Ebay sniping services - are passwords stored in plaintext?

We can't really tell you how specific services implement this functionality.

But we can tell you what is possible:

They store the credentials. This cannot be happening in hashed form, as the plaintext password is required. At most, it is stored in encrypted form, meaning that all passwords will be leaked if an attacker gains access to the key. If you have to enter your ebay password when signing up with the service, you can assume that this case applies. I would strongly suggest not to expose your password to third services.
They use the ebay API [*]. It uses tokens to authenticate a user, so the user doesn't actually enter their password on any third-party sites, but instead, those sites get an access token.

[*] This is speculation. Theoretically, it should be possible to implement sniping functionality via this API - it provides bidding and authentication functionality -, but I did not try to implement it in practice.


Do hacks of mainstream web applications tend to happen more from random attackers brute forcing or from targeted heuristic attacks?

I think the question in the title is better answered as: neither. The attacks against mainstream web applications are in my experience automated against flaws in the web applications and not on the passwords themselves. My company experiences attacks daily for Wordpress, Joomla, and other CMS systems. They are exploiting flaws (mostly SQL injection) to gain access to the entire system.

Attacks against users, I have no data on.

Targeted attacks against users fall into two categories: attacks against all users; and attacks against a specific user.

It makes sense that attacks against all users would as @reed mentioned, would be against the weak passwords or offline hash cracking.

In the case of targeted user attacks, the attacker would be targeting insecure password resets like in the Sarah Palin Yahoo Email hack or using metadata on the user to figure out what is likely for their password.


Why isn't cloud (AWS, Azure, GCP) metadata served over HTTPS?

The first point to observe is that if you click one of the above addresses you shouldn't be able to open it.  They all point (clearly in the case of Azure) to a link-local IP address.  These are reserved addresses in the space 169.254.0.0/16 that are not forwarded by routers, and crucially are only accessible from a given instance.

The second point to note is the data that the URL contains.  User data can be stored via these APIs, but it shouldn't be as it's not protected by any cryptographic methods.  Identity and Access Management (IAM) data can also be stored, and that is one of their strengths.  But wait!  Doesn't that mean any user with access can see data that allows them to do things they really shouldn't?  Well...yes.  However, that data is rotated on a relatively short time frame (~1 hour by default) meaning any reveal is limited, and the data can be rotated on demand.

As for the question as to why the URL is unencrypted?  Yes, there is still network communication taking place, even if it was hosted on a local network interface.  However, since it's only accessible from your instance, and any attacker looking to sniff network packets requires root access (for any reasonably normal scenario at least), it can't be intercepted by anybody except root - and if a user has root access to your machine, then it doesn't matter what data is stored in the credentials!  Trying to determine exactly how the metadata server is called is tricky, but it's likely that the data is simply stored by the physical host of the virtual machine, and authentication is done by the physical host simply returning information corresponding to the virtual machine that the request comes from.  In that sense, the requests do leave your instance, but they never cross a network to be intercepted, unless a physical host has been compromised - at which point, again, your system has been compromised anyway.  AWS or Azure don't seem to detail anything specific, but Google seem to back up this logical assumption:

  When you make a request to get information from the metadata server, your request and the subsequent metadata response never leaves the physical host running the virtual machine instance.

That doesn't quite explain it all however, and the real answer is speed.  Any additional handshake takes time, and if there is no practical need to having the data encrypted then why do it?  Securing it here offers no additional protection, and only serves to delay the many requests to the API.

Why then is it not a big worry that IAM credentials can be gained over these URLs in an insecure model?  The answer lies in two principles of least privilege and defence in depth.  First, the IAM roles assigned to the instances assigned should offer very limited capability, and ideally none to write or create new data or interfaces.  Second, your application can be built to prevent requests to metadata - if somehow an attacker manages it, other defence mechanisms can be used such as not allowing requests from servers other than localhost or having alarms set when requests are made with credentials outside of a certain time period.

As a useful case for why you would want to utilise a metadata server:
To be able to read or write to a database ordinarily requires credentials to be stored somewhere on the server, normally in a fixed file or memory out of public view.  However, IAM roles can be assigned to an instance to allow an application to fetch these credentials 'on the fly' without storing them, as well as being able to read them after the credentials are rotated on a frequent basis, thus automating what can otherwise be quite a tedious admin task.


What are the most relevant security events/incidents any company should monitor?

You should log everything and analyze anything. People trying to brute your sites and servers. All of these are relevant incidents as they pose a threat.

It's not relevant to say to what is an incident, as every attempt might be a relevant event some time. What is important is to catalog them with different levels. Some threats pose greater danger than others. Some of them might contain a lot of "normal behavior".
The thing is that some things only become relevant after analyzing over a longer period of time. You might notice one attacker is doing his best extra hard to get in.
You might get a hacked server and then you'd have to be able to go back and look for related security events to learn from the incident.


Why doesn't standard antivirus detect commercial keyloggers?

There can be a lot of reasons that the AV did not detect the software:

The code is signed by a reputable company (known good)
The binary is a known-good in the NSRL
The software does not match a malicious signature or attempt to make suspicious network connections

For additional confirmation, check the list of AVs at avcomparitives.org and test another AV solution on the same system and compare results.


What does the "configuration protection" mode do on Yubikeys?

From the YubiCo docs: "To protect against unauthorized update of a specific configuration, a protection access code can be added. Then, in order to update or remove this configuration, the corresponding access code must be used, otherwise the request is rejected."


... and made a ... request to the server presenting the encrypted
  cookie

Without knowing particular server, we cannot really answer this question. But if we assume that the server does not use any other information (user IP, user location, user device data), then very probably the server will accept such cookie and believe that the attacker is the original user.

If an attacker get access to user cookies, encryption prevents sensitive information from disclosure. But this is arguable if this is a good practice or not. Users can clean up their cookies regularly (many browser extensions clean up cookies every 1-2 hours or every time browser is closed). So more reliable way may be to keep sensitive data in the user account on the server side.

Encryption of separate cookies does not prevent from manipulation on the user side. If user knows the meaning of the cookie, then he can replace some cookies with his own cookies from the earlier sessions (if they are not expired), or exchange cookies with friends, or in some cases steal cookies. In such cases encryption gives no advantages.

Some developers encrypt cookies to prevent their modification by users. But actually such approach is error prone. Backend should never accept client data as is and should always validate them. That's why the encryption for integrity purpose makes normally no sense.

You said "over HTTP". Encrypted cookies are no readable for anyone who reads HTTP traffic. But if web sites uses HTTP, then it is very probable that the information in cookies was earlier provided by the user in previous HTTP requests to server without any encryption. Thus it is very probable that the attacker knows this information already and encryption of cookies gives only a false feeling of more security.

The users who know what are cookies, may think something like "they are spying on me". Thus encryption of cookies may break the trust in the web site.

"What is the point of encryption ...?" In many cases there is no point, developers just have a false feeling that this may give more security.


Is there a way to fool google with wrong location information

Your question could be split into several parts; if you use Google through a browser, and that browser is not controlled by Google (say for instance, you're using a private window in Firefox on a laptop), then a VPN should protect you; google will only have access to the information Firefox provides it.

If you're using an Android phone though, and are logged in with your google account, then obviously Google has access both directly to your phone, and whatever info your browser is providing google.

So what then if you use a secure browser to access the Google web page form an Android phone? Depending on what you need, a VPN might keep you safe enough here: Google may be able to see your physical location using GPS, nearby networks, etc, but may yet not be able to connect that info with any action you do in the context of your browser.

In other words, Google may know where you are, but have no idea that it is you who are doing whatever you are doing on www.google.com in your browser.

Based on you question (specifically mentioning GPS, etc), I'm guessing this distinction is not of any great significant to you, but thought it might be worth mentioning anyway.

Beyond that, I can basically see two options:

Use the settings under your Google Account to delete your location data, and choose to trust that Google really will delete your private data here. I would assume there are other settings too, to minimize the amount of data Google gathers about you, but again - it comes down to trusting Google in the end.
Get a different / extra (non-Android) phone, on which you can limit Google`s access to your data.

Neither option is ideal if you're even slightly paranoid, but if you want your phone to be able to connect to a network (cellular or wifi), then I really can't see any other option.


Do Auditors use a specific methodology or framework when auditing IT Backup policy?

It depends on the industry. Healthcare? Retail?

For instance, Healthcare has accreditation bodies like Joint Commission who primarily rely on HIPAA as a guide. Retail is expected to follow PCI standards to protect customer financial data (like credit card information).

Ultimately, all backup audits will typically look at several key concerns:

backup frequency
maximum Return to Operation time using current backup method
Data retention policies

some industries require a minimum retention time

Security of the backup media

physical security
offsite storage
encryption

Obviously, there may be other concerns, but those are the highlights.


I ran netstat and one thing that came up was MSN bingbot, does that mean my computer is being used as part of a Microsoft botnet?

As answered here, this IP address is in legitimate Microsoft IP space, and the msnbot process appears to be related to fetching Windows/Bing search results for the search functions integrated into Windows.

Such processed are only called "bot" because search engine crawlers are often called "-bot" (GoogleBot, etc.)


"Security through obscurity" usually refers to systems which violate Kerckhoffs's principle.

The key point is that it is the system itself that is obscured, or which obscures something. Secrets may still exist within that model, such as a password or a cryptographic key, but they are secrets which can't just be discovered by reverse engineering the system. Obscure things can still be discovered. Security through obscurity fails because people try to hide secrets in a box, but then give the box to someone who has the ability to get inside it, and just hope they don't try.

Another way to look at it is this: you can make a password secret and build systems where only the user knows the plaintext password, but it's (mostly) impossible to build a useful system where the code or algorithm itself is secret.

In the end, though, your question really boils down to the difference in language between "obscure" and "secret". There isn't an easy answer to this, but I would say that the effort or leverage required to expose a secret is greater than that of something simply obscure.


Why is WPA Enterprise more secure than WPA2?

All earlier answers are missing a very important step and its implication and are misunderstanding EAP.

WPA2-PSK (aka WPA2 Personal) basically does the same thing as WPA2-Enterprise from the clients perspective: The client associates to the access point, authenticates to the access point using the pre-shared key and access point creates a 256bit PMK (pairwise master key) from the SSID and the pre-shared key (PSK). This PMK is then used to encrypt data traffic using CCMP/AES or TKIP.

The important thing to note here is that all clients will always encrypt their data with the same PMK, all the time. So it's easy to gather a lot of data encrypted with the same PMK. Should someone break the PMK, they could decrypt all data encrypted with that key, past/recorded and future/realtime.

WPA2-Enterprise is only a little bit different behind the scenes, but the security implications are severe: The client associates to the access point, authenticates to the access point, who passes this on to a backend RADIUS server (using EAP, but that's not important here, so more on that at the end). When the RADIUS server has authenticated the client, it gives the access point an OK, plus a RANDOM 256bit pairwise master key (PMK) to encrypt data traffic for the current session only.

Well, that's quite a difference. Instead of each client using the same PMK all the time (the seed of which is known plaintext, because the SSID is used as seed!), now every client uses a different PMK, it changes every session/association and the seed is random and unknown. Not only that, but this PMK will be 256bit real entropy (not a hash from a usually much smaller password containing words), so dictionary attacks are useless.

Should someone break a particular PMK, they only get access to one session of one client. Also (if the right EAP method is used) they don't get access to the users credentials, since they where individually encrypted. That's a whole lot more secure.

Also remember that this PMK is 256bit AES, this is currently "uncrackable" (128bit is considered safe for the moment, but not for long). The fact that the PMK of WPA2-PSK (also 256bit) can be cracked comes from the usually weak passwords (dictionary attack), the known seed (SSID) and the fact that all clients use the same PMK all the time, so a lot of ciphertext of known plaintext can be captured.

So, then a little about the Extensible Authentication Protocol (EAP). This is often understood as a security protocol in itself, but it isn't. It's basically a standard for passing messages from a client wanting to authenticate and a server that authenticates. EAP itself has no security features, it just specifies how the client speaks with the RADIUS server.

Now, you can encapsulate these EAP messages in a secure tunnel. Like HTTP (an insecure messaging protocol) goes over a secure layer, SSL/TLS to yield a secure connection to a webserver. Someone said in another answer that there are over 100 different EAP "methods", some very insecure. This is true, because EAP is old there were encryption standards implemented that are sub-standard today.

But in practice, if you need to support recent Apple or Android machines/devices and Windows machines, there's only two options, because others are simply not supported: Protected EAP (PEAP) and TLS-EAP (well, I lied: really there are a few more, but they are basically identical to TLS-EAP in functionality and security).

PEAP is just like a https server, a secure TLS tunnel is setup between the client and the RADIUS server (protecting the entire wireless and wired path between them), the server presents a certificate to the client (in companies often signed by their own CA) and a secure channel is setup on the basis of this certificate.

If the client has the CA as trusted in their certificate store it sends its username and password to the RADIUS server. If the CA isn't trusted, the user gets a warning about the certificate as with a https site that has something wrong with its certificate. The credentials are usually protected with the (old and now weak) MSCHAPv2 protocol, but that doesn't matter, since everything is already protected by 256bit TLS. The MSCHAPv2 protocol talks with the RADIUS server using EAP.

An obvious weak point is that you could setup a false access point, present a false certificate of which you have the private key, and hope that some idiot user gets a warning about an untrusted certificate and just clicks "trust" (and that option is not disabled by an administrator). Then you could maybe capture the client's weakly encrypted credentials that are fairly easy to crack (I'm not sure about this, as I know MSCHAPv2 can be easily cracked if you have the WHOLE exchange, in this case you'd only have the client side as you couldn't send a valid nonce to the client to complete the exchange, as you don't have the real hash of the users password).

While this may get you access to the real network with a lot of work (and I doubt it, but if you must know, look into MSCHAPv2 at http://www.revolutionwifi.net/revolutionwifi/2012/07/is-wpa2-security-broken-due-to-defcon.html), it wouldn't get you access to any other wireless data, as they are encrypted with a different PMK.

But for companies this may still be a problem. Enter TLS-EAP. TLS-EAP is basically the same as PEAP with the notable difference that the client also has a certificate. So the server presents its certificate to the client which must be trusted by the client (because the CA is in the trusted store, or an idiot clicked "trust"), but the client also has to present a certificate to the server. This can be a certificate that's been placed in the cert store when the device/workstation was provisioned, but it could also be from a smartcard etc. The server has to trust this client certificate, or you won't even get the chance to present credentials.

As many of you may know, such 2-way authentication can also be done for HTTP over TLS, but this is not often seen outside corporate settings. In that case, too, you can't access the website unless you first show a certificate that's trusted by the server.

So now the fake access point isn't very useful anymore. You may get the weakly encrypted credentials if the idiot clicks "trust" and you then blindly accept any client certificate, but since you don't have the private key of the client certificate you don't get access to the wireless network, nor do you get encrypted wireless data of this or other clients still courtesy of the random session-based PMK. You may get access to some intranet with the credentials, but if they went to the trouble to setup a CA for wireless they probably require a client cert for that too.

In corporations it's common to have such a client cert on a smart card, which employees then need to access all resources: logging in, network resources, mail using smtps, imaps, pop3s, intranets using https, anything that uses TLS can be setup to require a client certificate. Usually it's as simple as putting it in the keyboard and enter a PIN, then windows will present it when demanded by a trusted server running TLS.

So, I hope this clarifies a bit. The scale goes:
"basically unsecured" (WEP)
"crackable with some effort" (WPA2-PSK)
"partly social-engineerable" (WPA2-Enterprise w/PEAP)
"currently secure" (WPA2-Enterprise w/TLS-EAP and similar)

There are ways to make WPA2-PSK somewhat more secure, in that it would take months to crack it instead of minutes (pre-computed rainbow tables) or hours (dictionary attack): Set your SSID to a random string of the maximum length (64 I think), since it's used as the seed for the PMK, and use a random pre-shared key (PSK) of the maximum length. If you then change the key monthly you can be reasonably sure that nobody has a current PMK or had/has access to your network.

Though you can't get rid of the fact that someone could have stored a months worth of data of all clients and reads that once they do get the PMK of that month (which can be done, as it's not a key with 256bit real entropy as you're broadcasting the seed used).

Another drawback is that you will have a highly unique SSID, one that your wireless devices will broadcast wherever you go. If someone has your unique SSID of your home network it's a piece of cake to look up your SSID at https://wigle.net/ and find out where you live. So you're basically walking around with your phone/tablet/laptop announcing where you live...

If you're privacy conscious it's maybe a good middle way to keep your SSID set to one that's common, but not in the top 30 or so (that way it's unlikely to have rainbow tables for it available online) and use a random PSK of maximum length. You lose some entropy though.

If you want the same security as wired, use WPA2-Enterprise with TLS-EAP. (Well, for now... There's nothing stopping someone from capturing and storing all the data they want and decrypt it all in 20 years when we can all rent time on a quantum computer and factor all keys in minutes.

The NSA is said to have built a datacenter to do just that, store anything encrypted they encounter until they can crack it, so that problem also affects everything on wires if it crosses the internet. If something needs to be secure for all time, use a random one-time pad that you exchange out-of-band :)

All that said, while I'm paranoid and want the best security and thus spend two days making WPA2-Enterprise/TLS-EAP work, this is probably out of reach (and overkill) for most home users. If you don't already have a domain controller or some other directory service on your network, experience with RADIUS and have all expensive pro wifi gear that an enterprise would use then you most likely won't get it to work. You'd be better off just setting up an always-on VPN and run that over your wifi, that gives you all the security and none of the fun debugging EAP.

PS. For the sake of simplicity I also left out the fact that the communication between the access point and the RADIUS server is also encrypted by a pre-shared key (called the "shared secret"). Afaik this encryption isn't any good today (uses MD5 which is basically broken) but since you put TLS over it anyway that doesn't matter. You can use a decent key size (something between 64-128 chars = 512-1024bits depending on the implementation). I always set the largest secret possible, it can't hurt.


What key needs to be used to compute HMAC?

In general, the advice is always to use two unique keys for two distinct functions.  The main reason is for separation of responsibilities.

Consider that your senior executives may have a very sensitive file that talks about an upcoming business deal.  It needs to be encrypted so that only the other executives can read it.

However, you may need to ask a system administrator, security reviewer, or arbitrator to periodically authenticate or monitor the integrity of the files.  If they're both using the same key, you can't separate those duties.


How to figure about the total amount of password combinations possibles that have salt values?

Salt is stored in plain, alongside the hash, so there is no need to test multiple salt combinations when the correct salt is known. This will make your calculations simple.

If there is no salt, one could crack all passwords in one brute force job.

But if each of the 4 users has a different salts, then it will take 4 separate brute force jobs.

So 296,653 years for a single salt × 4 unique salts = 1,186,612 years to crack passwords for all users.


Windows 10's (Windows Defender Application guard) VS Browser Sandboxing

This type of scheme protects against other web-based threats besides JS sandboxing. JS sandboxing is mainly about securing the tab from other tabs, it's not so much about protecting the computer, even though that's a side-effect when done right.

If you look at actual breaches, it's been a long time since a browser sandbox issues hurt users. It's what happens outside of the JS sandbox that burns them: flash exploits, PDFs, word macros, jscript shell, etc. By tying all those browser "helpers" into a separate container instead of the full OS, the attack surface is minimized. Other browsers just try to make sure it never even gets to that point. Maybe MS is unsure about locking down IE/dredge, so they lock down the space around it as well. Probably can't hurt at any rate.

It's somewhat akin to booting off a DVD so that bad things from the net can't hose the hard-drive's OS.


Why OWASP Top 10 (web application) hasn't changed since 2013 but Mobile Top 10 is as recent as 2016?

The reason for the delay is that there has been little change in the Web T10. As stated by Dave Wichers, the Web T10 project lead, on 30 June 2015:

  Historically, we've produced a new OWASP Top 10 every 3 years because
  this seems to balance the tempo of change in the AppSec market, all
  the work everyone does to map their tool/process/other thing to each
  version of the OWASP Top 10, and the effort required to produce it.
  We've been producing a new one every three years since 2004 (i.e.,
  2007/2010/2013), and so a new version for 2016 is due. (Definitely not
  happening in 2015).

  However, we've been thinking about what might change in a 2016 release
  of the Top 10 and we don't actually think it would change much, if at
  all, which is kind of sad actually. I suspect some Top 10 items might
  move up or down based on the vulnerability prevalence statistics that
  we would need to gather and process, but I have my doubts that any new
  vulnerability types would break into the Top 10.

  As such, given that we don't expect the list to actually change in any
  substantial way, the project has decided to defer the next update to a
  2017 release.

This table from the 2013 T10 Release Notes demonstrates the small change:

The changes were largely due to rethinking how to categorize the raw data, not due to significant changes in the data.

Some have postulated that the level of effort for creating the T10 was a factor for delaying it. While it is a lot of work, I do not think that was a major factor. The Web T10 is OWASP's most recognized project and always has lots of volunteers (I contributed to the 2007, 2010, and 2013 ones).

Speculating as to whether the same thing will happen for mobile applications, I do not think that is likely in the near future. Mobile technology is still in its infancy and subject to rapid change.


What does "Old" mean in "OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"?

Back in the day when the ChaCha20-Poly1305 cipher suites were introduced, Google rushed them out. There was no full IETF TLS WG review nor was there any formal process involved (which isn't yet finished as of 10th march 2016). However the draft for the cipher suites was brought up and was adapted over time.

Part of this progress is the formal assignment of "code points" (i.e. the bytes identifying the cipher suites), which was done only quite recently (around 1st march 2016) by IANA. The assigned code point for your cipher suite is 0xCC,0xA8. Here is where  the "old" comes into play. Your server advertises support for 0xCC,0x13 which is a different code point. To distinguish the code points Qualy's apparently added the OLD_ as prefix.

Additionally it may be the case that the TLS WG changed some things compared to the original ChaCha20-Poly1305 cipher suites (like nonce generation) which also require a different code point to avoid confusion by implementations which (still) implement the "old" suite.

  Is there any risk lurking there?

No. The old cipher suites are still good and will be for quite some time, you can however expect support by browser to be dropped "soon" for those cipher suites (within a few years maybe).


Is "Have I Been Pwned's" Pwned Passwords List really that useful?

Disclaimer: I am the author, creator, owner and maintainer of Have I Been Pwned and the linked Pwned Passwords service.

Let me clarify all the points raised here:

The original purpose of HIBP was to enable people to discover where their email address had been exposed in data breaches. That remains the primary use case for the service today and there's almost 5B records in there to help people do that.

I added Pwned Passwords in August last year after NIST released a bunch of advice about how to strengthen authentication models. Part of that advice included the following:

  When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to: Passwords obtained from previous breach corpuses.

That's what Pwned Passwords addresses: NIST advised "what" you should do but didn't provide the passwords themselves. My service addresses the "how" part of it.

Now, practically, how much difference does it make? Is it really as you say in that it's just like a one in a million front door key situation? Well firstly, even if it was, the IRL example breaks down because there's no way some anonymous person on the other side of the world can try your front door key on millions of door in a rapid-fire, anonymous fashion. Secondly, the distribution of passwords is in no way linear; people choose the same crap ones over and over again and that puts those passwords at much higher risks than the ones we rarely see. And finally, credential stuffing is rampant and it's a really serious problem for organisations with online services. I continually hear from companies about the challenges they're having with attackers trying to login to people's accounts with legitimate credentials. Not only is that hard to stop, it may well make the company liable - this popped up just last week: "The FTC’s message is loud and clear: If customer data was put at risk by credential stuffing, then being the innocent corporate victim is no defence to an enforcement case" https://biglawbusiness.com/cybersecurity-enforcers-wake-up-to-unauthorized-computer-access-via-credential-stuffing/

Having seen a password in a data breach before is only one indicator of risk and it's one that each organisation using the data can decide how to handle. They might ask users to choose another one if it's been seen many times before (there's a count next to each one), flag the risk to them or even just silently mark the account. That's one defence along with MFA, anti-automation and other behavioural based heuristics. It's merely one part of the solution.

And incidentally, people can either use the (freely available) k-Anonymity model via API which goes a long way to protecting the identity of the source password or just download the entire set of hashes (also freely available) and process them locally. No licence terms, no requirement for attribution, just go and do good things with it :)


Who: phone manufacturers, GSM operators or OS-creators (or whoever) should care that our mobiles do not to connect to rogue GSM towers?

International interoperability

Users - and thus also phone manufacturers and network operators - want the ability for phones to connect to all kinds of operators throughout the world. It's a clear benefit that if you take your phone, fly across the ocean, and turn it on - and it becomes able to receive and make calls. This means creating and using standards that enable the phone to negotiate a communications channel with any tower following the standard - including operators that were established after the phone was manufactured, including cell towers with technology generations later than when the phone was manufactured.

If I today launch a new cell operator in Wakanda, and put up generic tower hardware, then phones of visiting tourists should transparently connect to them, otherwise they'll be very unhappy that phones don't work in Wakanda. And the phone can't distinguish this scenario from me putting generic tower hardware next to your office. A global "whitelist" of operators would have technical challenges (how would an old non-smart phone w/o internet access know about my Wakanada operator that I launched yesterday?), and also require strong international cooperation, which is unlikely - for example, there are mobile operators running in disputed territories or conflict zones, where the local governments could prefer to "veto" them.

Internal roaming

An operator may be "renting" some towers from another operator - e.g. they want the phone to transparently connect to the other operator's tower. There also are virtual operators, who don't have any towers of their own, but they're paying tower operators for the provided service - and they want their phones to connect to all those towers where they have agreements. So phones connecting to towers not controlled by "your" operator is an important feature of the network that makes it work.

While you generally get notifications for international roaming, for this operators don't want you to get notified. One reason is that for branding reasons, the operator very much does not want users to know that they don't have direct coverage of that spot and you're actually using a competitors tower; the other is that in such cases simply driving down a highway would get you a dozen notifications as your phone repeatedly switches network cells.

Risk doesn't affect operators and manufacturers

Another aspect is that from the perspective of the operators and manufacturers, it's not a particularly relevant risk. It doesn't enable stealing of service or cause loss of revenue for the operators; doing so is illegal (regulated frequencies) so it's not going to be used by other companies to offer competing service; it doesn't easily enable fraud for commercial gain, so it's unlikely to be that frequently used by criminals to cause consumer backlash.

The most common abuse of fake towers is surveillance by law enforcement agencies, and the operators and manufacturers don't have a major reason to prevent that. Yes, there is also some risk to the users, but it's marginal enough to consider it as something that would be nice to fix, but not important enough to harm the (very important) interoperability while doing so.


Getting a SQL injection past a given regex

For complex regular expressions you should use a regex debugger.  However this regex is dead simple.  In short,  you need to find a query that is susceptible to injection without using single quotes.
lets assume the following query:

value = Regex.Replace(userInput, "[\n\r\t\']", " ");
sqlCmd = "Select names from mytable where mycolumn = '" + value1 + ' and yourcolumn= '"+value2+"';

now this can be exploited using the following PoC:

let value1 = \
let value2 = union select password from myusertable-- 1

This will produce the following query:

Select names from mytable where mycolumn = '\' and yourcolumn=' union select password from myusertable-- 1'

A couple of modifications,  most connection managers do not allow query stacking,  thus ; is just garbage,  the -- comment is actually a three character comment that ends with a  space so -- 1 will ensure the comment is respected even if white-space is truncated.  By replacing single quotes,  this sanitation method is better than addslashes,  as it is not vulnerable to multi-byte attacks see: addslashes vs mysql_real_escape_string


Is converting `<` to `<` sufficient to prevent execution of JavaScript from arbitrary HTML?

Inside the element, the parsing mode is in data state.  The only special characters that can escape data state are < and & (http://www.w3.org/TR/html5/syntax.html#tokenization sec.8.2.4.1).

If you replace all instances of < with &lt; then you only need worry about &.

In HTML4 and XML, you would need to consider which entity references are available for replacement, and whether any of them could be used to inject a script or other attack vector.  This could be a problem, for example, if the markup refers to an external DTD and the attacker can redirect a network download of the external DTD to one of their own choosing.  This is one reason that many XML and HTML parsers do not go to the network to resolve system identifiers.

However, HTML5 only permits & to be used for character entities, none of which can be used to escape data mode.

Hence, in the absence of bugs in the parser and in the markup, your acquaintance is correct.


Without reverse engineering the software and analyzing what all data is being sent, there is a minimum amount of trust that must be given to the application.
If you want to go by what they have publicly stated, the current EULA (as of 3/11/2021) states that "Acronis cannot decrypt your files if You have elected to encrypt."
This would imply that Acronis does not have a method of decrypting the (encrypted) data you send to them.
Additionally, in 2017 the GM stated that Acronis does not have the ability to decrypt data that users uploaded if they have encrypted it locally. Data uploaded in plaintext and encrypted by Acronis can (by necessity) be decrypted by them.


I don't remember IKEv1 itself being insecure, but it has been superseded by redesigned IKEv2 since 2005, so if the software supports both, I can't think of any advantage to using IKEv1 at all.

Your chosen PFS group (DH 1024-bit) is now considered to be insecure due to its size. The Logjam website claims that currently it's only breakable by "nation states", but that's already not a good sign. These days the minimum bit size for traditional DH seems to be 2048, and recently I've seen recommendations to turn it up to at least 3072 bits. You might even want to use ECDH.

IKEv1 with aggressive mode and PSK authentication is known to be insecure, as it allows attackers to capture the PSK hash and bruteforce the PSK:

https://wiki.strongswan.org/projects/strongswan/wiki/FAQ#Aggressive-Mode
https://www.giac.org/paper/gcih/541/vpn-aggressive-mode-pre-shared-key-brute-force-attack/104625
https://security.stackexchange.com/questions/76444/what-are-the-practical-risks-of-using-ike-aggressive-mode-with-a-pre-shared-key

But if I recall correctly, IKEv1 main mode does not support using individual PSKs for "roaming" clients as it has no way to distinguish them (except by IP address). So you should use IKEv2 which does support this because each client can send a different initiator ID (rightid).


RSA 4096 key size difference - "sig" and "sig 3"

The signature levels are defined in the man page under --ask-cert-level and --default-cert-level.  sig refers to cert level 0, "means you make no particular claims as to how carefully you verified the key."  sig 3 refers to cert level 3, "means you did extensive verification of the key."  So self-signatures, which are created at the time of key generation and which I believe are part of cross-signing, are level 3.  sig would have likely been made by someone signing your key or by you signing your key with another key of your own, because the default cert-level when signing, is zero.
If you ever want to get rid of a signature, run --edit-key.  Then, because signatures are associated with specific UID's you will have to select a UID associated with that signature.  (See the digit in parenthesis next to the UID when you run list.)  Select that UID with uid n, and then run delkey.  I don't suggest you delete the self-signatures though, as that will destroy the integrity of your key (see the link regarding cross-signing).