The thing about passive sniffing is that you don't get other people's network traffic unless you're either in a position to see that traffic due to network topology (e.g. you're sniffing a trunk port) or are doing network spoofing (e.g. ARP spoofing) that causes packets to be sent to your device.

If they're doing the latter, you just need to look out for ARP spoofing attacks. Many IDS solutions have features that can detect ARP spoofing. A really low-quality cheap way to catch rogue devices is to just look for packets coming from MAC addresses you don't recognise. Better solutions match up the known MAC addresses to physical ports and devices, so that unusual routing can be spotted quickly.

I can't think of any way to detect entirely passive sniffing per se, but it would certainly be possible to probe for rogue devices on your network by doing ARP scans, DHCP probes, or application-layer broadcasts (e.g. on 192.168.x.255) and looking for responses from devices that you don't recognise.


The key here is what you define as "every day use" - if you work in an environment where the data is sensitive, your security policy should take into account the risk from wireless interception and if appropriate, the use of wireless devices should be forbidden.

Faraday cage equivalents, such as shielded rooms/buildings may be appropriate but are obviously a much higher cost than just using a different keyboard/mouse.

If you have nothing majorly sensitive, be aware there are other potential issues - I have seen instances where another user started seeing keyboard input on their screen as the two machines managed to sync to the same wireless keyboard. This could cause some privacy worries :-)

If you are worried at all, go wired and you don't need to try and work out the risk/benefit tradeoff of wireless.


What is the purpose of including time as a part of random in TLS Client & Server Hello messages?

I'm not a pro nor am I working with this but I assume it might be something with a duplicate.

I mean if you just use 32 Bytes of random data the chance increases with time that you get the same random data.

But if you use 28 bytes of random data and 4 bytes of time the chance that someone gets the same 28 random bytes at the same time you get your 28 random bytes.

If im wrong please correct me since this is a pretty interesting question.


What are the (practical) dangers of writing your own login method?

The danger is expressed in Schneier's law:

  any person can invent a security system so clever that he or she can't imagine a way of breaking it.

The only way anyone knows to test if any given system is secure is to have lots and lots of clever people try to break it over a long period of time. You won't have that with a system you rolled yourself.


Metasploit over WAN (ngrok) - Specify different LHOST and LPORT for payload and listener in an exploit

It turns out I had to use another metasploit session to run multi/handler on the correct port as the first session was trying to bind my listening port wrongly as the ngrok given port and my listening port was different. All I had to do was to use another handler to listen on my loopback address + local listening port.


What's the difference between Comodo Premium and Positive SSL certificates

The $149 Positive SSL is a Domain Validated certificate.

It's a shame that the $404 Comodo Premium Wildcard product page doesn't say the certificate validation type, but according to SSL Shopper, it seems to be an Organization Validated certificate.


How secure are hashed passwords that are salted too?

A salt can make brute forcing much longer.  Assuming the attacker only has hashes, he will have to find out the hash algorithm and the salt.  You can sometimes tell the hash algo used by looking at the hash or at least narrow it down.  Next is finding the salt.  Usually a hacker probably has many hashes.  You can assume a user has the password called "password" or the hacker made their own account so they know the password, and start appending a salt until you get a match.  It's best to have unique salt per password to make this process more cumbersome, although they may focus all resources on an admin's hash.


Windows 7 ROP Functions mapped to 0x00########

Sometimes you just can't ROP if your vulnerable function breaks on null terminated strings.

However, you still have some other options:

Try to find a memory leak condition. You get at least one return address before the last null byte breaks your payload, and build a 2nd stage exploit
You could write a ROP chain including ASLR and re-based modules (if using mona, tell it to include modules regardless of their security: !mona -cm aslr=true,rebase=true and no nulls !mona -cp nonull) and shift relative base address offsets on the gadgets on the fly in some brute-force tries. You might get lucky and land just fine as 32 bits address space entropy is very reduced.


Both OpenJDK and Sun read from /dev/urandom, not /dev/random, at least on the machine where I tested (OpenJDK JRE 6b27 and Sun JRE 6.26 on Debian squeeze amd64). For some reason, they both open /dev/random as well but never read from it. So the blog articles you read either were mistaken or applied to a different version from mine (and, apparently, yours).

You can check whether yours reads from /dev/random or /dev/urandom by tracing it:

strace -o a.strace -f -e file java A

and look for the relevant part of the trace:

21165 open("/dev/random", O_RDONLY)     = 6
…
21165 open("/dev/urandom", O_RDONLY)    = 7
…
21165 read(7, "\322\223\211\262Zs\300\345\3264l\254\354[\6wS\326q@", 20) = 20
…

Don't worry, /dev/urandom is perfectly fine for cryptography.


Website security - should I hire a developer?

The most important thing to do when you use 3rd party applications like Joomla! is to always keep them up-to-date. Most attacks are targeting vulnerabilities which were patched long ago and only hit those people who neglect updating. So create a regular reminder in your calendar to check if an update is available for Joomla (as well as any themes and plugins you are running) and install it. Updating Joomla is very simple, because it can be done from within the administration interface. You don't need any advanced IT skills to do that. But it is very important to do this regularly!

Be wary of any plugins, themes, extensions and other addons which did not release any update for a long time. It means that either that addon is perfect and has no security problems, or that the developer simply doesn't care to release any more updates to fix security vulnerabilities. But the latter case is much, much more likely. You should also check the Vulnerable Extension List regularly and avoid everything listed there.

For more information, consult the security and performance FAQ on the Joomla wiki.

This actually applies not just to an application like Joomla but to your whole software stack, from operating system to webserver to PHP to MYSQL. OS and webserver also need to be configured securely. But when you use a hosted solution, then the provider will likely take care of everything except the applications you install yourself, so you likely don't have to worry about that.

But it's a different thing when you rent a virtual server which provides you with a naked operating system (or not even that) and expects you to set up everything on your own. In that case you are responsible for updating everything. When you require this for your project, you should consider hiring someone who knows how to harden a server properly, who knows which components need to be updated and how this is done. But the person you are looking for is not a software developer. It's a system administrator.


Doing 'the inverse' seems like the more secure solution.
If:

the backup function is the only function that the backup server
performs
all incoming connections to the backup server are blocked
all outgoing connections (except the connection to the server being
backed-up) are blocked
the only process that the backup server performs is the backup process
(by way of a cron job)
all other standard best practices are applied

then the backup server has a very small attack surface.
Futhermore,

if the backup server only has read-only access to the server being
backed-up

then even if the backup server is somehow compromised, it can't tamper with files on the server being backed up, or copy malicious files to the server being backed up.
Finally,

if the backup server makes incremental or differential backups

then even if the server being backed up were compromised, and files were tampered with, and backups of these files on the backup server were overwritten with the tampered files - 'pre tampered with' files would still be available on the backup server by way of the differential or incremental backups.
Edit July 26, 2020:
There has been a fair amount of news over the past few days about Garmin suffering an outage that has lasted over three days to date.  A number of news outlets are reporting that Garmin's network has been infected by the 'Wasted Locker' ransomware.  According to MalwareBytes, Wasted Locker is specially designed for each victim that it targets, and one of its objectives is to find and destroy all backups.  A backup solution like this one would be resilient to such an attack.


DNSSEC - Domain Name System Security Extensions

It is a set of extensions to DNS which provide to DNS clients
(resolvers) origin authentication of DNS data, authenticated denial
of existence, and data integrity, but not availability or
confidentiality.
It adds a layer of trust on top of DNS by providing authentication.

When a DNS resolver is looking for security.stackexchange.com, the .com nameservers help the resolver verify the records returned for stackexchange, and stackexchange helps verify the records returned for security. The root DNS name servers help verify .com, and information published by the root is vetted by a thorough security procedure, including the Root Signing Ceremony.

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


Encrypting intellectual property on client side

If your data at any point is in plaintext on user’s machine – you can’t secure it. You can do many things to protect it, but this would only slow down a dedicated attacker: obfuscating source code, encrypting data at rest, rotating encryption keys on server, etc. This is the territory of DRM, and there are many companies that will sell you their solutions.

Every DRM system would sooner or later be broken (if your product is worth it), game piracy shows this pretty well. Also, as you’ve pointed out, any strong defense like server-side crypto would be inconvenient for users (and probably expensive four you). I propose that valuing UX over IP protection would offer a much bigger competitive advantage than having an unusable app with close-to-perfect IP protection.

GitHub is a good example. The source code of the self-hosted enterprise version is encrypted at rest with a pass phrase "This obfuscation is intended to discourage GitHub Enterprise customers from making modifications to the VM. We know this 'encryption' is easily broken.". And despite having a large chunk of source code for github.com available to every enterprise customer, they’re still in business. Offering useful service was better for business than stringently protecting IP.

There are some other ways to protect against IP theft by your competitors. One classical technique is called “Paper Towns”. Since the maps of the same area would look very similar, cartographers started to put fake towns on their maps, and if your fake town shows up in the competitor’s map then you’ve got the proof of IP theft. Even google maps does this. Recently genius.com has shown that the lyrics in google’s search result were scraped from their site by encoding a message in alternating kinds of quotation marks in the lyrics.

You can protect antivirus signatures in an analogous way: by including some signatures of a fake viruses, and periodically scanning these fake viruses with the antiviruses of your competitors.


Openvas : Change in port list has unexpected results

Depending on the target system the port scan of ALL UDP and ALL TCP will take too long to finish, the portscanner will timeout and thus information about the portscan got lost.

