Authenticate tracking device with TCP server

Universally Unique ID v 4 with device pre registration sounds about right for this sort of application. When a device is in the factory you flash it's firmware with a UUID in it. Then you register that UUID with the DB. If the UUID exists, you generate and flash a new one.

This should be exactly what you want because now if someone grabs a device, they have NO IDEA what other devices have ever been created or how to impersonate that device without making as many guesses as there are atoms in the universe. Better yet you can encrypt this UUID in some sort of permanent user side cookie(Like JWT) that gets sent over and can only be decoded on the server and never needs to be modified by the client.

Now the best a person who stole one can do is to impersonate that device... and the question then becomes to what end? You've already stated if that happens you no longer care.

Device pre-registration is kind of similar to private client keys and serves almost the same role. They're just easier to implement since you don't have to run an extra check in SSL. You just have to decode the cookie that gets sent and never changed and verify it as the device in a data-store somewhere. Better yet you could even have a way to update the value of this cookie in OTA updates to change it every so often with some sort of garbage data that doesn't change the UUID.

And if you're worried about overhead, this can be done with a script that generates the UUID, check if it's in the database, regenerates if need be or stores, then generates the cookie, and finally modifies the firmware and flashes the value into the permanent cookie space. Then it just becomes a push button operation.


Storing passwords in Confluence vs a password manager

There are significant differences, both concrete and general, between the security provided by Confluence and a good password manager.

One specific problem is that Confluence doesn't encrypt data at rest. This means that someone with physical access to the disk can access the passwords. Even if you encrypt the disk, someone who gets access to the disk once the computer has booted (eg: via incorrectly configured remote disk access, or running a process on the server), can read the clear-text passwords.

Confluence also has many configuration settings that combine to grant or deny access to resources. Incorrectly setting these may lead to users unintentionally getting access to data.

Confluence also doesn't support common password manager features such as short authentication time-outs and masking passwords. The former is important because passwords are considered too critical to be trusted to the authentication of a computer or web portal such as Confluence. Masking passwords is important to prevent shoulder surfing which, in the case of a list of passwords in a table on a wiki page, seems a serious concern.

More generally, Confluence is a large and complex app that is written with the goal of sharing data. Password managers are very targeted apps that are written with the goal of securing data. As such, they are likely to have had more security-focused testing and code reviews, been written by more security-aware engineers, and to have been subjected to more security abuse by users. All of this leads to password managers being less likely to have vulnerabilities.


Well, from your question I assume you know what a line in /etc/passwd is, so your question strikes me as a bit of odd.  Unless, of course, you're going through some kind of test and don't really know your ways around a unix system and try to pass easily by cheating with us.

However:

That's a line in /etc/passwd that defines a user called backdoor, which prefers the bash shell.

The bad news is (aside from the fact that someone utterly stupid or an author of some kind of admin test used the name backdoor for this user) that this account uses  user ID 0 and Group ID 0, and home /root, and all three of those should be absolutely exclusive to root, the super user.

Your system has been compromised.

You'll need to remove the system from the network, do a postmortem analysis, and set it back up from scratch, hopefully closing the vulnerability you found in your postmortem analysis that allowed them do this in the first place. (Leaving the system up and trying to "clean it up" is a losing game because who know what other rootkits or backdoors they have planted).


In this case, you would probably be best off going for self-signed certificates for the clients, ideally using an internal CA which your server is aware of. This situation doesn't have the usual drawback of self-signed certificates giving a browser warning, since only the server is expected to connect to the clients.

However, you wouldn't want to rely on just the basic HTTPS authentication process. While that would provide encryption in both directions, it wouldn't let you verify that it is your server connecting - it could be any other device. You could instead use HTTP Certficate Authentication (see Certificate based authentication vs Username and Password authentication for a description) and make your clients aware of what certificate the server should present. This is somewhat more complicated to configure than normal encryption, since both ends need to be aware of the other. The advantage, though, is that you can be sure that only your server (or an attacker who has compromised your server and copied the private key file) can connect to the client devices.

Depending on your configuration, this process might not be needed in both directions - you might consider it acceptable for other devices to connect to the server, so connections from client devices only encrypt without needing to verify the server certificate, while the connections from the server need to be verified by the client, since it's the only intended connecting device. This would also simplify the addition of new clients - they need to know what certificate to expect from the server, but the server doesn't need to be updated to know what certificate they have. This would be a decision based on the specific situation though.


Network Security with EAP: PEAP and Phase 2: MSCHAPv2?

There really isn't enough information here to provide any definite conclusion. However, based on the information you provide, I would assume that the configuration is using PEAP with EAP-MSCHAPv2, which would indicate the MS-CHAPv2 is being tunnelled through a TLS connection and therefore should be reasonably protected against the vulnerabilities in plain MSCHAP.

Whenever you connect to any network, wired or wireless, there is a level of implicit trust - you are trusting that the system has been configured correctly by the admins, that the hardware is secure with up-to-date firmware and that the admins are trusted and know what they are doing. If you are not confident about all of this, my recommendation would be to consider your operating in a hostile environment and to take measures to reduce your exposure. Things you can do include

Ensuring you use different passwords wherever possible. Don't use the same password for your wifi connection as other sites/services. If someone is able to get your network credentials, they won't be able to use that information to access other data/services
Always use HTTPS rather than HTTP whenever possible. This will ensure that even if someone is able to sniff your network traffic, they only see encrypted data
Consider setting up a VPN or SSH tunnel inside your connection. For example, when I sometimes have to use an untrusted public wifi network, after connecting to the network, I establish an ssh tunnel to a trusted server and then forward all my traffic through that tunnel. As this tunnel is encrypted, the amount of information accessible by anyone sniffing the traffic is minimal. A VPN connection will achieve a similar result.

It may be worthwhile contacting your college IT department and asking to speak to someone about security and network configuration. They will probably be able to provide you with guidance on how to ensure your connection is safe etc. This may also help to determine how confident you are regarding the college setup etc.


What will I get if I "decrypt" a plaintext?