Try again with a different portlist with less UDP ports. This can be configured in the GSA when creating a new Target via Configuration -> Targets.

A good start could be either "All TCP and Nmap 5.51 top 1000 UDP" or "All TCP and Nmap 5.51 top 100 UDP".

Disclaimer: NVT Developer @ Greenbone


I figured it out. Problem was that router checks Referer field in HTTP header. It should be set at http://192.168.0.1/Docsis_system.asp.

Anyway I didn't manage to solve problem with THC Hydra since specifying: :H=Referer:http://192.168.0.1/Docsis_system.asp
 made THC Hydra to do nothing, I checked with Wireshark and not even one request was sent. When I removed this field Hydra worked fine again but router wouldn't approve login without Referer field.

I tried with Medusa but it turns out that Medusa doesn't support redirect as response since router always sends 302 Redirect with selected page depending on if login was successful or not.

At the end I was forced to write dirty Python script that sends crafted HTTP request and everything worked out.


Best way to store a password for web app

The best way is to NOT store the password at all
Second way is to use a public and private secret to communicate with your service (things like oAuth and X.509 certificates)
Third is to encrypt the data on the phone itself

The problem is that anything that's outside of your control can be possibly subjected to tampering.

Facebook, Twitter, Google and some other tech giants created the oAuth standard of which oAuth-2 would do nicely for you.
You can store a not so secure secret on the phone to secure the authentication channel than set up a secret that is only known on the phone and server and it is specific for that communication only.

To the how to do this, without knowing what platform you are using, I cannot assist there.

Ask yourself why do you need to have access credentials that anyone can use. You should consider only credentials that can easily be revoked and are specific to that connection only (so a mobile token used on the desktop yields a lockout for example).


Why are PGP signatures not more widely used as an authentication method?

It's a chicken/egg problem.

Few people have PGP installed, so nobody builds systems which expect people to be able and willing to use it.

There are few systems which expect people to be able and willing to use PGP, so few people feel the need to install PGP.

However, what you see quite frequently in the wild are authentication systems based on X.509 certificates. It's rare for systems targeted at consumers, but for systems targeted at IT professionals it is quite common. And yes, it even works for websites.


How to tell if my MacBook is being spied on

Reduce your exposure
within System Preferences > Sharing close everything you don't need.
To give you a practical example, in my case, everything is off.
Shut off netbios:
cd /System/Library/LaunchDaemons
/usr/bin/sudo launchctl unload -w com.apple.netbiosd.plist
ps ax | grep 'PID|netbiosd'

This might highly reduce network noise.
Scan for residual crapware
See How to scan a Mac for rootkits and other stealthy security hazards
Detect basic data leak
This isn't bullet proof, but will detect most known data leak and call back home to help you focus on serious problems.
Little Snitch 3
This is a fantastic tool. It won't detect everything but will help you to reduce the abnormal traffic to a very reduced one.
Hunt within a reduced traffic
And now to the core business,
look at residual strange connections:
netstat -A
tcpdump -i en1
wireshark


Why is it required to HMAC riv in HDCP 2.3?

Let's first break down this (HMAC-SHA256(riv, kd)).

As described in RFC2104, an HMAC can be defined as follows:
HM AC=H(K⊕opad||H(K⊕ipad||text))
where H is the chosen hash function, K is the secret key, ⊕ is the exclusive OR symbol, || is the concatenation symbol and ipad, opad are constant values.

Based on this paper, building HMAC upon the backdoored Merkle-Damgård hash function yields a backdoored HMAC scheme, which is easily forgeable using the backdoor key.

Hence, it is easy to see that after the messages are prepended by k⊕ipad, they still lead to a collision in the inner hash chain of HMAC~h. Since the outer chain is equal for all messages, m and m∗ both have the same tag t. Putting differently, HMAC is not backdoor-resilient just because it uses a secret key. In summary, since an adversary holding a backdoor can forge a tag for a new message, HMAC~h is forgeable and hence not pseudorandom.

Please, refer to paper, for more information.

What is the HMAC?

  A HMAC is a specific construction for calculating a message authentication code (MAC) involving a cryptographic hash function in combination with a secret key. Input is a message and a key, output is the HMAC value. It is used to verify data integrity and authenticity of a message. The accompanying hash function for the HDCP standard is the SHA256 function which works with input blocks of 512 bits.

Why is it required in the HDCP standard?

  In the HDCP standard, the HMAC-SHA256 function is used for the locality check and the calculation of H (HMAC of km). The most demanding HMAC calculation concerning the timing is the one used in the locality check. As mentioned before, the NIOS processor has not enough computing power to complete a HMAC-SHA256 operation within 2 ms. That’s why this block has to be rewritten in VHDL. The HMAC for the locality check has a key size of 256 bits and a message size of 64 bits.

Function of the HMAC-SHA256 algorithm for the locality check:

  The locality check asks receiver and transmitter to calculate a HMAC value of a random number rn (message) and the pre-shared key kd. Before the calculation starts, the pre-shared key kd has to be xored with a pre-shared random number (rrx).
  The random number rn is sent in plaintext to the receiver, the receiver sends back the HMAC value. The transmitter checks now if its own HMAC is identical to the received HMAC.  Only  someone  who  is  in  possession  of  the  pre-shared  key  can  compute  the correct HMAC value. Additionally, it is impossible to conclude the key from the HMAC value, because the HMAC-SHA256 algorithm is a one way function.

Block diagram HD over IP system:

(Kindly provided by Lukas Itin's Master Thesis)


certificate usage for signing and encryption

A certificate is simply a public key that has been signed by a third party and is part of a key pair as you described. (or in the case of self signed certificates it is signed by the first party).  It is also worth noting that the sender only needs a keypair if you need authentication (ie, the receiver knows that the message came from the sender) in addition to confidentiality.

The sender would encrypt the message with a secret key and then encrypt that secret key with the public key of the recipient.  The encrypted secret key and encrypted message can then be sent and only the recipient can decrypt the message by decrypting the secret key for the message.  If verification is needed, the HMAC of the message can be encrypted with the public key of the sender and the certificate included with the message.  If the certificate is signed by a trusted third party, then the recipient knows that the public key is valid and can use it to verify the HMAC, thus verifying that the sender holds the private key which corresponds to the certificate.


Security "Threat" with Picture of Yourself?

Not sure how that long story relates to uploading a picture online.

The big dangers of your picture being online, is

the image has metadata that you don't want to leak (e.g., your phone geotags your location, so if some crazy person sees it they could figure out where you live), or
the image helps people from real life identify you and helps average users tie your semi-anonymous online behavior to yourself (could be problematic), or
the image posted online helps connect you to illegal/unethical activity (e.g., bank robber posts selfies with illegal machine gun used in recent robberies, or
the same image is used by you in multiple locations, easily found by using an image search tool like tineye, which loses your privacy.

For example, I probably wouldn't be able to identify you by your tiny gravatar thumbnail.  But if I examine the image URL: https://www.gravatar.com/avatar/6151310f6b2443a98ee2b0987ab01b7d?s=128&d=identicon&r=PG and change the size of the image to say 1024:

https://www.gravatar.com/avatar/6151310f6b2443a98ee2b0987ab01b7d?s=1024&d=identicon&r=PG

I could probably identify you.


Is it possible to set permissions on a per application basis?

Giving a linux-specific answer, I think SELinux (available in Red Hat like distros)  or AppArmor (available in SUSE and ubuntu like distros) is exactly the thing you are looking for.

To quote wikipedia's AppArmor page:

  AppArmor ("Application Armor") is a Linux kernel security module that allows the system administrator to restrict programs' capabilities with per-program profiles. Profiles can allow capabilities like network access, raw socket access, and the permission to read, write, or execute files on matching paths.

When you consider that almost all things in linux (sockets, shared memory, etc) have file paths, SELinux / AppArmor applies to most system resources.


You are far too paranoid.

The "eye" is simply what it is, a way for you to unmask the password in the password field. It is good from a security perspective to mask passwords as you are typing it to protect against shoulder surfers and the like. However, it can be annoying if you accidentally mistype passwords and have no way of verifying which character you got wrong especially when the password is 16-30 characters long as is common for network keys. Windows 8 simply gives you the option to unmask the password for your own convenience if you are sure no one can shoulder surf you.


Find out how my server is being used for DDOS attacks

It could be that someone is indeed using your instance either by rootkit or through some malicious PHP scripts. Your system is compromised now. Nuke it from orbit and restore from a trusted state (backup).

Make sure to keep your server updated and use long, complex password hashes. Disallow root login (only allow login by key for instance). Install a HIDS (host based intrusion detection system) and a rootkithunter. OSSEC is a good choice on Linux.


Locking the user account or returning the "Invalid username or password"

We have implemented an account lockout functionality where we can lock
  the user attempts after configured number of attempts.

I cant help but wonder wont this result in denial of service?Why not try limiting password attempts by a specific system.But still at the end of the day you can only frustrate an attacker in an attack like bruteforce.

  What do you prefer guys either return the message of account lockout
  which may give indication to user that username is correct only
  password is incorrect or return the generic error message of "invalid
  user name or password"

Its always told to only show a generic "wrong username or password" error message so that the attacker cannot better their brute force in anyway.

If the application is security sensitive.Add 2 factor authentication or use key based authentication


Will using a keyfile option to open a software such as KeePass defeat keyloggers and screen capture software?

Depending on what malware is installed on your system, like you said key loggers will log your master key back to the attacker but if an attacker wanted to gain access to your password database then he will just install a more sophisticated piece of malware to download your key file.


Set up an AP that indicates it is encrypted with WPA2 but in fact is open?

What you're seeing is the intended behavior. Clients won't be able to connect to your rogue AP as your AP isn't set up with the same PSK the real AP is, and clients shouldn't connect to a network that has the same name (SSID) but different security (unencrypted).

To answer your question, no it is not possible. Even if you manage to set up such an AP (pretty much impossible as the low level parts of Wi-Fi are handled in the NIC's firmware, so good luck getting that firmware to advertise it's broadcasting an encrypted network while in fact it isn't), the clients wouldn't be able to connect as they'll still try authenticating and will obviously fail because your AP won't be expecting the authentication frames as it's broadcasting an unencrypted network.


Choosing a group of symbols that contains a password

You are correct!

This techniques is there to prevent your passwords from Shoulder Surfing. As you said, it allows a user to prove the knowledge of his password without, revealing it to the person who is shoulder surfing the user. There are many other proposed solutions to the problem of shoulder surfing, including some Graphical Password schemes. This survey on Graphical Passwords contains few schemes which can be used to prevent shoulder surfing.


PCI-DSS Requirement for Application Level Security?

The advice your PCI consultant gave you does not match PCI requirements.  Ask them for a citation that "Application level encryption" is required across the network.  Any PCI consultant has to at least tell you what DSS requirement they're citing.  "Pictures or it didn't happen..."

Section 4.1 of the PCI DSS requires you to encrypt on untrusted networks; if your internal network is properly protected as per Section 1 then you are permitted to transmit unencrypted PAN data on it*.  And Transport level is explicitly listed as an appropriate protection:

  Use strong cryptography and security  protocols (for example, SSL/TLS,
  IPSEC,  SSH, etc.) to safeguard sensitive  cardholder data during
  transmission over  open, public networks.

When storing PAN data, you are required to protect it, which in the case of encryption section 3.4 states you should use:

  Strong cryptography with associated  key-management processes and
  procedures

Which may be where your consultant is coming up with "Application level encryption", but that's on disk, not on the wire.

*Note, even though you can go without encryption on the backend, you probably shouldn't.  Among other things, DSS 8.4 requires that credentials be encrypted during transmission, and if you're sending PAN data in the clear you're probably sending credentials in the clear.


Does HSTS prevents MITM using a valid certificate?

HSTS does not contain any kind of fingerprint (that would be HPKP instead). It only says that the site has to be loaded with HTTPS and that the certificate has to be trusted directly, i.e. no bypass of warnings by the user should be allowed. Insofar HSTS does not prevent MITM if the attacker can use a valid certificate which was issued by a CA trusted by the client.

It is unclear what you've exactly seen with Burp suite but maybe you were used to just bypass certificate warnings when using Burp instead of importing the CA of Burp as trusted, and bypassing certificate warnings no longer works with HSTS.


Is it safe to store a single symmetric key encrypted with several different RSA public keys?

Storing the same symmetric key encrypted multiple ways is not a problem, but using the same key for every client is, unless you have an unusually high degree of trust between the clients, as it enables the clients to decrypt each other's communication with server.

It would be more secure to generate a new symmetric key for each session, which is then encrypted using the clients asymmetric key, and stored for the duration of session.


Are non-English speakers better protected from (international) phishing?

There is a really, really good paper on this here.

Tl;dr:

95% of spam is in English
In f.ex. Germany only 17% of the spam is in German
In Scandinavia it's less than 1% in the local language

Conclusion I: Yes, generic phishing is mostly directed to English speaking people. I can only confirm that many German people will not even consider opening a mail with a non-German subject.

Conclusion II: The main factor for the phishers will be to gain proficiency at the target language. Target languages are English and other "first world" languages, but they are differently hard to learn. Since it's much easier to auto-translate and learn basic English than for example Icelandic, phishing will be much less effective on non-English speakers.

But: Spear phising is much more dangerous and will always be done in a local language, so statistics can't take that into account.


You seem to be partially describing a PKI, and partially describing an authorisation schema.

While I realise this doesn't answer your question, you might want to split these concerns:

describe an authorisation scheme based on the relationships you describe, and the rights they grant (I am fairly sure I have seen the sort of scheme you describe before, but can't think of a name for it)
and describe the authentication scheme you mention, based on keys, as well as the mechanisms for key issuance, etc.

You may find it useful to do a more formal requirement analysis to work out whether your approach works for your actual use cases.


Yes.Its being done. And unfortunatelly it's a pretty scary answer: All you need it's the phone number . It's the SS7 protocol has been exploited since 2014 and remains vulnerable to this date.
https://thehackernews.com/2017/05/ss7-vulnerability-bank-hacking.html

Basically SS7 (Signaling System 7)  it's a 70's  protocol which lets telcos operate globally. It's used to signal on which cell tower a mobile station (with a given phone number) it's connected.

So , if you are in Hawai  and someone from the US calls you, his telco would use SS7 to ask where your number is (even on which specific Cell ID). Then, when it gets all the routing data needed to communicate with Hawai's network, with the basestation you are connected with, it proceds to connect and diverges your traffic there.

But , as it was designed on the 70s, it wasn't done with security in mind. Unfortunately , SS7 doesn't require authentication in any stage of it's communications. Instead, its a trust-based system, telcos relies on each others. In other words, if you access the SS7 network, then you are a trusted source.

So , all your adversary needs is an access to the SS7 network, a Global Title (similar to a IP)  with roaming license, which can be bought  from a legit source such as a telco (or from a not so legit one from the deepweb).

Then the attacker sends fake SS7 messages to the  network, registering your mobile station to it's own controlled basestation. Once he did this, he MiTM you, logging all your traffic and re-sending it afterwards.

Best part of this ? We can do nothing to protect ourselves. The SS7 protocol won't be modified soon , 'cause all the economic impact it would have on the operating networks. It would require that all telcos upgrades at the same time, so communications aren't interrupted.

EDIT : forgot to mention. This could be exploited from any part of the world. No need to be close to the target.


Windows registry keys not preventing users/group enumeration via null session

From technet:
https://technet.microsoft.com/en-us/library/jj852184(v=ws.11).aspx

  This policy setting has no impact on domain controllers.


Canadian police mentioned a new line-trapping technique, but what is that?

Because there is no technical information, the below is pure speculation

I can think about 3 methods in which the attackers could have continued tapping the device and intercepting calls.

Method #1 - Ghost Cell Tower

Assuming that the attackers had physical proximity to the victim, there are tools that enable the interception of phone calls and other communications. some call them Ghost Cell towers, and the most known "solution" in the market is a stingray.
The mobile device is always looking for the closest cell-tower, and by leveraging that inherent "vulnerability" it is possible to replicate the cell tower interaction with the mobile device to intercept the calls. It's quite widely used by law enforcement agencies including the US and Canada, and the attackers might have gotten their hands on such a device, intercept the call and continue the fraudulent activity even when the victim called the police.

Method #2 - Roaming Enforcement

A harder approach, but one that is also widely used by attackers. again an inherent "vulnerability" in the cell networks is the ability to send a request to a carrier to move a user to a different carrier for roaming (in example, if you are flying abroad and the phone immediately connects to a foreign carrier, but you are still billed by your local carrier for those calls / data usage). In recent years there were evidences of attackers gaining access to less secure carriers (e.g. in africa) and transmitting a roaming request for a victim, to intercept SMS OTP requests mostly for financial hacking (e.g. bank accounts). if the attackers had a grip over a third party carrier, they could roam the device to that carrier and for a small period of time be able to route phone calls or intercept SMS requests. To date I haven't heard of that method being used for phone calls, but mostly for SMS phishing / fraud. You can read more about those attacks in the great blackhat presentation by Hendrick Shmidt, Daniel Mende and Enno Ray

Method #3 - Attackers infected the victim's device

If the attackers had access to the device through a malware of any sort, they were probably able to alter the phone numbers for the "police line" or route calls. I didn't see the article suggest whether the victim had an android or an iphone device but for android it should be quite easy. there are companies that sell such technologies to enforcement agencies (e.g. NSO) and a similar tool might have found it's way to the attackers.

You can also read a bit more on GSM risks in this article by the GSMA:
https://www.gsma.com/security/wp-content/uploads/2019/03/GSMA-Security-Threat-Landscape-31.1.19.pdf


Allowing root login, but denying any actual logins

It is easy to construct a password hash that does not match any password. One of many ways to achieve this would be to store a hash value along with a different salt from the one it was computed from. A password hash constructed that way would never match an actual password unless you constructed a collision in the underlying hash.

Regardless of the method used to construct such a password hash, the outcome is the same. The account will appear to have a password (to any program with access to check this), but regardless of which password is entered, it would be rejected.

Whether this approach is a good idea is a different matter. I would rather have sshd simply refuse password logins completely.


How to create a self-signed client-certificate without a CA?

Is there somehow to generate my own client-certificate that would be accepted by the server without any CA?

In general no. A client certificate is required by a server for authentication of the client. It is in a way similar to a username and password. The idea of creating your own client certificate which should be accepted by the server is similar to the idea that you can just make up your own username and password and the server will just accept it (without having a user with this name and password).

In practice there might be servers which don't actually care what certificate was send or accept even if no certificate was send. These are usually either misconfigured or require some additional authentication in case the provided certificate does not match their expectations.

If you run your own server you could of course configure it so that it accepts arbitrary certificates. And there are lots of sites out there which show how to create a self-signed certificates. The instructions there have nothing to do with what you show in your question though so I'm not sure what you really tried.


Is github doing anything to prevent e-mail scraping?

I think the answer is that spam filters have got better, and spam so wide-spread it's probably that you are getting the spam but it isn't being delivered to your inbox.


DB Passwords: More Secure in a PHP App's .ini config files or apache2 environment variables?

I completely agree with your opinion that it is no wise idea to have phpinfo() dump your DB passwords. An ini file seems to be a little bit better, your application can retrieve the passwords when needed. With current frameworks like Symfony this is the way to go. If you restrict access to the production machines to administrators in charge you have a limited circle of persons that could access the configuration files. Of course the ini files should not get stored in a public repository. The drawback is that the application itself, your webserver user must have access to the file and thus any PHP script could read and dump it.

This raises the question of wether you are willing to make huge efforts to improve security.

In the Java EE world you can apply the following concept. You deploy an enterprise application to an application server like GlassFish or JBoss. In the concrete JDBC configuration you set a placeholder for the password. The actual password can be stored within an encrypted password file for which the administrator has to enter a password upon startup of the server. Naturally this prevents a fully automated server startup. I personally cannot assure you that this is 100% bullet proof but it makes it more difficult for an attacker.

Another possibility is to "outsource" your passwords. You could use a password service (google for "Cyber-Ark", I think they have an API/SDK to connect own applications to their password vault) tool that stores passwords and controls access. Every time your application needs a password it must be retrieved from the service. Of course, someone who gains access to the API and the login data to the password service could request passwords, too. But with a separated service you have at least the option of logging access to have an audit trail available. Separation of duties: if the password service has another administrator it gets hard for one person to do things that are not allowed, or at least there's a chance to track these things.


Can a simple comment on WordPress harm my system (CVE-2016-4567)?

It can, but not directly. This vulnerability does not inject code on your webserver, rather it injects JavaScript that, when you visit the page, will be executed in your browser. What can happen then is that an attacker steals your session cookies and logs onto your wordpress website or redirects you to a malicious page with malware or a phishing website to lure you into disclosing credentials.


Why check to see if a password is already used by another user?

You misunderstand what remember does for pam_pwcheck; see the man page:

remember=XX
Remember the last XX passwords and do not allow the user to reuse any of these for the next XX password changes. XX is a number between 1 and 400.

With this option, pam_pwcheck will reject attempts at reusing a password which was previously used by the same user. It does not do anything cross-users; it will not warn you about whether your password of choice is used by anybody else or not.
In fact, such a check would be expensive to implement if proper password hashing is in place (with salts and many iterations for slowness, it would take several minutes to "try" the putative password for thousands of other users). As you say, warning users about how a potential password is already used by another user would be, by itself, a serious security issue; but it would also mean that the passwords are not stored properly, and that is another serious security issue.


Is sending the same e-mail encrypted and also unencrypted a security risk?

No, that's not a risk at all with any secure cryptosystem, especially a crypto-system that use asymmetric encryption (e.g., has public keys and private keys) like PGP.  If that was a risk, then any time you sent someone an encrypted message that they have permission to decrypt, they would be able to recover your private key by possessing both the decrypted message and the received encrypted message.

Even with symmetric encryption when used properly (e.g., in well-designed secure software), there will be no risk.  If you use symmetric encryption improperly there will be a risk.  E.g., if you use a block cipher in counter (CTR) mode with a repeated initialization vector, then this has the flaw of the many-time-pad.  That said, re-using an initialization vector in a stream cipher mode like this is a flaw in and of itself and doesn't require an attacker to have access to the plaintext, just multiple ciphertexts with the same IV -- though having a plaintext and ciphertext makes the attack completely trivial.


They fixed it when they implemented transport layer security, it provides end-to-end encryption (and authentication) between the browser and the webserver.  So, even though a "hacker" could intercept your traffic, it will be encrypted and stealing your credentials is a lot harder.  If the "bank site" doesn't use transport layer security, then that's a very poor practice.

Some systems prevent multiple logins from the same account, but that could also result in a "Denial of Service":

Do you prevent new sessions from being created
Do you break off the original session.

Either way, you could kick out the legitimate user.  Plus, one could be legitimately logged in from several locations (home, work and mobile).


Why did a subdomain from a trusted website download a file?

Nothing malicious is going on. The file is empty.

This happens when there is a misconfiguration of the webserver and instead of serving a page to display, it transfers the target as a file. In this case, there was nothing to transfer.

This sort of thing was a lot more common in the early days of the web, but I'm shocked to see it these days.


From your computer - Not any more than usual, no.

However the owner of the website you used could very easily have a copy of your password!

You shouldn't ever use an online password checker, as you have no control over where your data has gone.

As Neal stated in this answer on a very similar question:

  You're unnecessarily exposing your password to some site out there on
  the internet! Even local applications for password checking may be
  nefarious. Claims that the site uses javascript and never transmits
  the password over the Internet cannot be trusted. Some password
  strength testing sites are surely run by black hats, who just add them
  to their dictionaries along with whatever other information they can
  gather about you.


How does concatenating a user password and a YubiKey OTP work?

You are mistaken in your understanding. The security of an authentication system is defined mostly by the type of attacks it will protect against. Hashing the user password is very often part of authentication systems but usually not in the way you described.

Typically, in order to store  the password in a manner that is considered secure (salted, hashed, stretched) it will required the password to verify to be provided in clear text.

The security of the actual password while in transit is typically left to connection encryption (usually, TLS).

The addition of a OTP system does not change the above: validation of the OTP is typically done without directly involving the password.


In general the answer to “is it possible” will almost always be yes.
In the case you describe: is it practical that something malicious would be stored in the database? It seems unlikely, and wouldn’t be the first explanation I’d choose for the circumstances.
If you are particularly concerned then lookup historic vulnerabilities in the software, a typical search might be “firebird CVE”.
Some further ideas:

Assessing whether there are any suspicious saved functions should be trivial. Use a database manager and inspect any stored procedures.
Dump the entire database to a “safe” format and check the data   matches the expected format. For example, backup to ASCII SQL statements and restore to a fresh database.
Leave the database running for some defined period without making any changes (for example prevent your application from updating or inserting rows). Does the corruption still occur?
Turn on query logging, if possible. Do any statements affect rows which then become corrupted?
Check your application code carefully! A logic bug is a far more obvious cause of this kind of problem.

These ideas assume you are using the latest version of the database software.


Generating unique public-private key pairs

Just generate 100×10 key pairs and, unless you are using Debian’s (in)famous OpenSSL version, you are pretty sure that they are all different.


Is a QEMU live session less secure than a proper VM?

Testing from a "live" session VM might be slightly more secure, but considerably less thorough.

Live sessions use a RAM-based file system like SquashFS, aufs or UnionFS to simulate write access to the primary partition.  Malware can propagate by writing worms into the master boot record of the volume, which can be simulated (and scrutinized) from a qcow volume or raw disk image, but is completely absent in an ISO-9660 optical filesystem.

If I were you I would consider making a "starter" images of vanilla Ubuntu / Fedora, then make copies of those to test your malware.

If you're extra paranoid that the malware might "break out" of its VM, you could make sure you are running QEMU as an unprivileged user.


Is flash or javascript a bigger security concern?

The answer is: yes.  You should always worry about software.

"Complexity is the worst enemy of
secuirty"
--Bruce Schnieir

That being said, even if your machine is fully patched, one of the many Flash 0-days could still compromise the machine. XSS is exploitable regardless of if your machine is patched.  This flaw is usually exploited with JavaScript but it can be exploited with Flash as well, so having either of them would be a problem.  It's also important to note that about 90% of websites won't work without JavaScript, so disabling it is very problematic. GET based CSRF vulnerabilities can be exploited with pure HTML,  so even if Flash and JS are disabled you can still be hacked.
What I would do:
Use Firefox with NoScript. Even if JavaScript is globally enabled NoScript will block most CSRF and XSS attacks. Install an anti-virus and keep the machine up to date.


Necessity of physical access to air-gapped computers

What I think is important to point out about malware targetting air-gapped systems is that as much as these methods require physical access, it doesn't require that the attacker himself has physical access.

The idea is to spread the malware on as many computers as possible around the targeted system so that someone who is allowed to physically access it will eventually plug a contaminated USB key to the said system.

However, these methods seem to still require the attacker to be fairly close to the target to pick up the sounds produced. I think it is usually more efficient when the objective is to cause damage to the air-gapped system (erasing data, causing disfunction in automated industrial tools etc...).


How the 'probability of verification' is inversely related to the 'false accept rate'?

Ekhmm... they're not inversely related.  They're directly related: when one increase the other increase as well:

70% | 0.01%
90% | 1%

70% < 90% and 0.01% < 1%

This is really a machine learning question.  False accept rate is a false positive.  In other words, it is the chance that a random someone will verify his fingerprint as another person.

Assuming that Bob is an authorised person whose fingerprints we have loaded into our biometric system.  Now, we can tune the parameters of our biometric sensor to check whether Bob is Bob by using his fingerprint.  If we tune the sensor to be very very picky (acceptance threshold is low), Bob will have 77% of chance of verifying that it is himself on the first try.  If now Eve tries to impersonate Bob through this very picky system she has only 0.01% chance that her fingerprints will be recognized as Bob's on her first try.

When we lower the "pickiness" of the sensor (have a bigger threshold of acceptance), Bob will be able to verify that he is himself easier: he will have a 90% chance that the sensor will conclude that he is Bob based on his fingerprints (on the first try).  On the other hand, in this less picky system, Eve has a bigger chance to impersonate Bob: On her first attempt to read her fingerprints, there is a 1% chance that the sensor will conclude that Eve's fingerprints are actually Bob's (and authorize Eve as if she was Bob).

Any machine learning system that has an acceptance threshold parameter will perform in the above fashion.  In ML you always will have:

true negatives - An impostor's fingerprints are not Bob's
true positives - Bob's fingerprints are Bob's
false negatives - Bob's fingerprints are not Bob's
false positives - An impostor fingerprints are concluded to be Bob's

The perfect ML system would give only true positives and true negatives, but it does not work like that.  There is noise and noise will require some acceptance threshold.  A sensor that would not have any acceptance threshold would only provide true negatives and false negatives.  But that would e completely useless because no one would ever be authorised to do anything.

An acceptance threshold is an amount of difference that is allowed between the fingerprints stored in the database and the ones read by the sensor (and processed by the ML system).  Making this threshold bigger increases the number of true positives and false positives (remember that without the threshold we had only true negatives and false negatives).

In the context of the article "probability of verification" is the amount of true positives, and the "false accept rate" is the amount of false positives.


Requiring a pin instead of password for websites?

I don't think this is a great idea, especially as an alternative to a password (rather than in addition to a password):

A 4 digit pin by itself could be brute forced in ~100 days even if you had a 15 minute lockout for incorrect password attempts.
Entering 4 digits via your mouse on a screen is probably slower for most people than entering their password via their keyboard (which they're used to typing)
People are very likely to use some permutation of their year of birth or postcode as their pin

To make this secure a user would still have to log in normally from each machine, which sets a long expiry cookie then each time the user returns to the site they must enter a pin which sets a shorter cookie. This is really only protecting them from someone else using their computer while the user is still logged in via a long term cookie.

Depending on your goals I suggest the following:

If your goal is stronger authentication then I suggest using multi-factor authentication
If your goal is to make it easier for users to log in but you don't want to use a longer cookie then remember their username and not password (users can type their password pretty quickly)
If your goal is to prevent other people snooping on a users computer than this is better addressed on the user end by logging out when they leave their machine.


"ECDH public server param reuse" is when a server uses the same DH key value for multiple handshakes, instead of generating a new one for every handshake. The DH should be "ephemeral", that is why it's called "DHE" or "ECDHE", and this means the key is single-use and should never be reused.

Generating a new NIST P-256 ECDH or X25519 key is cheap, so there is no need to reuse it for performance reasons, but some SSL accelerator appliances do that. This is bad and they should be patched/configured to not do that.

@Mohamad

I have answered your question. It seems you do not know how TLS works. There are good explanations on this site about how TLS works. ECDHE uses a cleartext channel to establish a shared secret between two parties, then RSA or ECDSA signatures are used to establish identity of server or both server and client, then authenticated encryption (AEAD) is used to protect confidentiality and ensure data was not modified in transit.

"ECDH public server param reuse" refers to a small thing (about a single line of code) that is done wrong by a TLS server. It violates the forward secrecy property of ephemeral DH. It might be done on purpose, to enable decryption of traffic immediately by an appliance or later from an archive. It might be a performance optimization. It might be indication your software or firmware needs an update. It might be a configuration issue. Without more information, we don't know.

A TLS server has a great many lines of code, most of which are important to security. Unfortunately, it is possible to deploy an interoperable implementation that has some of those wrong (or missing). So the software/appliance seems to work (Chrome connects to such a server, or your client is able to connect to a standard server like Apache or IIS), but actually has a security problem.

A bunch of common errors/issues have names, and this is one of them.

If you know the general layout of an implementation, you should know where this line of code is. If you know the configuration API of a library or the configuration UI of an appliance, you should know where the toggle is.

Your question is a little of an XY problem. Tell us what you actually have and what you want, and we will be able to help you. For example, if you manage/operate a web site and you used Qualys SSL Server Test tool and got this issue, and you tell us how TLS termination is done for your site (e.g. version of MS IIS, version of F5 appliance, etc.), we might be able to tell you how to fix it.

I see you're an ASP.NET developer. Versions of MS IIS that have the "ECDH public server param reuse" issue do not have a configuration that can affect this. The software does this by design. The DH key is cached and regenerated periodically, but not for every connection, for performance reasons. Since the key is not stored on disk and is not completely static, it's not so bad, but it's not great. Possibly newer versions of IIS don't do this, but I don't know.


Bcrypt outputs a 192-bit result, no more, no less. This is inconvenient if you want a key longer than 192 bits, e.g. a 256-bit AES key. In that situation, I recommend taking the bcrypt output and hashing it with a secure hash function with a large enough output for the required key material length (e.g. if you need a 256-bit encryption key and a 128-bit MAC key, use SHA-384 or SHA-512). Otherwise, bcrypt is considered to be fine as far as key derivation is concerned.

(Generating a 256-bit encryption key from a 192-bit value does not make much sense; but using 256-bit AES instead of 128-bit AES does not make much sense either, practically speaking. The real weakness in a bcrypt-powered system, anyway, is that the keys come from a human-remembered password; bcrypt makes such a thing tolerable, but nowhere near as secure as a truly random 128-bit key, much less a 192-bit or 256-bit key. So if you need a 256-bit key for "administrative reasons", generating that from the bcrypt output and a hash function would create no extra actual security problem.)

Bcrypt has a minor quirk in that if you split a 192-bit bcrypt output into three 64-bit values, it is mathematically guaranteed that the three 64-bit values will be distinct from each other. Thus, the output of bcrypt can be distinguished from that of a random oracle by looking at about 264 distinct bcrypt outputs (for random 192-bit values, one may expect to encounter a block collision -- two of the three 64-bit values equal to each other -- after an average of 264/3 values). This is a very slight bias which has no practical consequence for security.


Gmail Accessed by Remote Acess User in China, Computer, VNC number used

I don't think a password change would remove its access. You should go to your account settings and remove its access there.

https://myaccount.google.com/intro/security?utm_source=OGB&utm_medium=act#connectedapps

This link should be the right place.


Client Hello message suggests cipher suite which is not in the list specified by setEnabledCipherSuites() method

The SunJSSE provider does not support SSLv2. It does support sending the first ClientHello message of the SSL/TLS handshake in SSLv2 format, though.

A client sending the ClientHello message in SSLv2 format is useful if the client is ready to actually use SSLv2. However, since SunJSSE does not support SSLv2, it sends the ClientHello in SSLv2 format for a weaker reason: this is to support old, buggy, legacy servers that know SSLv3 but expect the ClientHello in SSLv2 format, and simply hang up when faced with a "normal", SSLv3-format ClientHello (such servers exist because when SSLv3 was designed and deployed, SSL clients soon took to the habit of sending the ClientHello in SSLv2 format, so receiving an SSLv3 ClientHello was not really tested).

This sheds some light on what SunJSSE will do: it will send a SSLv2 ClientHello not to actually do SSLv2, only to be able to connect to some old servers that expect that message format and then proceed to use SSLv3. The SSLv2 ClientHello will also contain, in the list of cipher suites, the codes for the SSLv2 cipher suites -- that the client does not actually support, since it does not know SSLv2. These cipher suites are thus harmless: the client has no intention of using them and indeed does not know how to use them; it includes them just to make the ClientHello message more "SSLv2-like". The client strongly expects the server to respond with a SSLv3 ServerHello, the SSLv2 cipher suite being ignored.

Disabling support for that "SSLv2 ClientHello format" is still a good idea, for the following reasons:

Though the JDK from Sun/Oracle uses SunJSSE for SSL, another Java implementation may include full SSLv2 support (IBM's implementation is reputed to do that), and you don't want to inadvertently use the complete SSLv2, since it is weak in several ways.
There is a strong push to disable SSLv2 completely. Servers may cease to support the SSLv2 ClientHello message format. They might be some old buggy servers that require a SSLv2 ClientHello; but there also are some new, non-buggy server that don't support SSLv2 ClientHello; and the latter will be more and more prevalent as time passes.
Even when they do support it, that format cannot contain SSL extensions, e.g. Server Name Indication, so using the SSLv2 ClientHello format may prove limitative.

Nowadays there is a lot of talk about disabling SSLv3 too, and forcing TLS 1.0 or higher, so clinging to SSLv2 will make you look unfashionably archaic.


What are Implicit and Explicit Certificates in Public Key Cryptography?

A certificate establishes a link between an identity and a public key; the link is "guaranteed" by a Certification Authority with some sort of digital signature or another similar cryptographic binding.

The Wikipedia page on "implicit certificates" (pointed to by @Clayton) describes a concept where the public key algorithm is such that the public key, the key owner name, and the signature from the CA are somehow conflated into a single lightweight element. This concept seems to have emerged from the ECQV algorithm, and "implicit certificate" was coined as a sales pitch for that algorithm. Indeed, you can find the (slightly marketing toned) description from Certicom. It seems to be (possibly) subject to a host of patents (e.g. this one).

Though the concept is generic, I am aware of only one actual implementation, which is ECQV. It is not standardized and deployed yet.

In ECQV, the mechanics of the algorithm contrive to store into a single element both the public key and the sort-of-signature from the CA, while the element is no larger than the public key alone. A system trying to use the implicit certificate for a given user needs three elements:

the purported key owner identity;
the implicit certificate for that owner;
the CA public key;

and the ECQV algorithm takes all three elements to output the user's public key. This is implicit in that it is not known yet whether the certificate really exist; i.e. given an implicit certificate C and the CA public key P, the ECQV algorithm says: if the certificate C is owned by user U, then the public key of U is K. All the "implicit" resides in the "if".

A roughly similar concept, but more extreme, is identity-based cryptography. In ID-based crypto, more mathematics are thrown at the problem (pairings on elliptic curves...) so as to achieve an even better result: removal of the certificate. The certificate is so implicit that it no longer needs to exist at all. With ID-based cryptography, the user's identity is his public key. ID-based crypto is "better" than implicit certificates because it allows public key usage out of the blue. Consider for instance the problem of sending an encrypted email to somebody (let's call him Bob):

With classical (say "explicit") certificates, you have to first get Bob's certificate. E.g. Bob sends it to you (traditionally with a signed email) or your software finds it in some directory.
With implicit certificates, you still have to get Bob's certificate. It is shorter, thus "more efficient", but you need it.
With ID-based crypto, you don't need Bob's certificate. You already have it: it is Bob's name, i.e. "Bob". This is sufficient for you to encrypt and send the email.

It seems to me that the implicit certificate concept, i.e. ECQV, has trouble finding some market share; it is squeezed between "normal" certificates, over which ECQV only offers some perceived performance advantage (which, more often that not, has no relevance whatsoever), and ID-based cryptography, which offers some really structural advantages.

(It has been reported that Certicom and other patent owners still succeed in pushing their algorithms in some standardization committees through intense lobbying. I have not witnessed such things myself, though.)


How do I know if Google keyboard input is safe for use?

Valid concern for both Android and iOS now that Apple has enabled third-party keyboard options there.

For Android, there are several security solutions with firewalls that enable you to cut off network access to particular applications, even if full network access is allowed in the permissions of those apps. Some require root access and I cannot personally attest to the efficacy of these applications, but several work with vanilla Android and are very well regarded. That said, "well regarded" doesn't mean secure—these apps pose the same threats as the ones you're trying to restrict. If it functions without root access, then—for reasons beyond my familiarity with the platform—they require full network access themselves. For apps that do require root access, they get root access which is even worse (and the act of rooting itself poses a significant security risk for that reason). I suppose it's a question of which entity you trust more: Google vs. a third-party developer. This can easily spiral into a debate over which entity would be most fearful of the law and bad press, but of course that is not sound as a sole consideration in the scope of information security; an attack prevented today is better than an attack today, justice served tomorrow.

Not the easiest task to remove Google connectivity from your phone altogether, and the keyboard isn't going to be the bottleneck in a hypothetical breach on their part. Notwithstanding, there are keyboards that require neither root access nor any network access at all, although the user experience may prove dissatisfying/insufficient for your purposes. You can try Keymonk Keyboard which does not require any network access, but judging by the reviews it probably would not work that well for your purposes. One other option is to use something like LastPass or DashLane which I believe act as input methods like a keyboard does. Something brewing with 1Password that is worth looking into: they will fill in passwords without use of the clipboard (clipboard sniffing is another valid concern of this same nature, perhaps an even greater threat at the moment). All of those apps I listed could have their own ulterior motives.

At the end of the day, trust is more or less a (sad) fact of comfortable smartphone use today, and it can be difficult to determine who deserves it/who will respect privacy/whose infringements are most benign.


Barry Dorans, author of Beginning ASP.NET Security, provides some good material on the subject. I read his book and he covers a lot of ASP.NET MVC specific material.

If you are looking for a check list of application security controls, be sure to also check out the OWASP ASVS project.


How should I store a password to allow people to enter single characters from it?

I don't know, but I don't think a hash is practical here. Sure you can make a hash of one letter, but it's incredibly easy to brute-force if it ever leaks (like, a few microseconds at most); under 100 possibilities. Also storing all 3-char permutations hashed would be too easy to reverse.

It's actually interesting to consider this system from this angle. Usually you're calculating how many login attempts you would need in a worst- and best-case before an attacker knows the full password (or is able to login within 3 attempts), or how much security this system adds anyway (with MITM an attacker can still login). I never thought about what it meant for storing the login, and it's not looking good.


IDS in combination with vulnerability scanner

You've got a number of options.

The first and most common is to instruct the IDS to ignore attacks originating at the vulnerability scanner, and to configure the vulnerability scanner to correspond to the IDS.

The second solution, which requires a lot more work, but has a lot more value is to take this as an opportunity to validate the behavior of both tools and the network.  If you analyze the behavior of the vulnerability scanner and the IDS, you should be able to make a fairly precise prediction about the behavior of the IDS in response to the vulnerability scanner.  Configure your IDS to record the predicted events and to screen them from reporting, or set them to a very low priority.  For example, "I expect to see a port scan from IP Y between timestamp T1 and T2 every night that hits ports P1,p2", etc."  That confirms that both security tools are working, and should radically increase your confidence that your network has not been penetrated. (An adversary is going to want to disable your IDS and your vuln scanner; the adversary is very unlikely to do so in a way that will match your predictions). If your adversary is that good, you didn't have a chance in the first place.

Somewhere I have a information assurance/risk management/security management model. As your security practice becomes more and more sophisticated it should enable you to make better and better predictions about your network/environment.

And remember Wallace's first law of network security; if you don't effectively manage your network, your adversary will be happy to do so.


Can I securely keep the user logged into my local application AND use the password as a decryption key?

If you want it to be cross-platform, consider using a Python module which provides access to various platforms' existing built-in "keyring" systems. A popular one is called python-keyring.

In all platforms which have a keyring, it is stored encrypted with the user's login password and unlocked in RAM while the user is logged in.

(This isn't super-secure, as technically other programs can also request the same password from the OS... but practically all other "store something in RAM" options would have the same problem, so it's not a downgrade.)


Replace hashed password by public key generated from password

In theory, this is certainly possible - see this answer about doing the key generation. However, bear in mind that you're going to have to do all of this (hashing and key generation) on the client, which has several undesirable characteristics:

It's done in JS, which is slower than native code even on modern JIT-compiled engines, and you're doing two different things (password hashing and key pair generation) that are already slow.
It needs to work exactly the same on each client, and there's no standard JS API for generating a key pair from a given high-entropy seed (or for executing scrypt, for that matter), so you're going to have to supply all the relevant JS code yourself (and ensure it works correctly on all browsers that you support, with polyfills if needed for any library functions) rather than just calling a built-in API.
Since the hashing is done pre-auth, there's no secure way for the server to supply a salt (that an attacker couldn't get), so you're stuck with salts that might be unique (like username/email address) but are not secret and thus the password hashes can be pre-computed for users of interest. (On the plus side, the extra step of generating a key pair from this hash output provides an additional time cost against brute-forcing attacks).

So, all of this is possible. It is arguably a bit of a hack; there's no inherent browser support for what you're trying (even when it was recommended, the <keygen> element didn't allow supplying the seed entropy, and the built-in JS crypto API doesn't support that either) and you're kind of re-inventing public-key auth in a slightly weird way (using passwords for client-side key re-derivation, rather than just moving around a client certificate+private key). It doesn't add a lot of security either, as the scripts that do all this hashing and deriving and signing are going to be served by the server so an attacker with access to the server could slightly modify the scripts to steal the passwords/keys anyhow. But it could be done.
EDIT: You tagged this question "web-application" and referred to HTTPS, so I assumed your client was running in a browser. For a thick client, this is much less of an issue; not only do you have a much richer (and usually more performant and better-defined) API to draw upon, it's harder to surreptitiously serve the user maliciously modified code.


Why is the Signature Algorithm listed twice in an x509 Certificate?

I think it's a protection against certain kind of cryptographic attacks called "algorithm substitution attacks".

Please take a look here: Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute (RFC6211)

As briefly explained here: https://tools.ietf.org/html/rfc6211

  In X.509
     certificates, the signature algorithm is protected because it is
     duplicated in the TBSCertificate.signature field with the proviso
     that the validator is to compare both fields as part of the signature
     validation process.

I think it's exactly what you are looking for :)

Cheers !

Edit: Edited to add the "I think".

Edit 2: Found out that the question is duplicated...
From this post: https://security.stackexchange.com/a/24796
Relating the "TBSCertificate.signature" field:

  There doesn't seem to be much use for this field, although you should check that the algorithm identifier matches the one of the signature on the cert (if someone can forge the signature on the cert then they can also change the inner algorithm identifier, it's possible that this was included because of some obscure attack where someone who could convince (broken) signature algorithm A to produce the same signature value as (secure) algorithm B could change the outer, unprotected algorithm identifier from B to A, but couldn't change the inner identifier without invalidating the signature. What this would achieve is unclear).


BLE v4.2 Should be secure against replay attacks, but not secure against MitM attacks.
According to this post, it uses a counter along with signatures to stop replay attacks.
However, BLE v4.2 still (to my understanding) is vulnerable to MitM attacks, this post mentions that the attacks from WOOT 2013 still apply to Bluetooth 4.2.
This article talks about the security enhancements of BLE v4.2 over 4.1 and two possible attacks on Bluetooth 4.2.
There are also new attacks against Bluetooth user devices which have been discovered in the past month which I recommend taking a look at (both are :

BLURtooth: allows an attacker to perform device impersonation, traffic manipulation, and malicious session establishment.
BLESA: which enable an attacker to impersonate a BLE device and to provide spoofed data to another previously paired device


Anyway to Escape HTML Reading Input as a String?

It is fine if a web page does not filter strings like &lt; because it is escaped already. Browsers know that &lt;script&gt; is not an actual script tag, but just text.


If you use mysql_real_escape_string consistently every time you inject content into an SQL string literal, it's fine, there is no security issue.

However what time has taught us is that:

Catching every single place you inject into an SQL string literal is hard. In real world software unescaped cases are sometimes missed, even when the original coder understood SQL-escaping properly. Or raw injections are added later in maintenance. Or escaping is omitted where the coder thinks there is no possibility of special characters being in the string, but then later on something changes and that assumption no longer holds true.
Littering your queries with ...'.mysql_real_escape_string($value, $db).'... makes them tedious and difficult to read.
People still don't understand the encoding issue that real relates to, and consequently fail to set the charset in the right way (mysql_set_charset(), not bad SET NAMES).

We can spend the rest of time chasing these issues in code written with the mysql extension, or just push everyone to use parameterised queries instead, which work properly without requiring any deep understanding of string processing.


Preventing Session Fixation: MAC or Hash?

Q1 - Preventing Session Fixation - MAC or Hash?

Q2 - What is lost if the MAC is replaced by unkeyed hash?

Q3 - Is there a weakness with this approach (of replacing MAC with a hash)?

You identified the drawback of key management with using MAC across multiple servers whereas with unkeyed hash the only drawback is increased risk of session forgery due to the public nature of a hash function.  So in terms of the more secure option, the MAC option is better for preventing forged sessions.  However, in both cases as you pointed out, session fixation can still occur.  Other approaches I have seen to strengthen the session id is to adjust the session expiry and to include the user agent as input to the MAC function. I think Q1, Q2, and Q3 are partially asserting or assuming that using MAC in session id creation is the "solution" to preventing session fixation. I think that it is important to be mindful of a comprehensive set of strategies to prevent session fixation. However, a very important issue in the ASP.Net environment is to not reuse old session ids after a user which is a huge vulnerability for session fixation exploits.

See https://support.microsoft.com/en-us/kb/899918


Monitoring sender and/or receiver identity of a Whatsapp message?

WhatsApp's end to end encryption is based on the Signal protocol developed by Open Whisper Systems. An overview of the implementation of the protocol in WhatsApp can be found in this white paper.
According to the double ratchet algorithm documentation which is used by Signal:

The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key. Typically the parties will use some key agreement protocol (such as X3DH 1) to agree on the shared secret key. Following this, the parties will use the Double Ratchet to send and receive encrypted messages.
The parties derive new keys for every Double Ratchet message so that earlier keys cannot be calculated from later ones. The parties also send Diffie-Hellman public values attached to their messages. The results of Diffie-Hellman calculations are mixed into the derived keys so that later keys cannot be calculated from earlier ones. These properties gives some protection to earlier or later encrypted messages in case of a compromise of a party's keys.

It provides forward secrecy. It is a complex algorithm which has been studied by cryptographers and is being constantly improved.
As far anonymity of the users, it does require a phone number to work so I guess you are as anonymous as your phone number.


How can I reprogram a USB to appear as a CD or HD?

There are probably much better ways of doing it but if you look around (eBay) you can still get flash drives with the U3 firmware that allows flash drives to emulate CD ROM drives. The U3 software to set the drive up only works on Windows, but once it's set up it will emulate a CD drive transparently regardless of OS.


Is CBC mode for AES still safe to use in 2018?

It's a little hard to say without knowing your exact set-up, but CBC may well be fine, especially as it is available in .NET as is.

The main risk of CBC is the padding oracle attack here are some good links:

https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites/

https://docs.microsoft.com/en-us/dotnet/standard/security/vulnerabilities-cbc-mode

If you can be confident that an attacker cannot modify the cipher text then you should be alright. You could also go down the route of encrypt-then-MAC to ensure that the actual ciphertext was unaltered.


Blocking a redirect link in an iframe on a chat site

See if using X-Frame-Options header helps, as you want to block it within an iframe. For more information, please refer below link:

https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

You may also want to look at below link to understand how a URL Shortener works.
https://stackoverflow.com/questions/4572734/how-does-a-url-shortener-work


Preventing reverse engineering through obfuscation and LLVM

The slang for the tools you're looking for is "crypters".
Those tool are "compiling" your code using various techniques to the so called obfuscated code, there's no single solution and every tool may select its own weird way to obfuscate the binary.
As for other "dark" subjects practical explanations about those techniques are quite rare (have you ever found a decent reverse TCP shellcode writing guide?).

...but there are some thumb rules about obfuscation, for example encrypt any string which is embedded in the data segment in one way or another.
Note that as said by @cpast you'll never get perfect security against professional  reversers.

If you're interested in "perfect obfuscation" from an academic PoV I strongly advise you to read Prof. Ran Canneti's and Dr. Nir Bitansky's publications.


Who will notice a data breach more likely, me or an online password manager?

Unless you're actively managing your password database on a regular basis, an online password manager company is probably more likely to notice the "breach" (as you've called it) sooner. That said, even though they may notice it sooner, they may not take action or notify you right away - which would impact your ability to act. So, I'd say it's probably fairly even in a users ability to react to a breach event (locally stored vs stored in the cloud by a vendor) IF they are actively monitoring their password usage. If they're not actively monitoring their passwords/password manager, then the obvious answer would be that they'll act once they're informed by a vendor that a breach has occurred (hopefully).


Certificate validation Local DNS hosts file

The process of establishing a full trust chain between two system using TLS is the following:

1/ Create or obtain the root CA X509 certificate.
2/ Obtain all intermediate signing authorities.
3/ generate a leaf X509 certificate and have it signed by the authority immediately higher in the trust chain (either an intermediate CA or the root CA if you're using a simple model).

On the server:

Install the root CA in the trusted root certificate store (under windows, it is recommended to do so for the local computer account unless you know exactly which security principal will be used by the server app).
Install all intermediate CA certificates in the appropriate store (note that, depending on the server software, you might need to create a "chained" certificate file instead containin all relevant certificates in the chain as well as the private key for the leaf) (on windows same remark as for 1/)
Install the leaf certificate on the appropriate user principal store (in windows, again, typically the local computer "personal" store)

On the client:

Install the root CA in the trusted root certificate store.

Note that all certificate will need to exhibit the appropriate properties to be considered valid. The hard part is that this depends a LOT on the application, the usage of the certificate and how it was generated. Typically, for TLS, the leaf certificate must have a a subject.CN field or an a entry under SubjectAltName that matches the DNS name you're using to attempt to reach it (even if you're using a HOST file). Additional requirement can be placed by the client as well (for instance, Chrome will not accept certificate with SHA-1 signatures if their validity extend beyond 01/01/2017).

All this is independent on the name resolution process: it doesn't matter if the client obtains the server's IP address through a regular DNS resolution query or from a HOST file.


The simplest method of encryption  on a mysql server is aes_encrypt() using a randomly generated passphrase.

You should not encrypt user passwords,  passwords must always be hashed.  Passwords should be stored using bcrypt or sha256.


You might want to consider running an SSH server on the machine where the files that need to be backed up are stored (the source machine), then running a cron job on another machine (the backup machine), which connects to the source machine and copies (or rsync's) the files that need to be backed up.  You might also want to include a job on the backup machine that preserves changed files for versioning purposes (hard links are good for this).

By allowing connections from the backup machine to the source machine, but not vice-versa - this addresses the security concern that you described in your question.  Even if an attacker gains access to your source machine, he would not be able to connect to the backup machine to destroy your backups.  Versioning on the backup machine provides another layer of protection, in case backed-up files on the backup machine are overwritten by files copied over from the source machine which had been modified by an attacker.  Also, you can make the solution more secure by only allowing SSH connections from the backup machine's IP address, and requiring key-based authentication by the backup machine.


I note that you've gotten your answer from the comments, but I will chime in and create a proper answer to this question.

a CDN works just like a regular hosting company. You pay for diskspace, and the CDN makes sure the content you upload is available to you, and often distributed around the globe for faster access. Anyone who has the cash can register and upload their files on a CDN. Some even accept payment in Bitcoin, making it much less of a risk uploading malicious files.

CDNs rarely do any content filtering, and I would guess that very few do any proactive screening of the files uploaded. How should the CDN know if the uploaded file is malicious? One mans JavaScript may not differ to much from that of another, but one of them could be used with malicious intent while the other one just provide a slider for a blog. It's impossible to know for sure!

If you ever experience malware hosted on a CDN, you could send them an email to have it removed/flagged. (Like what MaxCDN does) But there is no guarantee that X CDN will remove it, and if they do, it might even be too late!

You could make a whitelist of well-known CDNs, that you know take quick actions regarding hosted malware, and that might protect you a little (and it's certainly better than nothing!). But this is no guarantee, and I would suggest adding additional software/hardware to protect against malicious intent, and not just a whitelist.


What are the security risks when using free Content delivery networks (CDNs)?

Since you are usually loading CSS, JavaScript and graphics from a CDN anyone with root-like permissions on the CDN servers (i.e. the company running the CDN) can:

replace your images with other ones, such as porn or other things you don't want your users to see on your website
replace your CSS to load said images, mess up the design, etc. - for IE and Mozilla/Firefox users the CSS could also cause arbitrary JavaScript code to be executed
replace your JavaScript to annoy your user, redirect to other sites, possibly load exploit code to infect them with trojans
(have technical problems causing your site's assets to load much slower than normally)

So all in all, only use a CDN you trust enough not to do those things.


Is a 512 bit RSA key secure when used temporary?

For signing only, a 512-bit RSA key ought to resist at least a few days, more probably a few weeks, even against determined attackers. This is still "reasonable" as long as you verify the signature "soon". You can imagine that from the point the public key was made public, you have a few minutes, at best hours of security, after which you must consider the key as expired and refuse to trust signatures computed with that key.

I find your use case a bit dubious, though. Generating the RSA keys will be quite expensive with regards to computing a signature. If you worry about signature size, then you should investigate DSA or its elliptic curve variants. ECDSA with a 160-bit curve will use 320-bit signatures (quite smaller than 512-bit signatures for RSA-512) while being substantially stronger (ECDSA with a 160-bit curve is still beyond the technologically feasible) and will still be competitive with regards to CPU usage.

Also, the hard part of asymmetric cryptography is key distribution (that's what PKI is about); if you generate many keys, you only make that part harder.


What is the best way to hand out passwords to a widely spread diverse employee base?

I would think that your only real way around this road block is with a pre-issued two-factor token, and an email with a one time password that has to be reset to the user's new password upon first login.

The one time password would be of no value without the two-factor token.


Can be Tor Colleration Attack used in court?

I don't know about the legal side, but law enforcement does this to find the bad guys. See for example

https://www.theverge.com/2013/12/18/5224130/fbi-agents-tracked-harvard-bomb-threats-across-tor


According to my experience, many people concentrate on preventing attacks in the first place and not on mitigating the impact. Therefore outgoing firewalls rules are often not a priority. Especially since you have to define exceptions for update servers, if automatic updates are desired. The list of IP-adresses has to be kept uptodate.

In my experience it is way more common for attackers to try to upload phpshell/perlshell/etc. in file upload forms. The attacker hopes that the files are stored in a folder that is reachable via the webserver with script execution enabled. Or to inject php code and remote includes into request parameters. Furthermore SQL and XSS attacks are quite common, so is phishing. Of course my observations are biases by the areas I am active in: web application and online game security.

That being said, it is of course still a good idea to have outgoing firewall rules.


Could a state actor MITM Let’s Encrypt certificate issuance to provide a cert they could more easily crack

The private key never leaves the server requesting the certificate.

The public key in the certificate has to match this private key.

The certificate returned is either invalid (public key not matching private key) or it has the same security. It might be signed by another CA, but that doesn't change the security. It might be considered invalid by some browsers.

If a attacker can MITM the actual connection between client and your server, then a state actor can interfere.


How can I track executed PowerShell commands within a network?

PowerShell Script Block Logging might be useful.

I haven't tried it yet, so I don't know how you can track user information, but it surely tracks the executed commands.

Here's a link to Microsoft Docs about how to enable it: Script Tracing and Logging. And here is another with broader information about auditing and logging:  Practical PowerShell Security: Enable Auditing and Logging with DSC. Otherwise just search for Script Block Logging.


Am I wrong to believe that passwords should never be recoverable (one way hash)?

For an ISP it is quite likely that they store your password in plain text or using a reversible encryption. This reversible encryption is not a hash as the answer claimed.

ISPs tend to not use one way hashes because a number of old protocols use the password as part of a challenge-response digest authentication.

Most notable is APOP, which is an extension to the old Post Office Protocol. In normal POP the username and password are transmitted in clear text, which is obviously bad. So people thought of an extension which prevented sniffing and replaying attacks: The server sends a unique identifier (for some strange reason it is called timestamp in the specification although it is more). The client concatenates this identifier and the password before calculating the MD5 hash. The server needs to do the same calculation, therefore it needs the clear password. This protocol is outdated; POP over SSL should be used instead. But it is still in common use.

Furthermore, ISPs often offer a number of services and getting all of them to use a central authentication mechanism is a huge challenge. So often passwords are replicated to those servers instead. Since this replication must be reproducible at any time for reliability reasons the clear text password is often stored. If a central authentication is not possible, it would still be preferable to store the different encrypted formats at the replication source instead of the plain password.

It is obviously extremely bad practice to give those passwords out to customers and first level support personal. Sending them in plain email makes it even worse.


Is there something like a “Windows Sandbox software Wrapper”?

What about using a virtual Machine (VMWare for example and creating an "Appliance") where you put the software in. This is not meeting "no need to have a sandbox software" however.


Is it theoretically possible to decrypt a file without the key/password?

- Show me the file contents.
- I cannot, chief ! It's encrypted !
- Dammit ! He wins this time.

An so ends the show, 5 minutes after the start.

TV shows don't show the "real world", and that's not to make a mockery; that's because shows aim at pleasing the audience, by providing them the sensations and feelings that they crave for. If it implies depicting events which are distorted, or even physically infeasible, then so be it. After all, Star Wars explosions make noise in the vacuum of space, and Godzilla is an ill-tampered radioactive lizard who breathes fire and insults a giant moth in Japanese while trampling Tokyo.

If encryption is done properly, then it cannot be broken upfront. But nobody said that police forces must act only within the formal mathematical rules of cryptography. In fact, they will first break your door at 06:00 AM and seize your computers and look for traces of the unencrypted data (e.g. parts of deleted files). After all, an encrypted file is useful only if was not encrypted at some point, and will be decrypted at some other point. Whenever a file exists somewhere in unencrypted format, it is prone to leak.


Best way to handle identity theft incident?

The best advice I can give you is to contact a lawyer or law enforcement agency in your country to seek advice. The laws regarding such matters vary from country to country so it is best to contact a professional in your country.

Legally and practically speaking, there isn't much you can actually do to stop the fraudster, especially if he is located in a country not known for their computer laws. You might consider changing your email address to something totally different and cannot be confused with, and inform all your friends/contacts about the possibility of them receiving a scam email.


Web Service Security Checklist - Tracing and Debugging

Yes, production servers should present little information outside their designed purpose to the outside world. Display of any kind of debug or trace information (intentional or accidental) could clue hackers/attackers into where to pinpoint an attack, a particular form box that maybe vulnerable and at the very least make finding a weakness in your site less difficult, and in the worst case open up a front door to any hacker familiar with the system/software should a noteworthy bit of information show up in the debug listing.

Production code is always recommended to run with debug and trace code turned off.

On the flip side it will make finding internal bugs more difficult if you are not doing internal checking and logging of errors, this is why you type check, argument count, length check, etc etc prior to running your code on untrusted data (from the outside world).

Failure to check your data is how hackers have bagged so many buffer overflow bugs and easily entered into many sites remotely. Should your checks detect something out of the ordinary then an internal log (not accessible to the outside world) should be generated and a email sent off to the administrator to indicate that the log needs checked but no indication of a problem should be made to the outside world, this is to avoid alerting a hacker of a potential goldmine, instead continue the process like everything is normal even if you don't actually process the data, the hacker will write it off as nothing interesting.


Prevent program from switching to user without password

...su -c ... theuser asks for teuser's password which is strange,...

There is nothing strange about this but this is exactly how su is supposed to work. It might be useful to make yourself more familiar with the concepts behind su and sudo and how they differ. In short: su allows user A to execute a command as user B provided that user A can also authenticate itself as user B. In this case A can execute anything as B because A can actually be B. sudo instead allows user A to run only the specific commands in the context/permissions of user B, which root as explicitly allowed A to run in this context. Thus the authentication asks for use A to make sure that this is the user which is allowed to execute this specific command as B.

  Is it safe to assume that it also cannot switch to theuser (without my explicit confirmation), even though it does not have a password set?

No, this is not safe to assume.
 su needs the password of B and if there is no password set you effectively cannot login as B (note that no password set is different from an empty password set). But, sudo only needs a successful authentication of A, which the user has. If the sudo permissions are set too broad then A might be able to break out of an allowed command to execute other code.
A classic example for this case is when A is allowed with sudo to edit a specific file with vi as user B. But, it is possible to execute arbitrary external commands from within vi. This means that once A is running vi within the context/permissions of B he can also execute any other commands from within the editor session and these will also run as B.

Apart from that there might be other attack vectors which allow privilege escalation for A. There were in the past enough bugs in the linux kernel or system setup which allowed such attacks. Thus, if you are not running a system which is still supported and keep it always up-to-date there is a fair chance that your system is affected by such security bugs.


Is it safe to do full disc encryption without ECC DRAM?

While the usage of error-correcting memory is a plus in preventing data loss due to sector corruption in the event of memory errors, it is not a requirement for full disk encryption.

Considering that most people do use FDE on computers that do not have error-correcting memory, it should be safe.


Is There a Library of Well Known Threat/Attack Trees?

Sadly, there is not a good free/community driven set. There's a set at the back of my book on threat modeling, and there's a set for sale via a company called Amenaza which I have not seen.

If there's something else, I didn't discover it when doing research for the book, and would love to hear about it.


MacChanger just changes the MAC. It is not meant to kick off another device on the network. The effect of having the same MAC as another device means that the 2 devices interfere with each other.

The simple way to ensure that the attacking device always "wins" the fight is to send an ARP broadcast at a faster interval than the legitimate device (e.g. every second). This way, when the legitimate device sends its ARP broadcast, the attacker quickly overrides it. Seeing these fast broadcasts is the primary way of detecting an ARP spoof attack.

To do this, you need one of the many tools available that perform MAC spoofing.