"Encryption" is a large term. In all generality, encryption takes an input message in some space of possible input messages; usually arbitrary "sequences of bits" with various restrictions on length, e.g. "length in bits must be a multiple of 8" (i.e. input must be a sequence of bytes), or "length must not exceed 245 bytes" (typical of asymmetric encryption with RSA in PKCS#1 v1.5 mode, with a 2048-bit RSA key). The output is al part of some space of possible output messages.

Computers being computers, both input and output messages are ultimately encoded in sequences of bits, so it may happen that input and output message spaces overlap, in which case you can conceptually take an input message (a "plaintext"), interpret it as an output message, and try to decrypt it. This is not necessarily possible: for instance, with RSA asymmetric encryption (PKCS#1 v1.5) and a 2048-bit key, input messages (plaintexts) are arbitrary sequences of 0 to 245 bytes (inclusive) while output messages (ciphertexts) are sequences of exactly 256 bytes, so it is not possible, in such a case, to try to "decrypt a plaintext": possible plaintexts are not long enough to feed the decryption engine.

When you can "decrypt a plaintext", what happens depends on the encryption system. Usually, when decryption works at all, what you get is essentially random-looking nonsense. In some cases, encryption is an involution (e.g. stream ciphers such as RC4 that work by XORing the message with a key-dependent stream), meaning that decryption and encryption are actually the same operation, so by "decrypting" the plaintext you are actually encrypting it.

However, it may also happen that not all sequences of bits of the right length are valid ciphertexts. For instance, consider a block cipher in CBC mode. To encrypt a message m, you must:

Pad the message to a length multiple of the block size, by appending between 1 and n bytes (n is the block size) with some specific contents.
Generate a new random IV of the same size as the block size.
Apply CBC encryption on the padded message, using that IV.
Output is the concatenation of the IV and the encryption result.

In such a case, when decrypting, not only must the length be a non-zero multiple of the block size, but after decryption, a valid padding must be found. If using the usual "PKCS#7 padding" (when adding k bytes, all added bytes have value exactly k), the probability that a plaintext of a compatible length actually decrypts to something with a valid padding is about 1/255. In that case, "decrypting the plaintext" will produce a decryption error 99.61% of the time, and some random-looking junk the remaining 0.39%.

Good encryption system include a MAC, in which case attempting to decrypt something which was not the result of encryption with the same key should result in a duly reported decryption error with overwhelming probability.

Summary: when you try to do something that does not make sense, you can obtain various results.


How does JTI prevent a JWT from being replayed?

How does a JTI prevent a JWT from being replayed?
  How often should the JTI field be regenerated? On every request? or only when a new token is generated?

I believe the answers to these two questions will depend on the application itself.

For example, if it has been programmed to only receive messages that have a unique JTI, then a replay of the same JTI can be ignored by the application.

The JTI would be regenerated in this case when it is valid for the same message to be repeated.


Is there a list of safe/normal/expected SUID files?

Is there a list of known/safe/expected SUID executables that one could compare against?

Not really, largely because all modern Linux distributions are package-based.  There's no single monolithic standard set of files, because installations vary easily based on which packages are installed.  That said, packages also provide listings of included files, making it easy for you to check whether a SUID binary is legitimately installed or not.

  Or a script that does this for you?

There are two simple ways to approach this - you can verify individual files against their package, or you can dump a list of SUID files out of all packages.

For example, let's say you're looking at /usr/bin and you're worried about the chfn SUID executable.  On an RPM based distribution, you can Verify the file against the package:

# rpm -Vf /usr/bin/chfn; echo $?
0
#

(The 0 exit code indicates that no discrepancies were found; the file is as expected based on the package parameters.  You can see a list of the checks that RPM Verify performs.)

On a Debian-based distribution (like Ubuntu, Mint, ...) you'll be dealing with deb packages, which have a less centralized approach than RPMs.  The same overall effect can be achieved after installing apt-file and debsums:

# apt-file search /usr/bin/chfn
passwd: /usr/bin/chfn
# debsums passwd | grep /usr/bin/chfn
/usr/bin/chfn                                           OK
#

You could write a tool to enumerate package listings to find SUID files, to verify them, and to compare your list against a list of what's actually on the file system via find.  (Note that with RPM, at least, you can verify all files in all packages with just rpm -Va, but you'll find that's a bit chatty and more than just SUID files).

For example, you could loop over all installed packages (rpm -qa) and, for each package, list out the SUID and SGID files:

# rpm -qlv util-linux-ng-2.17.2-12.28.el6_9.2.x86_64 | awk '$1 ~ /s/ {print $0}'
-rwsr-xr-x    1 root    root                    77560 Dec  5  2017 /bin/mount
-rwsr-xr-x    1 root    root                    53480 Dec  5  2017 /bin/umount
-rws--x--x    1 root    root                    20184 Dec  5  2017 /usr/bin/chfn
-rws--x--x    1 root    root                    20056 Dec  5  2017 /usr/bin/chsh
-rwxr-sr-x    1 root    tty                     12016 Dec  5  2017 /usr/bin/write
#

and use that to build your list of expected SUID files.


Antivirus being disabled by unknown source or application

It's worth noting that scanning your system with an anti-malware/virus application does not guarantee the detection of a virus.

It is possible that you have installed what is known as a trojan. This is a piece of malware that is disguised as a regular program or application. So think, have you installed any software from untrusted sources recently? Including pirated software.

If your computer IS infected, then your safest bet is to completely wipe the machine and start over. I imagine to disable your anti-virus this malicious application must have administrator access on your machine, either through some exploit allowing for privilege escalation or through such privilege being granted to the application by the user.

As something of an afterthought, have you tried checking your windows defender settings? I am aware that in some cases in the past my windows defender has attempted to disable my third party anti-virus software and configure itself as the primary anti-virus solution.

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


Can the client communicate with the AP after a KRACK attack?

The KRACK paper states:

  We first establish a man-in-the-middle (MitM) position between the supplicant and authenticator.

And:

  A second minor obstacle is that we must obtain a MitM position between
  the client and AP. This is not possible by setting up a rouge AP with
  a different MAC address, and then forwarding packets between the real
  AP and client. Recall from Section 2.3 that the session key is based
  on the MAC addresses of the client and AP, meaning both would derive a
  different key, causing the handshake and attack to fail. Instead, we
  employ a channel-based MitM attack, where the AP is cloned on a
  different channel with the same MAC address as the targeted AP. This
  assures the client and AP derive the same session key.

(Emphasis mine)

From what that section of the paper says, there is a MITM between the supplicant (client) and the authenticator (AP). Furthermore, there is a diagram on the paper (page 6) which shows the MITM connection involving the supplicant, adversary and authenticator:

The paper also mentions how the authenticator will accept any replay counter:

  However, a careful inspection of the 802.11 standard reveals that
  the authenticator may accept any replay counter that was used in
  the 4-way handshake, not only the latest one.


There are a large number of open source hotspot software suites available. EasyHotSpot has an integrated billing system.  I have not audited these applications and i have no idea how secure they are.

From a security perspective, "captive portals" break ssl pretty badly. Convergence,  which is the Anti-MITM addon for firefox will detect captive portals as being a MITM attack.  Which is true,  it is a MITM attack thats trying to get money from you.

There is a fundamental flaw in all of these "pay to use" wireless networks in that they are authenticating paying customers via a MAC address. Unfortunately with wireless networks,  the attacker can see every user's MAC address and just spoof their own.

Other security concerns are that non-paying customers should never be able to route packets to the open Internet.  Sometimes these networks will route DNS traffic,  and its possible to route IP over DNS.  Or route IP over just about any other protocol (In fact I can't name a protocol above layer 1 that can't be used...).

A PHP remote file include vulnerability in your captive portal software could allow the attacker to gain access to the open Internet (as well as remote code execution on your box :-).  SQL Injection should also be a concern as it could an attacker to authenticate as a paying customer.


Decryption on AES when the same key and IV are used

What happens here depends on the mode of operation. As a basic rule, knowledge of the messages will not allow you to recompute the key itself, but it may give you enough information to (instantly) crack any other message encrypted with the same key and IV.

With CTR mode, a key-dependent stream is produced by encrypted the successive values of a counter, and the counter starts at the value given in the IV. The actual data encryption is performed by XORing this stream with the data to encrypt. If the same key and IV are used, then you get the same stream, so you are in the conditions of the (in)famous two-times pad. Without knowing the key, you can still compute the XOR of any two messages, which is often enough to crack them, by exploiting their internal structure. Once one of the messages is known, this reveals the key-dependent stream (up to the message length) and this allows for immediate decryption of any other message (up to that length) encrypted with the same key+IV.

OFB mode is in a similar situation: it produces a key-dependent pseudo-random stream. So it can be broken with the same level of ease as CTR.

With CBC mode, things are a bit harder for the attacker. If the messages start with the same bytes, then you will be able to see it. After the first distinct bytes, decryption becomes much harder. This is because, in effect, each block in CBC encryption is used as IV for the remainder of the message, and encryption of data with a block cipher tends to produce properly distributed IV for CBC. Generically, CBC requires a uniformly random IV which is unpredictable by the attacker, but in your situation you envision a passive-only attacker, and against such an adversary, an IV selected by encrypted a known data block is good enough for CBC, as long as the IV source is not reused; this is what you obtain with your messages, beginning with the first block at which the messages differ.

CFB mode is somewhere in between. If two messages begin with the same n bytes, then the encrypted messages will begin with the same n bytes too; then, for the remainder of the block containing the n+1-th byte, this is two-times pad. For the subsequent bytes, the streams have forked and attacker's power stops.

Important: though the paragraphs above seem to indicate that CBC or CFB would be safe for key+IV reuse as long as you include a counter in the header of each message, remember that this is for a passive attacker only. In many (most) scenarios, the attacker can be also embed a bit of data of his own in the messages which are to be encrypted, and/or alter the encrypted bytes and see what happens when they are decrypted. For these scenarios, which are realistic (many recent attacks again SSL are all about that), IV reuse, and even predictable IV selection (with CBC), are hopelessly weak. Do not reuse IV.

The only situation where a fixed IV is fine is when keys are never reused, i.e. each key is used for a single message only. This is, in practice, harder to obtain than a new per-message IV, because keys must be kept confidential: it is already challenging to have a key which is known by both the sender and the receiver, but by nobody else. At least, IV do not have this confidentiality requirement, and thus can be transmitted along with the message itself.


Can eavesdropping be facilitated by injecting content that will be transmitted?

Your description is a bit confusing, but from what I gather, the scenario is this:

You're able to add data to the credit card database, and then capture encrypted traffic off them wire.  The question then is: "Is there any data you can add to the database that will then give you an advantage in attempting to decrypt the credit cards?"

If, that is in fact the question, and if, in fact, the encryption used is strong, and properly configured, the answer is "No."   This is what is called a "chosen plaintext attack."  It means that you can choose the data (or some of the data) to be encrypted, in this case, the arbitrary data that you add to the database, in an attempt to determine if you can learn something about the plaintext from the ciphertext alone.  A strong encryption algorithm, properly implemented, will not allow this.  You can do whatever you want to the data to be encrypted, add anything you want, but once it's encrypted and sent across the wire, it won't help you in your quest to decrypt, or discover anything about the contents of the encrypted traffic.


How to best present 'Security Vulnerability Feedback' to devs in the IDE (like VisualStudio)

This is a very cool idea, but I think that to succeed it is important to integrate this seamlessly with the existing environment.

To that end, I would suggest NOT to come up with some new, unexpected way to present the information, but to use the existing formats and mechanisms.

For example, underline critical and high-risk vulnerabilities with a red squiggly line - just as Visual Studio does for compilation errors by default, and just as almost all programmers expect. You could mark less serious flaws with less scary colors - blue, green, etc.
I would go one step further - and allow this to be configurable, int VS's Fonts and Colors options dialog, to enable programmers to either have it fit in with their specific settings, or even have it stand out. You could have one setting for Critical, another color for High, etc.

Additionally, just as with compilation errors and warnings, there should be a window listing all currently found issues - the richer this window, the better, of course (filtering, sorting, etc).

This would go a great distance in training developers that security flaws, are bugs just like functional bugs - and, in some cases (e.g. Critical/High), should be treated as compilation errors.

Note that VS's builtin Code Analysis works similar to this (except not realtime, for the most part).


Brute-force heuristics used in password cracking

As has been already mentioned there's really only two main ways of approaching the problem (brute-force and dictionary based) (assuming that the password are not protected by a flawed algorithm or implementation).  From what I've seen the main add-on to those strategies is to try and add a probability element to the cracking, so if we know that the password '123456' is a very common one for similar password lists to the one we're looking at we start with that.

There was an interesting presentation at Defcon a couple of years back on this (link here) which covered some of this around probabalistic cracking and word mangling strategies for dictionary attacks.  There's also some good onward links in the presentation.

There's also a good collection of wordlists from cracked password database on the skull security site here some of which are already listed by probability.


Authentication between to devices where the same password is used on both

This is kind of one of those things that's terribly subjective.

What exactly are you trying to protect against here?

More questions that need answering:

How does B verify that pub key received from A is the right key, and not a MITM key?
How are you deriving a private key (pair) from the password?
How are you blocking brute force attempts?
What happens if someone gets the password hash and attempts to crack it offline?
How are you protecting the private key file?
How are you preventing replays of the encrypted password?

There are probably a few more questions worth asking that aren't listed as well.

The way you've outlined the flow is somewhat sound, but the implementation is a bit weak, and that's where you start getting into the don't-roll-your-own territory and that's never a good thing.

I would consider taking a look at how other similar systems handle authentication, or better yet use an existing protocol or technology that does this for you like Kerberos. Odds are pretty good most of those systems are already using pre-existing protocols.


ISP has informed us that our server is launching brute force attacks on WordPress sites, how do we end this?

Changing the server password or .htaccess will very likely not do anything now as the hacker has already gained access and installed malicious software on the system. On a Linux system I would at first check (as root) what sockets are open and what processes are using them:
netstat -anp | less
netstat -anp lists all sockets with the owning process and piping it into "less" allow to scroll through the list.
If the server is a dedicated server you can capture the traffic by using the tcpdump utility and analyse it with for example wireshark. VPSs often do not allow sniffing.
However if the hacker was clever and has covered his/her tracks the system may not display the sockets used by the malicious program. In this case a detailed security check of the entire system is needed.


Can LastPass local password store (on a Android device) be brute forced in a usual way?

Making brute-force attack the only possible option is a desired feature of a security system.

This "only" would mean there are no weaknesses in the algorithm or implementation and the system could be broken only by trying all combinations of possible passwords.

On top of making sure brute-force attack is the only possibly, it should also be made difficult to perform.

In case of LastPass' database (an offline, encrypted file) the countermeasures are limited, but both the system design and user have influence over the effectiveness of an attack.

First: the database is protected with a key derived from a password using PBKDF with a specified number of iterations, which increases the time required for confirming each guess attempt.

Users need to set the number of iterations of PBKDF high to the point they can bear the time required for opening the database on their devices (this can vary for PCs and mobile devices).

Second: users must use strong passwords to make the brute-force attack harder (possibly to the point of infeasibility).

Two-Factor Authentication in LastPass does not protect the password database, but the access to the online service which provides encrypted user's password database.

Once the database is downloaded it is a static encrypted file and 2nd factor authentication is not necessary to decrypt it.


Can "something you are" be implemented without effectively turning into "something you know"?

Just because it is stored somewhere doesn't make it "something you know". You don't ever really "know" your fingerprint or iris layout as it is too complex to know or remember. But that is really just semantics, I wouldn't try to over-think the terminology.

As you correctly point out though, that doesn't mean someone else doesn't know it. The server keeps a (hopefully) encrypted copy.

In addition, it may be possible indeed for an attacker to gain a sufficiently detailed "copy" of your biometric to be able to replay it.

This is particularly problematic for a fingerprint as you tend to leave copies of them everywhere!

That is why fingerprints in particular should never be considered as replacements for an id/password but rather as complementary too them. Fingerprint logins are a convenience not a high security feature. They are relatively low security, better than users not being bothered to use any password but nowhere near as good as a strong passcode. Remember that, in particular, biometrics cannot ever be changed, once compromised they are always compromised.


This question is a bit unclear.

It is important to understand that non-repudiation is a complex subject that involves legal, social, and technical considerations.  Non-repudiation is not just a matter of algorithms.  You seem to think that use of public-key cryptography is sufficient for non-repudiation; this is far from the truth.

I suggest you read up on non-repudiation; the concept is much more complex than this question seems to appreciate.  In particular, there is not sufficient information here to determine whether the system you have in mind achieves non-repudiation to a reasonable degree.

Here are some readings on non-repudiation:

How to achieve non-repudiation? and my answer: digital signatures are not sufficient for non-repudiation.
What is the difference between authenticity and non-repudiation


As you say, this question will get nuked, so here's a quick answer before that happens :)

Programming can be useful in certain fields of security, and less so in others.  So if you do application security work (advising/working with developers) then it's important that you have a good understanding of what they do and can work with them to come up with practical solutions.

Also if you're a penentration/security tester being able to write your own scripts for automation is important and also understanding roughly what a piece of code does and how is useful when attacking systems.

For other types of security work (e.g. policy stuff, higher level advice and guidance) programming is less likely to be important...


What is httpvh:// and is it the result of something malicious?

Not a full answer but I found this which seems to suggest it's something do with YouTube "Lyte", to determine the appropriate way to optimize the videos.

WordPress YouTube Lyte

It seems there are a couple other variations to the prefix: httpa and httpv (without the "h" at the end).


Example of something that WYSIWYS tries to prevent

The problem WYSIWYS is trying to prevent is that, when the same file is displayed with different software, or at a different time, or on a different system, etc, it may be displayed differently, even though the binary data is the same.

Imagine someone crafting a web page that displays differently in different browsers. If someone downloaded it as an HTML file and signed it, they would likely assume they had signed exactly the content they saw when they downloaded it, but another user who opens the HTML file in a different browser will see something completely different.

Another example is a document with external references (think images in a web page), even though the user is shown the image before signing the document, what they're really signing is a reference to that image. The user thinks they signed a document that includes the image, but the image being referenced could be modified without invalidating the signature.


Confidentiality without Encryption - A way to circumvent Internet censorship

You don't actually need other users for this to work, it just makes it more reasonable.  You can perform chaffing by merely creating pseudorandom packets and MACs and mixing them in with yours.

The problem with chaffing and winnowing is that each message must be so small as to convey no useful information to the attacker.  Otherwise, attackers can use redundant information and knowledge of formats and protocols to assist in rebuilding the original message.  Compression prior to chaffing would probably help some, but I'm not sure to what degree.

I'm not aware of any networks like Tor or Mix masters using Chaffing and Winnowing.  There is an implementation in PyCrypto, among others.


Is a DoS attack possible on a single home connection when the ISP uses NAT?

Saturating bandwidth capacity of an entire ISP is very well possible and unfortunately happens on a daily basis. You’re right that with techniques like carrier grade NAT and end user may not have a dedicated IPv4 address, but that can still result in an outage when attacked. And of course, if the ISP deployed IPv6, it can be possible to uniquely target the end user that way.


Identify a user using random characters of the password

The point of a cryptographic hash is to not be reversible, so they can't be getting it from that.

It's possible they pick out and store a few characters from the password when it's set, so customer service knows what characters 1 and 4 are, but not 2 or 3. However, I'd strongly suspect they're storing the password in reversible encryption, because that's much simpler of an explanation, and banks aren't known for having great information security practices.


using counter instead of salt for hashing

The main problem is that salts should preferably be globally unique to avoid existing rainbow tables.  If you choose to use hash 1,2,3,4,5,etc, there may exist a rainbow table for them already.  It's slightly less risky if you do it as increments from some random number that makes it unlikely to have an attack, however there isn't really any good reason to do this.  It is far better to use a random value for each.  It's not that much extra data to store.

As far as how it applies to your situation, it sounds like you are trying to exchange messages.  Hashes are not used for exchanging messages since they are one way.  They are only used to tell if someone else had the same value without storing the actual value.  A salt is generally only needed for passwords, not for message signing, so I'm not sure that salts and hashes even apply to what you are trying to do as it is described.


How to know what type of encryption type is that?

The numbers you have displayed so far do fall within the confines of an ASCII table, you could start there.


How to speed-up data collecting of WEP AP for aircrack?

you should use airodump-ng to get the traffic. not aireplay. But that asside you can replay traffic you capture with aireplay as stated here

http://aircrack-ng.org/doku.php?id=how_to_crack_wep_via_a_wireless_client

if there are no clients available you could use aireplay-ng to fake auth
and then replay the traffic as stated here

http://aircrack-ng.org/doku.php?id=how_to_crack_wep_with_no_clients

good luck and stay safe


Google adds ryanair flight to calendar without being logged in

Try launching the browser in incognito mode, and redoing the test.

Alternatively, you could try this experiment.  Make your own official-looking "boarding pass" in an editor, save as PDF, and email that to the same friend.  Does this information show up on your calendar?

If so, make a change to your "boarding pass," save as PDF, and encrypt it using some sort of PDF tool.  Then mail it to the same friend.  Does the information show up on your calendar?

If NOT, then make a third change, save as plaintext PDF, and mail it to the same friend.  If you see this one show up on your calendar, then it's clear (at least to me) that your attachments are being scanned by Google.

(If your friend asks for your password from step 2, then you know it's the friend doing this.  If you get no response to this experiment, then (a) your "boarding pass" doesn't look legit to Google, (b) Google's not to blame, and/or (c) your friend is wise to your experiment and is standing down.)


Website with HTTPS - site exports file, is that transferred using HTTPS?

Web sites can't directly export files to a web browser; the browser must first make a request, and then the server responds to the request by sending some content. That is how (almost) everything on the web works, whether the content being served is web pages (HTML, CSS, etc.) or other content (like a file the server created for you).

This all matters because, for every request, it's the BROWSER that decides whether the request is sent over HTTP or HTTPS. The server has no actual say in this. The server can decide that the only thing it will do for HTTP requests is send a response that amounts to "try again, but over HTTPS" - this is probably what you mean by "set it up so that HTTP is redirected to HTTPS" - but if the request came in over HTTP, the response will go back the same way.

If you want to test, that's pretty easy. Open a web browser's developer tools (for most browsers, you can do this by right-clicking on any page and selecting "Inspect") and go to the Network tab. Go to your site and download the exported file. Look in the logged data in the dev tools (warning: there may be a lot of it) and see whether the request that made the server send the file went over HTTP or HTTPS. Whichever one the browser used, that's what the server used.


Does a deterministic credit card tokenization conform to pci-dss?

I definitely think it's a borderline violation of the Tokenization Guidelines. From the Tokenization Overview section in the document you linked:

  For a token to be considered non-sensitive, and thus not require
  any security or protection, the token must have no value to an attacker.

An attacker could use the token from one merchant with another, but there may be other validations in the processor's system that prevents reuse across merchants. i.e. a merchant-specific database that contains a whitelist of authorized tokens for that merchant.

Without understanding more about the whole system, I don't think it's an explicit violation of the PCI-DSS standards, but it definitely raises eyebrows.


How does a browser manage secure sessions and store session keys?

Secure session details per-website are stored in local cookies set by a response and sent to the server in future requests.

For cross-domain example, like you described with youtube (and a comment described), the standard method is OAUTH or OAUTH2. It is the same mechanism that you may allow other websites to access your facebook or twitter details.

This all manifests as a series of requests with parameters and responses redirecting to other targets.

OAUTH has some "implicit" flows that may allow auto-login across websites without the user explicitly approving it.

You can interactively move through some example requests here: https://developers.google.com/oauthplayground/


In this day and age most commercial SIEM/SEIM/SIM/SEM/SEEM/CSIM/SCIM/SIM products ship with a large multitude of so called "canned reports". In general each of these reports will be designed to look at specific logs from specific types of systems and process those. For example, given a "Windows - Failed Authentication Attemps" report, one would assume that the EventIDs that map back to authentication events would be processed looking for FAILURE. Whereas a "Windows - Firewall Blocks" would look for EventIDs that map back to the firewall subsystem would be processed.

The real questions you should be asking yourself are these;

"What do we want to get out of a SIEM?"
"What do I want to be alerted on?"
"What reports would I like to see?"

The answer to question #1 is really all about framing the situation in your own head. So you can keep it in mind when thinking about the other 2. Once you have answered those questions you can look at the SIEM product you have and determine, "What data is required to produce that information?"

Keep in mind that his can also vary wildly depending on the specific log sources as well. For instance, you may decide that a web server that serves nothing except the contact information for a department only needs to send authentication and IIS logs, whereas you may want all logs from your domain controllers. This can also be greatly influenced by any licensing restrictions as many commercial products will license based on number of log sources and/or events per second (EPS).

Unfortunately, there is no short, clear cut answer. It all depends on what you want, and what your solution is capable of.


Why am I receiving HTTP GETs for a domain I don't own?

Your website has been hit by an automated script that looks for open proxies on the internet. The url it's trying to access would record a successful proxied request and add your server to a list.


Password hashing with salt. Where do you leave the salt?

Storing the salt together with the hash is fine. The salt is essentially public information. Many systems store it in a format like $hashAlgorithm$parameters$salt.hash.

  But isn't this insecure?

No, because the point of a salt is not to be secret. The point for the salt is to be random and unique. It should increase the work factor for the attacker, not prevent an attack completely. Let me demonstrate this:

Scenario 1

Your database contains 1,000,000 users, all just having their hashes stored in plain SHA-1. An attacker compromises it. Their possibilities are now:

Perform a lookup-attack, meaning that the attacker just looks up the hash in a database of pre-computed hashes.
Perform an attack with a rainbow-table, which is a variant of the above-mentioned attack.
Hash a well-known list of passwords themselves (e.g. rockyou.txt), exactly once.
Brute-force weak passwords, or password in a common scheme, like an uppercase character, followed by 8 lowercase characters and one digit.

Scenario 2

Your database contains 1,000,000 users, all just having their hashes stored in Argon2 with a unique, random salt. An attacker compromises it. Their possibilities are now:

Hash a well-known list of passwords themselves (e.g. rockyou.txt), 1,000,000 times.
Brute-force weak passwords, or password in a common scheme, like an uppercase character, followed by 8 lowercase characters and one digit - 1,000,000 times.

It's not possible to do a lookup-attack, because nobody would store the hashes to millions of password, with millions of possible salt combinations. It's also not possible to do a rainbow-table attack, because building the rainbow table for every user with their salt would take longer than to just computer each hash.

Furthermore, just by adding a salt, you changed the amount of work required from "Hash once, check everything" to "Hash every time". In our scenario with 1,000,000 users, you made the task of the attacker 1,000,000 times more difficult.


Why is VirusTotal "unable to process file type" for files packed with Mpress?

It’s likely the antivirus products are detecting the usage of MPress itself as a sign the file is malicious.

Executable packers create files which are usually significantly different from “normal” programs in a few ways:

the headers are minimised, the MPress site claims to remove standard features like debug directories and relocations.
executable sections have high entropy (due to compression) and usually minimal space between them (a normal PE has a lot of null bytes).
code sections often have read/write/execute permissions, or code is created in memory with write permissions and then executed. This allows code to be decompressed in place but is unusual (outside special cases like JIT compilers).

Other reasons antivirus programs may detect these files include:

they are often used by malware, and rarely used enough for vendors to worry about false positives (users can add exceptions).
there are few compelling reasons to use packers nowadays, as storage sizes and download speeds exceed requirements for most programs.

As for the reasons files can’t be scanned, this is vendor specific. Perhaps something about the ZIP file is unusual, and the engines are refusing to scan to avoid problems. If you supply hashes of your files it might be possible to compare them further.


how to detect udp port scan in suricata?

There's plenty of examples of UDP scans within the ET community signatures for Suricata.

One thing you have to keep in mind is that the very nature of a UDP scan. Someone is trying elicit a response through a socket on those ports via UDP. You may also want to consider creating flow rules related to the UDP protocol for saying # of connections with a null (or suspected common scanner payload) is seen sourcing from an offending host to multiple hosts in something like $HOME_NET and the flows bit words might be included from_client, stateless


What you're asking for is impossible. If the server can decrypt the data, so can an attacker with physical access to the device. Before thinking about strong crypto, think about strong physical security. Hosting companies aren't what I would call strong security.

If you're merely concerned about defending against malicious root access, then an HSM will prevent them from stealing the keys for later reuse, but they'll still be able to use them while they have access to the server.


Outbound proxy which whitelists by server certificate?

There are two things I can think of, neither fits the bill perfectly, and there's some assembly required.

squid  with sslBump and the SSL Server Certificate Validator
This is basically an MITM SSL proxy configuration, and you get to provide an external "helper" that augments normal verification. Stumbling blocks include certificate trust and managing your own CA/certs. I've never used this though.
Apache httpd as a forward-proxy, with mod_rewrite, mod_proxy and an external validation script. The approach here is to use a mod_rewrite program map to pre-validate the target's certificate before allowing access.

The Apache option can be tested easily:
httpd.conf

LoadModule proxy_module           modules/mod_proxy.so
LoadModule proxy_connect_module   modules/mod_proxy_connect.so
LoadModule rewrite_module         modules/mod_rewrite.so
[...]
Listen 10.0.0.16:3128

<VirtualHost 10.0.0.16:3128>
    ServerName   proxy.domain.com
    ErrorLog  ...
    CustomLog ...

    ProxyRequests on
    RewriteEngine on

    RewriteMap sslval prg:/usr/local/apache2/bin/sslval

    <Proxy>
        RewriteEngine on

        ## parse CONNECT
        RewriteCond %{THE_REQUEST} "^(CONNECT) ([^:]+)(:([0-9]+))? HTTP/"   [NC]
        RewriteRule .          -   [env=CHOST:%2,env=CPORT:%4]

        ## hand over to sslval
        RewriteCond  ${sslval:%{ENV:CHOST}:%{ENV:CPORT}}          ok
        RewriteRule  .                            -               [P,L]

        RewriteRule   .                           -               [F]

    </Proxy>
</VirtualHost>

This is an external "sslval" script which uses gnutls-cli because of its certificate caching support, and lets you specify exactly which certificate you expect:

#!/bin/bash
export HOME=/usr/local/apache2
while read key; do
    timeout 10 gnutls-cli --tofu \
        --port=${key##*:}  ${key%%:*}  >/dev/null 2>&1 <<<Q
    [ $? = 0 ] && echo ok || echo fail
done

Now all you need to do is add the expected certificates to ~apache/.gnutls/known_hosts interactively with gnutls-cli --tofu ..., and entering "y" to confirm.

This trust on first use method might seem familiar, it's exactly like OpenSSH's known_hosts. This approach is not unlike the OpenVPN's --tls-verify option.

A variation on the sslval script can be used to check against a select CA database, e.g. with OpenSSL's s_client and a database of .pem CA files (maintained with c_rehash), e.g:

timeout 10 openssl s_client \
         -connect "$key" -servername "${key%%:*}" \
         -verify 5 -CApath /usr/local/etc/CA <<< Q |
   gawk '/Verify return code: (19|0) /{ok=1}
      END{print ok?"ok":"fail"}'

Error checking, locking, configuration and access-control, caching, and all those nice things are an exercise for the reader... ;-)

With Apache (2.2.2x) I have found that proxying normal requests (non-CONNECT) is affected by the above mod_rewrite technique, you will need an second VirtualHost for those.


Importance of Lastpass User Vaults Statement and Two-Factor Authentication

As LastPass is a proprietary service, giving definitive answers about it can be difficult. I can say that I have seen no documentation that 2-factor authentication (2FA) would protect you from a side door attack where your data is stolen from the server. That said, 2FA does provide added security against an attack via the API.

So, it seems to me that the statement about 2FA is meant to reassure the public and encourage more secure practices rather than provide a strategy to protect against similar LastPass attacks.


Should the thumbprint be SHA2 in addition to the Signature Hash Algorithm?

Computed field
I think that's a calculated value by the Windows GUI. And not actually inside the cert. Have a look at the cert itself using OpenSSL. (openssl x509 -in MYFILENAME.CER -noout -text)
Here's a blog that talks about this:

http://morgansimonsen.wordpress.com/2013/04/16/understanding-x-509-digital-certificate-thumbprints/

the thumbprint is a computed field, i.e. not a part of the certificate data itself.


Cookies are not the only persistent mechanism they may be using.  Flash LSO, HTML5's Local Storage are two that come to mind...


Is it possible to steal money directly from the systems of a big bank?

Each transaction needs an audit trail - numbers need to come from somewhere - and bank systems have these checks in place. Are they perfect? Almost, but enough to make it easier to look for other attack vectors, like humans.

Did I mention that I was in jail in a far away country and I need you to wire me money for bail?


Do openssl CA certificates get updated with apt-get upgrade?

The global trust store in /etc/ssl/certs/ is part of the ca-certificates package and receives regular updates as can be seen from this Changelog. These are normal updates which get installed by apt-get upgrade.

The specific file itself is not part of the package but is generated by update-ca-certificates. This command gets automatically called on updates of ca-certificates as needed to reflect the changes in the trust store.


Is there an open-source PGP that Encrypts-then-MACs, uses Blake2 or Whirlpool, and none of the NIST curves known to be compromised?

No, however it is not necessary. Some of your presumptions are incorrect to start out with. The things you point out as security issues are not necessarily actual issues. Let me go into more detail.
MDC uses SHA-1 and MAC-then-Encrypt
The MDC is designed to avoid a decryption oracle attack, as well as accidental corruption. Both of these issues are effectively mitigated even when using a "modest" hash function. In fact, even MD5 would likely not cause issues, considering the MDC acts similarly to a MAC where collision resistance does not matter. Using a stronger hash function would not give you any real benefit. In order to have actual integrity guarantees, you must digitally sign the message. That will prevent a large class of attacks that MDC is unable to. Overall, MDC is not designed to give a strong guarantee of integrity. It is neither intended nor capable of doing so. It is only meant to protect from a particular, obscure attack, and to give some protection against accidental corruption that may lead to decrypting a garbled message.
BLAKE2 and Whirlpool are not supported
For signing a message, a hash function is used. For this purpose, SHA-256 and SHA-512 are fine. In this situation, SHA-1 may not be ideal, and for this reason, it is being phased out in favor of stronger functions. While entirely different functions may be nice, it is not necessary for security. SHA-2 is fine. They are completely preimage resistant and have very good collision resistance. Also note that Whirlpool, while not endorsed by NIST, is directly based on AES, which someone who has no trust in NIST whatsoever may want to avoid (not that there's any reason to suspect it is particularly weak). The attacks that SHA-2 are vulnerable to (such as length extension attacks) are completely irrelevant to the way they are used in the OpenPGP format. When the need arises, more hashes may be added.
NIST curves are used for ECC
This is not entirely true. A NIST curve (P-256, specifically) is used when ECDSA is in use, but ECDSA is being deprecated due to the same weaknesses that regular DSA has. It is supported, but it is not recommended or required. Newer GnuPG versions have a non-NIST curve, specifically Ed25519 to replace ECDSA. It is not as well supported, but it is faster and has superior security. I'd also like to note that P-256 and other NIST curves are not "known to be compromised", as you put it. The issue with P-256 is that it does not use nothing-up-my-sleeve numbers, making it theoretically possible that the values were chosen to enable a class of yet-unknown attacks. There is no actual evidence for that, but it is good to be cautious. That's one of the reasons ECDSA is being replaced by Ed25519.
The real issues
There are actual issues with GnuPG, but they are not among the things you mentioned. These issues tend to be newer things which were not a concern back when the OpenPGP format was thought up:

Forward secrecy is not present. Compromising the private key allows retroactive decryption.

Post-quantum cryptography is not in use. NTRU would be great, but it just isn't supported.

The Web of Trust is hard to get right, so most people who use PGP tend to rely on TOFU.

GnuPG is very complex. For parsing complex formats, a tight seccomp filter would be nice.

PGP involves non-intuitive concepts, making it hard to use. This hinders adoption rates badly.


Are web scrapers fooled by obscured emails anymore?

You've got multiple methods really, you should of course consider that such bots harvesting this content are essentially scraping whatever pages they come across and searching for patterns that look like email addresses. As you say, it's a bit of an arms race and there's nothing stopping the people developing such scrapers from implementing these methods (wait, is that why you're asking?)

You're going to want to avoid actually creating a hyperlink out of your email address in most cases, and you certainly want to avoid using mailto: - that's basically announcing to anybody reading the page "hey, I'm an email address".

Let's start of nice and simple, spacing:

m y e m a i l @ m y d o m a i n . c o m

It's obviously an email address to a human, looks like a bunch of random letters with spaces to a scraper. Don't like spacing? Much less common but far more foolproof is to convert your email address into an image. It's still human readable but it's not going to be something that most email scrapers are looking for, let alone able to parse.

How about converting your punctuation (@ and period) into their HTML equivalents (&#64; and &#46; respectively)?

myemail&#64;mydomain&#46;com

This still looks like an email address when rendered by the browser, but it isn't going to be all that difficult to work around from the point of view of scraping since you'd just look for the &#46; and &#64; - but why stop there? Why not go all the way and just encode the entire email address? This can be done quite easily with a tool like Rumkin's Mailto Encoder, suddenly your email address looks like this:

&#109;&#121;&#101;ma%69&#108;&#64;my%64%6fma%69&#110;%2e%63&#111;m

This still renders like you'd expect in a browser, but is basically gibberish as far as any scraper that doesn't take the encoding into consideration.

You can also do this with CSS if you're so inclined with something like this:

<style>
  my-email::after { content: attr(data-domain); }
  my-email::before { content: attr(data-user); }
</style>

<my-email data-user="myemail" data-domain="mydomain.com">@</my-email>

Or, as already discussed on Stack Overflow, you could just use JavaScript.


If you're using simple HTTP for communication then TLS would be the easier route.  While you think you might have thought everything through it's better to use an established protocol for the following reasons:

It's already supported by most browsers, operating systems, and devices.
The infrastructure is already in place, with lots of examples for configuration.
Already tested.  Faults in its security have been detected and fixed.
Regular updates

The other concern for using just straight GPG is performance.  Bignum operations take significantly longer to perform.  Having to do these large calculations for every message you send to the server could be taxing.

Checkout How Does SSL/TLS PKI work? for more information on why/how the web uses Certificate Authorities.


How can an email from a Yahoo address be sent through Yahoo without authentication?

The important thing to remember about email and email addresses is what can be set by users and what can't be set.

The To: address is set by the user and can be though of as the name and address that you put on the top of the a written letter that you might write. The From: address is the address that you would put in the upper right hand corner of that page.

But, notice that letters are mailed in envelopes, which may have different addressing information on the outside (the return address on the outside does not have to match the address on the inside). Mail clients usually show the address from the top of the letter (not the addresses on the outside of the envelope). The one thing that you can't control when sending a piece of postal mail is the cancel stamp (which has the name of the city that canceled it). All of those Received headers can be though of as cancel stamps as the email moves from system to system.  Looking at those headers you can see the traffic flow:

vip.cybercity.dk (Authenticated sender: dsl366676) sent it to
uf9.cybercity.dk at Thu,  3 Apr 2014 23:27:37 +0200 (CEST)
Which then sent it to smtp1.cybercity.dk at Thu,  3 Apr 2014 23:27:50 +0200 (CEST)
Which then sent it to mtaq2.grp.bf1.yahoo.com at 3 Apr 2014 21:27:50 -0000
Which sent it to a mail server process (qmail 11784) at 3 Apr 2014 21:27:50 -0000
Which sent it to m9.grp.bf1.yahoo.com  at 3 Apr 2014 21:27:50 -0000
Which sent it to a mail server process (qmail 90091) at 3 Apr 2014 21:27:50 -0000

This shows that the mail came from cybercity.dk to yahoo.com

Of note, this email says it was created by a Microsoft Live Mail

X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3522.110
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110

Which is not used by yahoo.com. The problem I see here is that Yahoo.com should have flagged as spam email from someone using a From: address that was *@yahoo.com without that connection first being authenicated as a valid yahoo.com user. Some email providers do this, but others do not (Yahoo appears to be in the second group).


Listening using the microphone is unlikely
Listening secretly without consent
While listening using the microphone for collecting data would be technically possible, there's a few things against the theory. The unifying factor is that secretly monitoring conversations is considered unethical and would probably even be illegal. Getting caught of such actions would ruin any company's reputation for quite a long time, which makes it less likely.
One would eventually get caught, because:

If the device sends the unprocessed audio from the microphone, that would cause notable network traffic.
If the device processes the audio with voice recognition, that would cause notable processor activity.
So many are reverse engineering both the processes and network protocols.

Is it worth it, when there are better and legal alternatives? Data sources without recording offline conversations are already overwhelming, as explained later.
To back up this reasoning, the network traffic on both Android and iOS weren't comparable to Hey Siri and OK Google on Wandera's experiment, where they systematically played both pet ads and silence to the devices and compared their metrics. (Thanks, TCooper!)

Upon examining the results, we found nothing to suggest our phones are
activating the microphone or transferring data in response to sound.
The data consumption and battery consumption changes were minimal, and
in most cases, there was no change at all.

Sources you have given the permission to listen to you
There are also legal sources of microphone data like Alexa, Siri and Google voice search. These are not spying on you all the time but do use voice recognition – that's just a voice interface that replaces the search bar. Some problems do arise when such a service is activated accidentally.
The closest example of recording everything has been Samsung SmartTVs back in 2015 when their privacy policy transparently stated that:

Please be aware that if your spoken words include personal or other
sensitive information, that information will be among the data
captured and transmitted to a third party through your use of Voice
Recognition.

Although this was mentioned in the privacy policy, it caused so much uproar that today their privacy policy has changed and they only send recordings related to voice commands, just like the others:

Voice information: Recordings of your voice that we make and store on
our servers when you enable this function and use voice commands to
control a Service, or when you contact our Customer Service team.

The data collected could also be used in ways you might not know if you haven't read the EULA or the privacy policy carefully – nor understood the legalese used.

Alternative explanations
The following mechanisms / phenomena both exist and complement / reinforce each other.
The Internet knows you better than you do
Everyone is constantly tracked while surfing on the Internet. Tracking cookies can identify the person across several sites and make connections. The searches on search engines are saved and connected (whether they are typed of got using voice recognition). Shopping behaviour is carefully analysed connecting both data voluntarily given using loyalty cards and data left behind involuntarily.
Many things can happen to all this data. It can be sold, connected with data from other sources (anonymized or not), and analysed using algorithms. The results can be and are sold again. This enables advertisers to find carefully selected target groups. The relation doesn't even have to be direct like "people buying tools will soon buy construction materials", but the data may reveal much stranger connections. This is explained in detail with many examples e.g. in Hannah Fry's book Hello World: How to be Human in the Age of the Machine (2018).
The bottom line is that there are ways the advertisers can make good, educated guesses on your potential future needs before you do even without listening to you. That's how you really get surprisingly relevant ads.
Confirmation bias
You talk about hundreds of things during the day. Likewise, you probably see hundreds of ads. Most advertisements are completely irrelevant and about topics you haven't talked, so they are easy to dismiss. However, when you occasionally see advertisements on topics you have been discussing, it starts bugging you, leaving suspicions behind.
Every time this happens, you get more and more convinced that someone must be listening to your conversations, and your phone is the first suspect as your closest friend you even take to the toilet.
This is easy to test by taking a vacation from your smartphone – unless it's glued to you. If it doesn't make any difference in how you see advertisement about the topics you are discussing, then it must be something else than the microphone you always carry with you.


Where do Access Controls Fit into the Parkerian Hexad?

Looking back at the wikipedia page you linked to, I can see access control falling into the first bullet, confidentiality.

Quoting Wikipedia

  Confidentiality refers to limits on who can get what kind of information. For example, executives concerned about protecting their enterprise’s strategic plans from competitors; individuals are concerned about unauthorized access to their financial records.

Access controls are exactly about who can get what kind of information.

In the comments below the answer, someone suggested it would be within authenticity and I was leaning towards that too but after reading what Wikipedia says, authenticity is more about proving that what you claim is true. Access control is about determining what it is you can do with that claim. Access control assumes that the claims are authentic.

If you go to the CIA triad definition of confidentiality, you will find the same approach as in the Parkerian hexad:

  In information security, confidentiality "is the property, that information is not made available or disclosed to unauthorized individuals, entities, or processes" (Excerpt ISO27000).

So access controls (be it ACL, RBAC, or ABAC) belong to confidentiality.


Can I get rid of storing user secrets by using OpenID, and what do I need to store?

What you keep about the user is your own decision. The most basic implementation is keeping a user ID (the one received from the open ID provider) and the token you receive from the open ID provider (which includes access token, expiration and refresh token).
whatever you wish to keep beyond that is up to you.

As much as I know every openid connect provider must respond with the same data structure... that is part of the protocol, but openid has three versions: 1.0, 2.0 and connect

Some examples of providers:
Google and Microsoft Azure now use openid connect for their openid services.
Yahoo uses openid 2.0
You mentioned Facebook - they are not an openid provider, they have their own unique protocol


Can I look up email address from a PGP/GPG fingerprint?

Yes you can, just take that fingerprint remove spaces and add 0x at the beginning.

Then make a search query:

https://keyserver.cns.vt.edu/pks/lookup?search=0x...


For all things SSL, reading the standard is not a bad idea; it is very readable (for a standard). You may want to skim through this answer first, as a kind of reading guide.

For your specific question, what the server sends as "certificate" is described in section 7.4.2:

certificate_list
   This is a sequence (chain) of certificates.  The sender's
   certificate MUST come first in the list.  Each following
   certificate MUST directly certify the one preceding it.  Because
   certificate validation requires that root keys be distributed
   independently, the self-signed certificate that specifies the root
   certificate authority MAY be omitted from the chain, under the
   assumption that the remote end must already possess it in order to
   validate it in any case.

The point is that a certificate, in order to be usable by whoever receives it (here, the client), must first be validated, a process by which the client puts the certificate at the end of a chain. The chain begins with a "trust anchor" (a "root CA" whose public key is known a priori), and each chain element is an intermediate CA certificate, issued (signed) by the previous certificate in the chain. The chain ends with the certificate that is to be validated. Validation entails verifying an awful lot of things (described in another standard that is substantially less readable for sane human beings), in particular all the cryptographic signatures (each certificate is signed by its issuing CA; the signature is verified with regards to the public key contained in the certificate which comes immediately before in the chain).

Since a chain must be built, the server is supposed to send to the client a complete chain, so that the client may work on it directly. Otherwise, the client would have to locate and obtain the relevant intermediate CA certificates, a process which can be quite complex and prone to failure.

Noteworthy points:

The chain sent by the server is in reverse order: it begins with the end-entity certificate (i.e. the server's certificate properly said), then followed by the certificate for the CA which issued the server's certificate, then the CA which issued that CA's certificate, and so on.
The chain may or may not contain the root CA certificate itself. Sending it is not needed since the client already has it (validation is really trust delegation; it must start somewhere). Sending the root CA is nonetheless allowed by the standard, and some servers do it (mostly for the sake of tradition).
The client is free to use the chain sent by the server, or to build another one. For a given certificate, several chains may be possible (it depends on PKI structure). Most Web browsers will first try the chain as received from the server, and, on failure, try again with some custom chain building. Some more limited clients, in particular embedded systems, will use the server chain only. So the server should send a proper chain with no missing link (otherwise, only "smart" clients will be able to validate the server's certificate and thus successfully connect).


How can startup companies protect their code from any intentional leakage?

There is no perfect technological solution, and there never can be.

Humans are the weakest part of security, (because they click on things they shouldn't and fall victim to social engineering traps), but they are also the strongest part of security.  They can identify when something "doesn't seem right".  They can look into and probe deeper to confirm or refute their suspicions.

Ideally, the people you hire should not want to steal your source code.  You should be treating them well so that they want the project to succeed as much as you do.

Ideally, you should know each of your developers well enough to know if they would do something like that.  Even if you blocked access to Tor, you can't prevent them from putting the code on a USB stick.  If you prevent that, you can't prevent them from printing it out and sending it through the mail, and so on.   You need to nurture a level of bidirectional trust, such that they know you're working in their best interests and you know that they're working in yours.


This question includes two parts: why we have so many bugs in the first place and why not all bugs gets detected and solved given enough time.

Why we have software bugs

Writing software takes resources, i.e. time, knowledge of developers and money. There is always a shortage of time (to go to market) and the number and experience of developers. Also, more developers just does not mean that the product gets done faster because more developers means more communication overhead which adds to the complexity.
And there is a shortage of money, because there is the need for the product to have a positive return on investment.

Thus to write more secure software in the first place you should aim for a minimal complexity which you can manage with as few developers as possible. But unfortunately the complex needs of the customers often contradict this goal. On top of this requirements change with the time because the environment where the software gets used changes.

This way even software with a good initial design developed by experienced developers gets more complex over time. And, most software was not even developed with a good initial design by experienced developers but many just started as a prototype which worked good enough initially and then just got extended and extended over time often by different developers (with a limited understanding of the initial design).

And this is just one reason you have bugs. Other reasons are that the software is used in an environment it was never designed for, like software designed for a closed and protected environments now gets connected to the open internet.

Why not all bugs gets found and solved

Security researchers and developers inside and outside of software companies face the same limits: there is only a limited number of time and a limited number of researchers while there is lots of software with potential problems. Thus the security researchers focus on the software which promises the largest return of investment first, i.e. where the most high impact bugs can be found in the shortest time using the specific knowledge and experience of the researcher.

This of course leaves lots of undiscovered bugs because some might need a specific experience, some seems to be not worth to detect or just because there was no time to look into the specific area of the software. And even if a bug gets found it might not be critical enough to invest resources to fix it (some or just that deep in the design that it is too costly) or the software vendor might not exist any more or the software is declared end of life so nobody should use it anyway (even though many do for various reasons).

Can't we just ignore the bugs not found yet?

Finding and exploiting bugs is similar to extraction of natural resources: there are still lots of undiscovered resources out there and there are discovered places where exploitation of these resources is too expensive. But, new knowledge, new techniques or just an increased marked value of specific resources make it attractive to exploit these resources or to look for more hidden resources. In case of bugs this might be some new technique or tool which makes it easy to find new classes of bugs. Or change of use cases make previously impossible attack vectors working, like connecting some software to the internet. Or there might be a valuable target using a specific software which makes it attractive to look for vulnerabilities in this software and exploit these.


How do attackers hit a website with thousands of similar but distinct IP addresses?

It doesn't feel like a DDOS attack as it is "just" a few thousand per hour.

That's not always the case. There are attacks e.g. like the RUDY
attack that don't have to generate a large amount of traffic but yet they are very effective.

Could this be a zombie botnet of compromised devices, or is it possible the attacker is spoofing these addresses?

It could be a botnet, or even a single script that spawns a few threads and routes them through proxies.

Is IP address spoofing easily done and common now in these scenarios?

If the attacker wanted to get some results back from his/her attack then IP spoofing wouldn't be useful since the traffic wouldn't return back to the attacker - so in this case he/she would have to use a botnet or proxies. However if the goal is a Denial of Service then it's possible, since packet-level IP spoofing can be easily implemented.


Why are root certificate authorites allowed to issue certificates for any domain?

Why is it designed to trust all root CA to issue certs for any domain name?

This has historical reasons and maybe for reasons to promote competition. At the beginning you had only a few root CA with very high prices. Now the prices are down because all CA can issue a certificate for anybody. If each CA would only be able to sign certificates for a specific part of the internet this competition would not be possible.

Such insecure initial design you have in various parts of the internet protocols and it is usually worked around by adding optional security, i.e. pinning for certificates, content security policy against cross site scripting etc. Of course, all of this is is just added optional security and thus rarely used. The general thinking is that it works without so why care.

  Would it not be more secure that you designate which root certificate authorities are allowed & trusted to sign certificates for your domain name records for example via DNS SEC?

There are ideas to use it and in the area of mail security DANE is slowly gaining followers and there are also proposals to store SSH or other keys and certificates (or fingerprints) in DNS. The main problem is that one would need to first have DNSSec available everywhere before one could rely on DNSSec to deliver all these certificates. But for now only a small part of the internet is protected by DNSSec. Also lots of DNS resolvers don't deal with DNSSec at all or not properly and at the application level you usually have no access to the protection status of a DNS response too.

  Similar DNS examples are also mail SPF records where you say which mail servers are allowed to send mail from your domain.

SPF or DKIM records are considered not that much security relevant and thus delivery of these records with unprotected plain DNS is considered acceptable. This would not be the case with certificates where you would need a response you can fully trust.


Any OWASP project is as relevant as the community behind it, for example the PHP project is now abandoned but ASVS seems pretty active still.

Adhering to any OWASP best practice is always a good idea, it may not be the perfect fit for your organization and you are not obliged to follow everything they say, but it certainly helps to steer you in the right direction, and you have the back up of a solid not-for-profit organization.

As for the second part of your question please see this, but keep in mind that you can also approach it from the risk analysis point of view, for which you have options like STRIDE or Trike and even OWASP's own help.


Browser page "Not resolved" page hijacked by yandex

It turns out that the DNS system has been hijacked by yandex in cooperation with turk telekom (TTNET) which in turn results in non resolving pages end up on the yandex landing page.


Unsigned device drivers used to be extremely common in the XP-Vista-partially 7 days. Obtaining a Microsoft WHDL driver signature comes with a monetary and time cost, so hardware companies releasing frequent updates used to sometimes ignore it and rely on the user to click through. This includes AMD.

Driver signatures are only enforced on new OS installed after July 26, 2016: https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/

The driver in question predates this policy, so the developer didn't have to have it signed.

The general case for such drivers is not to be malicious, unless later modified by malware. The most reasonable thing to do in such a situation is to uninstall the current driver, do a malware check just in case, download the latest drivers from AMD, and install them.


You want to increase signal and reduce noise during a pen test?

Great! Here are some things to ponder on:

For answers to the questions you have -- are they already answered somewhere else? For example, does Nmap data from a previous pen test provide an accurate-enough view of the data you would expect today? Would csrecon or similar provide that data? If you are on the local network, does ARP provide it? Can you speed up the ARP discovery (netdiscover, arp-scan, arping, etc) and packet-capture/MITM (e.g., bettercap) techniques or combine them with Nmap via xerosploit?
Can you scan from a trusted or third-party source and note the results before you start your own scan from your own infrastructure? Would scanless or similar provide that perspective? How about using the ipidseq NSE script to pivot towards idlescanning? Or how about using dnmap from tons of sources?
Can you modify Nmap so that it isn't picked up by IDS or blocked by IPS? Can you use a tool such as sniffjoke with a prepared configuration? How about using a different means of scanning that appears more-normal and more-TCP friendly/efficient, such as pbscan? Can you perform both Nmap and MetaSploit simultaneously with metasploitHelper?

If you already have creds, then go poking around with SPN scanning before IP/ICMP/TCP/UDP scanning. Then pivot with tools such as portia, autoDANE, and CrackMapExec.

Sometimes, other protocols are in-use on the network, such as DCE-RPC over Ethernet (as opposed to TCP/IP over Ethernet), but you could build a bridge between the two using Piper or similar. Want to create a backchannel (e.g., C2, covert channel) over ARP? Then test out slarpd/slarpc.

Other times you can create a covert channel in existing protocols, such as by using the phcct tool for TCP/IP protocol hopping or even the Forkitor method over SSH. Hide in plain sight!

How about IPv6? Is it enabled on the network but the blue team isn't looking for it? If you want to see if IPv6 is enabled, grab a local stack and use ip -6 neighbor show, ndp -an, to passively show those networks, or even actively with ping6, e.g., ping6 -c 2 ff02::1 or ping6 -a ag, ping6 -a al, ping6 -N. Run this module from the metasploit-framework --
 auxiliary/scanner/discovery/ipv6_neighbor_router_advertisement

Try these techniques -- https://www.ernw.de/download/newsletter/ERNW_Newsletter_45_PenTesting_Tools_that_Support_IPv6_v.1.1_en.pdf -- to build a bridge between your IPv4 tools and the target IPv6 networks.


I suppose the sslstrip breaks the bridge between the http and https. One of the cases where the tool works is the case of redirection. The tool checks the 'Location' header and strips off the HTTPS from it. It then embeds the HTTP URL for the client so that the browser should not go for SSL handshake. In short, the SSLStrip intercepts the traffic before it gets negotiated to secure tunnel. The url you mentioned is the https URL is a direct https url where the http->https transition will not happen. Hence the tool [sslstrip] will not give you the expected output even though HSTS is not enabled.
I hope this is useful.


Analysis of the 32 million passwords recently exposed in the breach of social media application developer RockYou last month provides further proof that consumers routinely use easy to guess login credentials. Sensitive login credentials - stored in plain text - were left exposed because of a SQL injection bug in RockYou's website.

  The emails and passwords of around 1.3 million registered users – including those of Gawker Media owner Nick Denton and its employees – were accessed and subsequently published online.

  The social networking website LinkedIn was hacked on 5 June 2012, and passwords for nearly 6.5 million user accounts were stolen

  A hacker collective calling itself D33Ds Co. publicly posted more than 450,000 log-in credentials -- i.e., paired usernames and passwords -- obtained from Yahoo's "Contributor Network" site.

  It all started when Adobe reported the breach of more than 3 million customers' information (including password-identifying information), then upped the number to 38 million. Last week it got a whole lot worse when an outside company found the data of some 152 million Adobe customers on a site frequented by cybercriminals.

  Turkish hacker Maxn3y defaced avadas.de on Saturday (archive here) before dumping what the hacker claimed were customer details online. The purportedly leaked information included incomplete configuration files for the shop.avadas.de domain, what appeared to be authentic admin login details with encrypted passwords, and (most seriously), what security experts believe is the PayPal payment information for an estimated 20,000 consumers. According to Cyberwarnews.info, which analysed the data dump, the hackers also grabbed the email addresses, user names, encrypted passwords as well as certain bank and payment details of the customers.

  Thousands of Tesco customers have had their emails and passwords posted online after hackers got their hands on the login details.

…

Relying on the rate limit on password attacks is all good and well until the password database gets leaked.

When the password database is in cleartext, the game is over for this password. You can't mitigate that by having a strong password, only by not reusing the same password (or an easy-to-modify password such as swordfish!Yahoo vs swordfish!Tesco) on different sites.

When the password database is hashed, it takes some time for attackers to run an offline search and find the passwords. The stronger the password and the better the hash, the longer the attacker will need. If your password is strong enough, then you may have a chance to change your password before any attacker finds your password. This puts users in competition: the weakest passwords will be the first to be exploited. Even in this case, you'll need to change the password everywhere you use it, which strongly argues in favor of genuinely site-unique passwords.


Say, I am interacting with Google. Firefox shows me their certificate details. If I were to be able to try out a MITM for a request to Google, can't I just copy Google's certificate(which seems to be a public information) and provide that as my certificate?

You can copy the certificate all you want, but you can't copy the private key that corresponds to the certificate. The private key is the (only) secret of the system, and closely guarded by the webserver.

The basic TLS handshake means that the server sends it's certificate, and proves it by using the corresponding private key to sign a nonce:

  Server's digital signature: The server uses its private key to encrypt the client random, the server random, and its DH parameter*. This encrypted data functions as the server's digital signature, establishing that the server has the private key that matches with the public key from the SSL certificate.

Thus, when a client uses the certificate (the public key) to encrypt something, you have no way of decrypting it, and the TLS handshake will fail. This handshake normally happens before any data is exchanged.

You should probably read up on public key infrastructure which describes how the model works.

This is also why Heartbleed was a huge thing; it allowed extraction of the private keys from webservers.


Why can't the client server speak directly to an identity provider like Facebook in OAauth 2.0

While it would be possible, the process would be more complex and therefore a faulty implementation more likely.

For example it could work like this:

redirect to OAuth authentication endpoint, include a session identifier
user logs in
OAuth provider sends authentication token and session identifier to requesting server
user's session is linked with the authentication token
user is redirected to REDIRECT_URI

The session identifier is needed, because else an attacker with good timing could take over the authentication token. As you can see the session identifier is replacing the authentication token to identify the client in this example, which means that sending the token from server to server is just an additional step.

  the client would have registered the redirect_uri with Google beforehand

The registration would make the system less flexible, because currently only the calling service needs to decide which OAuth provider to trust. By using registrations the relation has to be established on two sides.


HTTP Proxy with encrypted authentication

What you wish to accomplish does seam to be possible (but on the edge of it) using squid. Squid is actually capable of intersecting https traffic and it appears the connection to it can be encrypted using command line options. Details are available  here (at the bottom). You should also note that while no other software will be required client side, you will need to trust squids ca certificate. This is fundamental to the security of https without it anyone could monitor your traffic.


Masking configuration of physical workstation

There are myriad of ways to fingerprint a system from the OS version, registry entries, functionality advertised, driver versions, applications, hardware available (chipsets, drivers associated, etc.).

Trying to fool all methods of fingerprinting a system is likely a task that's not worthwhile.

You may accomplish a similar result by sandboxing applications which you would like to hide this information from.

Alternatively you could use a virtual machine since they typically look very similar to each other (hardware emulation) but that doesn't hide the OS or other applications.

Attempting to fool applications can also lead to unexpected and potentially damaging behavior. A program which thinks it's running on Windows 98 is going to behave differently than one that thinks it's in Windows 10. This may result in security issues if programs attempt to use "compatible" but insecure methods (e.g. SSL 2, or 3 instead of TLS; MD5, RC4, etc. )


Is this login flow via an authenticated email account safe?

A similar question was posted recently: Is this password-less auth flow secure?

My answer - in short - was, don't do it (creating a new "security protocols" requires a lot of knowledge, effort and QA and apart from that the combination of mail, get-parameters and so on sounds pretty error-prone).

To the question "how secure is mail":

The problem is, both sending mails (via smtp) and receiving mails (via pop3) are unencrypted. It's exactly the same thing as using http for web traffic: a man in the middle (mitm) can read and compromise everything.

The question is, how big is the risk of being a victim of an mitm-attack? This depends heavily on the scenario. Are you often connected to a public wifi? Then chances are good that there might be a hacker or just a troll in the network. Are you mostly connected to a switched and properly configured private lan? In this case, it's harder for an attacker to compromise the network and sniff the traffic. How responsible is your internet behaviour in generall in terms of "accidentally" download a malware? And so on


Are Printers running Linux 2.6 something to be concerned about?

The answer depends on how the printers are being used and who they are exposing themselves to. Assuming they are only listening on your local network, then the old kernel (and presumably other old software it runs) will be vulnerable to a variety of attacks. An attacker on your local network may be able to compromise the printer. If the printer is being exposed to the global internet, then there are bigger problems, and it may be possible for people all around the world to gain access to the printer and LAN.

While updating your printer's software is not likely to be possible, you can use a firewall external to the printer to block the open ports and only allow trusted connections from trusted sources.


At what table size does salt reuse make rainbow tables cost effective?

It depends

The purpose of the salt is to force a malicious user to use a dictionary attack instead of a rainbow attack.  The reason for switching will depend on the attacker's intention and resources available.

Single user

If a hacker is trying to get the password for a single user, he wouldn't use a rainbow attack anyway.  A dictionary attack is actually faster against one database row (unless the hacker is extremely unlucky).

Just targeting common passwords

If a hacker is only trying to find users who are using very common passwords, he can construct a pretty small rainbow table, one for each of your salt values.  The more salts you have, the more tables he'll have to create.  But there is no magic number.  It will depend on the resources available to the hacker and the size of the password list he is looking for.  Because each rainbow table would be small he may be willing to create hundreds or thousands of them.

Trying to get every single password

If a hacker is trying to crack every single password in your user base, he will need to construct a full rainbow table for each and every salt.  If there are too many salts, he will decide it is easier just to switch to a dictionary attack.  The threshold for this would probably be subjective and indicental... e.g. if the hacker had enough storage space for 100 rainbow tables, then using 101 salts would cause him to switch to a dictionary attack.

On the other hand, if your table has very few users (not few salts) then a dictionary attack may be faster anyway.  When you have millions and millions of users then an attacker would be willing to go a lot further to avoid having to use a dictionary attack.


How secure are expiring tokens and refresh tokens?

It could be that the access token might end up being used around the application over plain HTTP connections. So if an attacker sniffed it, they would only have short term access. This is what used to happen on the web as standard. Login was over HTTPS if you were lucky, and the rest of your session was over plain HTTP, transmitting the session ID in cleartext.

The refresh token is only transmitted to the authorization server, so it is easier to enforce HTTPS only, meaning that an attacker could not eavesdrop on this connection.

See here for more information:

  There is a security reason, the refresh_token is only ever exchanged
  with authorization server whereas the access_token is exchanged with
  resource servers.  This mitigates the risk of a long-lived
  access_token leaking (query param in a log file on an insecure
  resource server, beta or poorly coded resource server app, JS SDK
  client on a non https site that puts the access_token in a cookie,
  etc) in the "an access token good for an hour, with a refresh token
  good for a year or good-till-revoked" vs "an access token
  good-till-revoked without a refresh token."


How to restrict SSH access outside of LAN?

This is exactly what you want, I googled: only allow root ssh lan

First hit...
http://drsavoye.blogspot.com/2010/06/enable-root-login-from-lan-only.html

  On Linux, edit /etc/ssh/sshd_config. On Macs, edit /etc/sshd_config.
  Locate the line that defines PermitRootLogin, uncomment if it is
  commented out, and change its value to yes.

  On a separate line, add the following:

  Match Address 192.168.2.*,127.0.0.1
        PermitRootLogin yes

Of course, changing 192.168.2 to match your LAN subnet.


Multiple extension vulnerability. Is this malicious file triggered during form preview or after it has been uploaded?

This attack would require two requests,  one to upload the file and another to execute it.   It appears as though the 2nd request is attempting to execute the uploaded payload.  My guess is that the first request is generated by the normal function of your application and is likely not the request that uploaded the file.

In any case you should try replacing that uploaded file with a hello world and try replaying these requests from your log.  Also make sure to manually audit the code responsible for file uploads.


I just found many facebook entries on my registry?

If they keep coming back, it means that you have some software running checks on them. You should take some tool to analyze the running processes on your machine.

Use Process Explorer to look at the current running processes (so that you can find out which one is recreating the reported keys and Autoruns to check the list of programs initiated automatically at startup (search if the above process is configured to startup with windows, or if you have something suspicious installed).

Only by researching the name of the binary you will be able to discover what it does and figure if it should be there or not.

A common source of issues like this is the installation of software that comes bundled with adwares (the ones that have to be unchecked during the "next->next->finish" sequence).