With reference to using Gpg4win, which is better: OpenPGP or S/MIME? Which is better -- OpenPGP or S/MIME for higher security?

The most important security differences between OpenPGP and S/MIME have to do with trust models and certificate formats.

OpenPGP uses a "web of trust", which allows individuals to freely sign the keys of other individuals.  You could think of it as an early form of social network.  There are a variety of ways to find signature paths from one user to another, and define levels of trust based on the number of links and the user's estimation of how much to trust a given signer.  An extensive web of trust has been built up over time, particularly among some segments of the security community.  See Henk Penning's analysis of the strong set in the PGP web of trust for the latest information.

S/MIME uses the x.509 certificate format and trust model, similar to web site security via TLS/SSL.  In this model a set of root certificates is typically defined as trusted within a given mail client by the vendor.  This can be more convenient for deployment in organizations which deploy a traditional PKI.  It leaves the user with less control, and typically requires participants to purchase certificates from a commercial CA if they are not part of an organization which deploys a traditional PKI.
See How feasible is it for a CA to grant exceptions to the verification process? Which default trusted root certificates should I remove? for some issues with the traditional CA model.

Of course, another issue will typically be the question of what your correspondents use, what sorts of certificates they have, and what other uses you intend to make of your trust/signing/encryption infrastructure.  For example, OpenPGP signatures are used to authenticate many open source software packages, while x.509 signatures are used for signatures in pdf and office suites.


What is the real risk from trusted forests / domains? I am trying to identify specific attack vectors that occur due to domain/forest trust in Active Directory. Microsoft in their KB Articles Domain Trust, section "Considerations About Trusts" write that:

  Domain administrators of any domain in the forest have the potential
  to take ownership and modify any information in the Configuration
  container of Active Directory. These changes will be available and
  replicate to all domain controllers in the forest.

But there is no specific description of how. In Security Considerations for Trusts, Microsoft list two more specific issues:

Disabled SID Filtering here and here ( I understand you can disable it on external trusts?); and
Enabled SID history.

Are there any other attacks that are specific to domain trusts? e.g. SMB Replay attack isn't specific to trust. Also, how does the writing to Configuration OU can be achieved and what can you write from the other domain?

You can enumerate users

You can enumerate computers

You can query DNS for interesting information

If your domain is now in the search domain of the trusted domain you can use shortname replacements (autodiscovery) etc to try and trick client systems into accessing your resources insecurely and popping into social engineering environments.

This is generally a very bad idea if you're doing this with a third party.  This is why you have Federation systems that use SAML (eg ADFS.)


How do companies deal with storing their source code on GitHub from a data-loss risk management point-of-view? When it comes to storing my data "in the cloud" (aka: on someone else's server), I alway have kind of a bad feeling that something like "Google's deleted an artist's blog, along with 14 years of his work" might happen to my data, too.

On the other hand, even big companies like Microsoft store lots of source code on GitHub.

My question:

What is the usual policy of companies storing their source code on external servers when it comes to minimizing risks of data loss?

E.g.

They could rely on GitHub making enough backups.
They could have a policy to always store data in local data centers before publishing to GitHub.
They could have special contracts with GitHub to get additional backups.
They could fetch the data through GitHub APIs and store it locally.
…

So actually I'm just trying to understand why/how Microsoft (or other companies) can publish code to their public GitHub repositories and which security strategies they are applying to protect themself from data loss.

Maybe my question is to some degree opinion based, on the other hand there could be a chance that someone from Microsoft (or other similar companies) reads here and can actually answer that question.

Update 1

I'm not asking on how Git(Hub) technically allows you to distribute your source code. I do hope that I understand most of these concepts.

I'm more asking how to convince management from a security point-of-view to allow their intellectual property (i.e. source code) being stored on external servers by an external company.

And since lots of companies, including big ones like Microsoft actually do use GitHub, I'm interested on how they deal with this.

Update 2

I've added some extra words to hopefully make it more clear that I'm mostly concerned about data loss.

Don't know if this is still security related, though.

Contracts

The artist was presumably using Google's free services. The terms and conditions of such services tend to boil down to "we own everything, you have no rights" (disclaimer: I don't know the exact terms for the artist).

When companies pay serious money for an enterprise cloud platform, they have a contract that is much more in their favour. There is still a risk the provider could mess up, but this particular scenario could not happen.

Some other approaches are multi-provider redundancy and offline backups. Multi-provider does seem a good solution - although I've not seen it done in practice. Offline backups are problematic because of the high bandwidth needed to perform a backup.


Remove domain from web filter blacklists A domain with a checkered past

I work at a company that purchased a .com domain around a year ago, and it uses this domain for its web site and e-mail now.  However, the previous owner had a site (last online several years back) on the domain which was pornographic in nature.  The site is now G-rated and has no adult or otherwise offensive content whatsoever.

E-mail blacklists have not been a problem, but some web content filter blacklists seem to block the site.  We've sent e-mails to various providers, such as Sophos, that we have found to block the site to request review and removal.

These requests usually get us removed eventually, however, sometimes it is difficult to determine what the blocking engine is.  For example, recently someone reported that if they go to the web site on a Virgin America flight, it redirects to the Virgin America homepage as if a content filter triggered a redirect.  It's hard to tell what mechanism they're running.

How to get unlisted?

My question is:  What is the best way to approach getting removed from content filter blacklists?  Are there services/consultants that specialize in this? Or shall I truly be reduced to a game of whack-a-mole trying to hunt down and e-mail these blacklist/content filter operators as we notice problems?

There are a LOT of blacklists.

I use often this tool, and it currently shows 103 blacklists. You might need to check each of these:

https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3astackexchange.com&run=toolpage#


Unsolicited SMS from Facebook I got the following SMS from number 32665 (FBOOK):

  "Confirmed! To edit SMS preferences go to m.facebook.com/settings. To turn off all SMS messages reply stop. Reply help for other option. SMS charges may apply"

I'm worried someone hacked into my account, since I did not do anything in the last weeks that would generate this message.
I think this SMS means somebody enters a confirmation code in a new deviced to be recognized. For example, the message is generated in the following simple hack. That hack which was fixed quickly.

Is there a way I can find out why this SMS was sent? Sadly, the activity log doesn't show security-related actions (such as logins). I didn't see any unknown devices under "Security > Your Browsers and Apps", but someone could potentially delete himself after checking something out.
I had login notifications & login alerts on all the time.

If you had notification alerts on, you would receive the login alert over SMS / E-mail (depends on you what have you chosen).

And if you suspect that someone hacked into your account immediately change your password.

Now, to answer your question:

  "Is there a way I can see why this SMS was sent?"

There are no results for this question and I can't help you with this but I guess someone really accessed your account.  And argument for being suspicious right now is the activity/behaviour you described.

It's also recommended to enable the SMS alert when new device connects. Maybe the Facebook security tips are known to you already, but I prefer you to check them again. LINK

Also verify your email related to the FB account. An attacker could gain access by using your hacked email...

  Sadly, the activity log doesn't show things like that. I didn't see
  any unknown devices under Security > Your Browsers and Apps, but
  someone could potentially delete himself. I had login notifications &
  login alerts on all the time.

SMS or Email alerts? by hacking your email the attacker could delete logs.


An alternative for /dev/urandom I like to overwrite my harddisk with random data.

Since /dev/urandom as source is too slow to overwrite a large amount of data in a reasonable time, I'm looking for a good alternative.

These two options meet my speed requirements:

(1) openssl with AES

openssl enc -aes-256-ctr -pass pass:"$(tr -cd '[:alnum:]' < /dev/urandom | head -c128)" -nosalt </dev/zero | dd bs=64K ibs=64K of=/dev/sdX status=progress

(2) shred

shred -vn 1 /dev/sdX

If I've understood correctly, shred uses ISAAC PRNG/stream cipher.

My question is: What option produces better (pseudo) random data or can these two called equal?

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

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

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

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

I tried perf to see what linux is doing:

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

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

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


What are the possible security issues (breach/losing access) with sharing passwords manually? I am thinking of forming a team in either LastPass or 1Password.

LastPass is free if I don't intend to use it to share my passwords.

I am wondering, why would I need to form a team?

If I want to share a password with my buddy I can just type the password in Skype and he can insert that password to his password manager. Why need the complexity of "teams" and "families"?

Complexity is a factor. If I misunderstand a feature, things can go really really wrong

Such as this https://discussions.agilebits.com/discussion/96592/can-i-share-passwords-without-team-or-family#latest

Is it worth the trouble to share password via password managers' share feature?

The only benefit I can think of is that changing a password is "propagated" to my buddies.

However, most of our passwords are not shared and we share only at most 10 passwords with each other.

Sharing a password is always a problem because you never know where it is going to end up. For example, if you send it by email, it might end up in the backups of the hosting provider, in the email client of whoever you sent it to, etc. Not to mention that apparently email can still be sent in the clear (not encrypted) from one server to another, or at least so I learned. As for Skype for example, the password might remain in the chat history, either on the user's device or on Microsoft's servers.

Apparently (or so I learned) an acceptable way to share a password is to use separate channels to send the information. For example, you might encrypt it, and send it encrypted via email, and then tell the password for decryption in a phone call. Or send a piece of the password via SMS, and the rest in a phone call. This way it's going to be harder for an attacker to intercept the password or recover it.

As you see all this can get pretty complicated (and a pain in the neck). LastPass and other online password managers then can make your life easier for this task, by allowing users to share some passwords with other accounts.


How to fairly pay out bug bounties without going over budget? I work for a small company and for our webapp, we want to offer bug bounties for vulnerabilities reported with monetary rewards based on criticality.
Problem is we only have a limited overall budget and dont want to promise anything we cannot pay. My question is: how to best phrase out the terms for our bug bounty project.

Let´s take some imaginary numbers and an imaginary situation to describe the problem. Say the overall budget is 1000. I would offer 200 for a critical vulnerability reported.

Now I start the program and receive ten reports coming in one after another, report A, B, C, ... Each report contains a critical vulnerability, as claimed by the reporter. Now I take my time and check each report and if it is valid. In the mean time, I get more reports. Let´s say, I have validated the first 5 ones as being critical. My budget would be exhausted in paying the reporters, but I still have more reports with valid vulnerabilities.

What is the best approach here from your suggestion? Splitting? Paying based on "first in"? I don't want to bait people with false promises, but I also do not want to drain our finances. I would stop the reward announcement of course once I realize that the budget is running out.

Also, a related question: What is a good practice if two reporters claim the same vulnerability? Do you reward both, do you split the bounty or only reward the first one in this case? I mean someone could just report under a different name with a slightly modified POC...

Thanks for your thoughts

You are the vendor, so you make the rules. Just be clear about them.

  Problem is we only have a limited overall budget and dont want to promise anything we cannot pay.

Then be clear about that. It's not uncommon for programs to do challenges/events where they pay special rewards for e.g. the first N critical reports, or pay extra for the best report submitted in a given time frame. So you could establish your budget as a "reward pot" from which you pay bounties until it's depleted. Or give rewards based on a ranking (e.g. monthly) - best report gets X, second best Y, ... This way you can keep your budget capped. Just make sure you clearly explain your reward scheme and stick to it.

  What is a good practice if two reporters claim the same vulnerability? Do you reward both, do you split the bounty or only reward the first one in this case?

Always only reward the first report. (Double-check that you didn't mix up the timestamps.) Hearing that a report is a dup can be frustrating, but bug hunters know about this risk. Also, it's good practice to CC the reporter of the duplicate on the original, so they get proof that there's indeed an earlier report, and can follow the progress.

Some additional practices I've seen in real-life BBPs:

Start with low bounties and work your way up. You can state in the rules that bounties will be increased after the program's test phase.
If multiple reported bugs share the same root cause, treat and reward them as one.
If you notice many valid reports target the same component, temporarily exclude it from the scope (but still reward the earlier reports!) and conduct a manual audit before moving it back into scope.


What questions should I ask a vendor that provides hosted encrypted email? I am evaluating a service provider that performs the following functions with email:

A user logs in to a web based application over an SSL connection.
Email is composed in a web browser over the SSL connection.
The email is then sent to the recipient's account with the same service provider.
The original email stays on the service provider's systems, and a notification email is sent to an email address that is associated with the recipient's account.
Recipient logs into their account and reads the email over an SSL connection in their web browser.
All encryption keys (one-way) are stored on the service provider's systems and are secured with the users' password.

I've come up with a few questions to ask already, such as:

Can I bring my own keys.
How can I migrate away from the service provider if need be?
Are you SOC-2, SOC-3 and/or SAS70 compliant? (Thanks to Jeff Ferland for that!)
How are the physical grounds of the service's backend secured?
Are the backend systems disk-level or volume-level secured?

What are some other good questions that an email security provider such as this should be asked?

This sounds like a closed communication system where the content isn't actually "sent" from their system.  You mention that data is encrypted once entered and that:

  "All encryption keys (one-way) are stored on the service provider's
  systems and are secured with the users' password."

I'm not certain what you mean by "one-way" here, but I'll assume you're referring to symmetric encryption which uses a single key such as AES.  My questions here would be what encryption algorithm they're using, and how are the keys generated and stored.  Are they using password-based key derivation?  If so, are the generated keys stored anywhere?  If not, how are they storing the keys they're generating?  As for the account itself, what processes are in place to reset a lost password and how difficult would it be to impersonate a user on their system?

As for a scenario, if a FBI were to walk into the data center and roll out a rack of servers and theirs happened to be among those taken (whatever the reason), would they be able to access the stored data with physical access to the equipment?  What procedures are in place to protect data in the event of a physical security breach?

Also, how are they backing up their data?  On-site?  Off-site?  Is the backup encrypted and who has access to it?


Identity theft from ubuntu machine? Recently my debit card information went to another hand, and he/she started to using it until my bank reports that there is an overdraft. I use Ubuntu 14.04 machine.

I am sure I am not a victim of phishing, or email-scam. But I sometime use debit card for online purchases.

Moreover, after going through my account history, I have noticed that these unauthorized transactions occurred just a couple of days after a taxi ride, where I had to pay with my debit card.

And during the same time I just started to explore the Tor network.

I do not have any firewall.

what could be the reason? Any idea?

You describe three possible attack vectors in your post:

Payment details stolen from an online service.
Taxi driver recording and using your debit card information.
Payment information stolen from your computer.

Of the three, I'd rank having it stolen from your computer as the least likely.  There's very little Linux malware, and most of it is focused around taking over computers and using them as servers/botnet nodes, rather than the typical Windows malware that tries to steal financial or account information.


PCI audits, TLS 1.0, and scoring I'm new to security in a variety of ways. We have a PCI audit coming up soon. We've put together a risk mitigation/migration plan for TLS 1.0 and have submitted it to the auditors.

My boss is focusing right now on addressing various TLS 1.0 sources. He calls it an "easy win", to get some of the low-hanging fruit out of the way. If we have any larger issues, then getting some of these easy wins will lower our score elsewhere.

But, we filed a mitigation/migration plan. That's all the PCI-DSS 3.1 calls for, it doesn't call for immediate remediation.

It's almost certainly me misunderstanding something. What am I missing?

TLS 1.0 (and 1.1 in some configurations) are not considered to be secure and thus PCI compliant.  Currently PCI allows the creation of a mediation plan that will have everything resolved by June 30, 2016.   This is due for some browsers (IE) not having TLS 1.1 on by default.


Understanding Cipher suite prefixes I have been lately reading cipher suites and how it works. I figured how it works in the web servers and there is a doubt regarding the prefixes used in the order.

How are RC4-SHA and RC4+SHA different?

Can anyone give a better explanation of how the prefixes work?

From the documentation:

  CIPHER LIST FORMAT...
  It can consist of a single cipher suite such as RC4-SHA....
  Lists of cipher suites can be combined in a single cipher string using the + character. This is used as a logical and operation. For example SHA1+DES represents all cipher suites containing the SHA1 and the DES algorithms.

Thus, RC4-SHA is the RC4-SHA cipher, also known as TLS_RSA_WITH_RC4_128_SHA:

$ openssl ciphers -V 'RC4-SHA'
  0x00,0x05 - RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

RC4+SHA instead contains all ciphers which use RC4 encryption with SHA1 as MAC, i.e.

$ openssl ciphers -V 'SHA+RC4'
  0xC0,0x11 - ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
  0xC0,0x07 - ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
  0xC0,0x16 - AECDH-RC4-SHA           SSLv3 Kx=ECDH     Au=None Enc=RC4(128)  Mac=SHA1
  0xC0,0x0C - ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
  0xC0,0x02 - ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
  0x00,0x05 - RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
  0x00,0x8A - PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1


wireshark does't show HTTP requests from other devices My machine along with several other machines are connected to wireless router.
When i open some http page on same machine(M1) where wireshark is installed, it captures the packets such as HTTP GET or POST but when i open same http page from other device(M2) which is connected to same router, i see the entry for it in wireshark installed on previous machine(M1) but does not show GET or POST. Instead I see many NBNS entry for M2 in wireshark installed on M1. By this way, one machine can't see the sites which are visited from other machine.

There are many youtube videos showing that it is possible to know the sites that are being visited from other machines.
In my case, I see some entries for other machine but not HTTP request which I was actually doing from other machine.
Is this a config problem?

Network traffic can be either unicast or broadcast (or multicast, but that's not relevant right now.) NBNS (NetBIOS Name Service) is broadcast, so the switch (your wireless "router" in this case) has a responsibility to deliver it to every host "attached" to it. Most other traffic is unicast, which means the switch should send it directly to the recipient.

Different kinds of layer-2 network devices do this in different ways:

Hubs simply broadcast everything to all their ports, regardless of destination.
Switches keep a table (the CAM table) of which MAC addresses are using which ports, and send unicast traffic to the appropriate port.
Wireless switches without encryption act like a hub, since radio is omnidirectional.
Wireless switches with encryption (oversimplification, assuming WPA) use individual keys to protect unicast data intended for a single recipient, but shared broadcast keys to send broadcast data.

In order to see the traffic destined for some other machine on your network, you need to do some traffic manipulation. Your options generally are:

Use a hub instead of a switch. Not possible in the wireless case.
Sniff directly from the switch (sniffer software installed on the switch.)
Configure a span port on the switch to receive all traffic regardless of destination.
Use ARP poisoning, ICMP redirection, CAM flooding, or other traffic manipulation to trick the switch into broadcasting unicast traffic.


DNSSEC implementation questions (BIND 9.10) I am planning to sign multiple DNS zones with BIND and have the following questions which I could not answer by reading the latest BIND 9.10 Reference Manual.

How can I use the same ZSK with multiple zones? When generating a new key with dns-keygen name seems to offer -n nametype where nametype can be one of ZONE, HOST, ENTITY, USER, OTHER. Can one of them be used to associate the generated ZSK with a set of zones?
Where can I specify what directory the signed zone files (*.jbk, *.jnl, *.signed, *.signed.jnl) get put into when using inline-signing yes;? I'd rather have the directory with the original zone files (which get edited manually) rather clean and put the auto-generated files somewhere else.

Since I am not sure whether or not "Stackexchange - Information Security" is also intended to be used for specific implementation questions, please move the question if it doesn't fit here.

1 (Same ZSK):
You should not use the same ZSK for multiple zones (as far as I know), as it is a zone signing key. There should be one ZSK for every zone.
2 (Journal Files):
You cannot move the journal files with the current version of bind, however you can make the zone files in the directory bind uses symlinks to files in a cleaner directory.


Are SAN IP addresses / DNS names useless in self signed certificates by untrusted CAs? I want to generate a self signed certificate for temporary local testing of a web service via HTTPS. I don't want to install the CA though, because the self signed certificate is generated on the fly with each start of the web service and I'd have to install the new CA each time. I'm fine with clicking "Advanced -> Proceed (unsafe)" each time.

So when thinking about which IP addresses and DNS names to add to the SAN, I tried out using invalid and empty DNS names, but Firefox and Chrome didn't complain about mismatching hostnames at all. They only complain about the untrusted CA. Edge on the other hand complains about the mismatching hostname and only when including the host that's used for accessing the web service is used as IP address / DNS name in the SAN it complains about the untrusted CA.

I was expecting to be warned about both issues in all browsers: The untrusted CA and the mismatching hostnames. Because let's say I temporarily trust ("Advanced -> Proceed (unsafe)") self signed certificates based on what Firefox lists under "The certificate is only valid for the following names:", I still want to be protected from Man-in-the-Middle attacks, no?

Currently, if I generate a self signed certificate with SAN IP address "127.0.0.1", "192.168.178.123" (LAN IP address) and DNS names "localhost", "alice" (hostname) and "alice.local" and I temporarily trust the CA, an attacker could now redirect the traffic via his machine with the DNS name "eve.local" and generate a new self signed certificate with "alice.local" etc. (but without "eve.local") and I as the user would only be warned about the untrusted CA.

If this behavior is intended (by the browsers), why bother setting a SAN at all? Just setting "" as DNS name seems to have the same effect (at least when the CA is not installed).

If you make an explicit exception to bypass a a certificate warning this exception is only valid for this specific certificate on this specific domain. It does not matter what domains are mentioned in the certificate, the exception is only added for the current domain. Thus, even if you accept a certificate which contains a SAN of paypal.com on your testsite.example.org this certificate will only be trusted for testsite.example.org and this trust can not be used to silently MITM access to paypal.com.

In other words: the specific content of the certificate (CN, SAN, expiration ...) and also the issuer (self-signed, signed by untrusted CA) are irrelevant when adding an explicit exception.


Are non-SSL connections safe in a local wireless network with password protection Shortly: I am working on a project in which several IoT devices are connected to a WPA2 password and MAC filtering protected hotspot. Can the communication in this network be leaked since I do not use TLS?

I do not want to use TLS since the resources of my IoT devices are really limited, and implementing TLS would occupy much of them. Therefore, I want to create a private WiFi network, with WPA2 password protection and MAC address filtering, so I can ensure that only devices that I allow are connected. The only question in my mind is, can the information sent over this network be stolen? Does password protection only stops foreign devices to join network or does it encyrpt the data as well?

PS: My private WiFi network has no internet connection, it's just Access Point+IoT devices.

Although messages sent over wi-fi are encrypted with a session key, a device that already knows the pre-shared key can decipher the traffic. WPA doesn't implement Forward Secrecy, therefore by owning the pre-shared key anyone can decrypt all the traffic which is not encrypted by upper OSI layer protocols (say, TLS).

Therefore, when transferring sensitive data you should use an external data protection mechanism - for example, TLS.


PGP keys varying only in attached signatures Here is a few questions revolving around the same core problem.

Let's say I generate a PGP keypair.
I now get the keypair signed by person A at signing party X.
In the evening, I give my now-signed public key to person B.
Next day I get my public key signed by person C at signing party Y.
In the evening, I give my now-signed public key to person D.

Person B and person D now both have my public key, but different versions (I don't know if version is the right word).

Imagine a person E obtains my public key from both person B and person D.

How does person E determine which one to use?

Similar, I could start by making two copies of my public key and then get them signed by two mutually different groups of people.

Again, how can a later-coming person's PGP software determine which one to use?

I wonder if it can automatically merge the signatures in to an all-containing key, if and only if the list of attached signatures need to be self-signed by my private key.

Finally, do people keep uploading their keys to keyservers as they get signed by more and more people?

A public key like published on the keyservers actually consists of a set of single packets. One is your public key, then there are user IDs, and the incoming signatures from other keys (and some more stuff which is not important here).

  How does person E determine which one to use?
  Again, how later-coming person's PGP software determine which one to use?

As stated above, the key is the same, just the signature packets are differents. You can have a look at them using gpg --listpackets [file], also have a look at this answer on how to view OpenPGP key files. I strongly recommend to have a look at the rather lengthy output to understand what's going on.

When "updating" the key (gpg --recv-keys [key]) from a key server, all the new packages will get merged with the ones already on the disk. The keys do not "branch" in any kind. Imagine this as the union of signatures sets. This can also be done by exporting and importing using gpg --import [file].

  Finally, do people keep uploading the[ir] keys to keyservers as they get signed by more and more people?

I hope I got your question right, and you want to know whether people upload their key from time to time to distribute their new signatures using gpg --send-keys [key]. Then, the answer is a clear "yes and no". Most do, a lot only now and then, and some not at all.


What are the variables of AES? AES is a standard encryption routine that can be used consistently across multiple languages, assuming all the variables match up. My question is, what are the variables. I am aware of the following

Variant (is this AES-256, or just plain AES-128)
Data to encrypt
Key (128 bits is common)
Initialization Vector - now what is this? Is it also 128 predetermined bits?

I understand from reading Wikipedia, that the IV is used to prevent two identical 16-bit blocks in the overall stream from being identical after encryption, as that would make the data more guessable.
Is there also a mode?

I'm guessing this is gonna be padding/streaming, vs required 128bit length.. but how many modes are there, or is this diverse?

Sorry if I got some of this wrong, but I confused, and would like a clear list of the variables. I think I got them all, but I am not sure if I got them right.

The AES cipher has only one parameter: the key. Indirectly, also the AES variant is defined.
You have AES-128 for 16 byte keys, AES-192 for 24 byte keys, and AES-256 for 32 byte keys.

I don't consider input data to be a parameter.

Orthogonal to that you have the chaining mode, which is the way you manage to encrypt/decrypt pieces of data that do not match the block size of the cipher.
For instance ECB, CBC, CFB, etc. I use the generic term cipher because a chaining mode is applicable to any block cipher, and AES happens to be one amongst many (e.g. you have TDES, Blowfish, etc), with a constant block size of 16 bytes.

Some chaining modes (CBC, OFB, CFB, GCM) require an Initialization Vector, which very often matches the block size of the cipher. In some cases, the IV is called nonce and it may be smaller than the block size (e.g. for CTR).

Finally, some chaining modes may require the plaintext to have a length multiple of some value (e.g. block size for CBC, segment size for CFB). In those cases, you may need to also define the specific padding algorithm (e.g. PKCS7-style).


What happens when CA server is down? Let's assume that I have a server which accepts requests over HTTPS. The server resides in a closed environment, and relies on a local CA server. I am not sure if this is relevant, but the server is written in ASP.Net WebAPI.

What happens if the CA server goes down? Does that mean that the client will not be able to send responses over HTTPS? Does it mean the server will not understand them?

The CA is used for signing the certificate which then gets used inside the HTTPS connection. The CA is not involved in the validation of the trust chain of the certificate since this validation is done using the locally stored (and trusted) copy of the CA's certificate (root CA).

The CA will be involved when revocation checking is done using OCSP: If the OCSP responder does not work then the revocation check will temporarily fail. The failure handling depends on the browser, configuration and type of certificate. Usually browsers simply continue when OCSP checks cause temporary failures (i.e. unknown if certificate is rejected). The only exception is usually the revocation check for Extended Validation (EV) certificates, but browsers can often be configured to do strict OCSP checks in other cases too. Chrome is known for not doing OCSP checks but using some other source for revocation checks, but it might be that it will still use OCSP in case of private CAs.

Note that failure of the OCSP responder could be partly mitigated at the server side by periodically retrieving a new OCSP response from the responder and attaching it to the SSL handshake (OCSP stapling). In this case the browser does not need to ask the OCSP responder and thus will not have problems if the responder fails. Of course this can only be done for a limited time, because the stapled OCSP response has a limited lifetime.


What are the security implications of allowing API consumer to decide primary key stored in database? Story

We are developing an API that which allow consumer to create or modify (i.e. upsert) objects stored in database via an endpoint with HTTP PUT.

The primary key of the object stored in this way is a GUID instead of an auto-increment number to prevent potential conflicts in future and it was decided that the GUID should be provided by API consumer in both scenario during object creation and modification.

We are being informed that the advantage of this approach allows us to focus the intention of storing objects without differentiate between create or modify.

Question

In this case, we expect the API consumer to pass a GUID as object identifier and what can go wrong security-wise if we allow someone else to decide the primary key of the object stored?

I understand I may treat the provided GUID as candidate key and generating another unique identifier internally but it seems redundant and wonder if it's a plausible approach.

It depends.

Objects are Secret

If the data being uploaded with those GUID is considered secret, then you do not want users to share the same GUID. For that reason, you want to include another identifier in your primary key to make sure that each customer has its own set of GUIDs. In other words, as Conor mentioned in his comment, every user would be able to create an object with GUID 12345 and the customer has no clue that another customer also has a object with GUID 12345.

You can easily do that by adding the customer identifier to the GUID to identify the object(s) on a per customer basis.

Note that in this case you would also include a way to identify the user since the data is secret. Either a long UUID like string that was given to the user when they logged in or directly the credentials of the user (that one only works if only the costumer's server access your server since such credentials.)

Objects are Public

When objects are anyway public, there is no real security issue. However, it puts a burden on the client which is to generate a new GUID when an upload fails because of a clash.

Now, a GUID should be unique so the possibility of a clash is minimal. It probably would happen because a hacker is trying to find objects which said hacker should not otherwise know exists.

Since the data is public, though, having a hacker find it is not big deal. It's available to them one way or another...

Identifier

The idea of an identifier that gets incremented has been used a lot and it is still being used a lot.

If the data the identifier references is public, then it is not important to have a number incremented one by one like this.

However, something that should remain somewhat secret should not use such numbers. This is because a hacker can easily check for all the objects by using a URL such as:

http://example.com/user/1
http://example.com/user/2
http://example.com/user/3
   ...
http://example.com/user/n

Now we can see that the hacker can find all the users. If the user's account is public, he can check their name, with that name, they can attempt a login with some random password. So you do have a vector of attack which is simplified.

Create vs Modify

Yes. This mechanism is used by many systems, especially in the NoSQL world. For example, Cassandra let you use INSERT or UPDATE to create and/or modify content.

Cassandra has one column which is called the PRIMARY KEY (as in SQL, only it can not be more than one column). That PRIMARY KEY is used to index the data. This is the same as your GUID only can be absolutely anything, including binary data.


In using a VPN service is it possible to transmit data without giving away system configuration details? In using a VPN service I want to feel comfortable in the knowledge that outsiders cant simply build up metadata on my browsing activities. The fact it is done is somewhat unsettling. I have spent days setting up and configuring a VPN connection for the purpose of transmitting only data which is absolutely necessary to navigate the internet. I ran many tools, conducted online tests and followed many tutorials in configuring patches/fixes for known security flaws.

Whilst running VPN service I used https://ipleak.net/ for checking status of the connection and it revealed things were able to be obtained and had to be fixed. The methods I used to fix them all are described at the bottom of the page.

PROBLEM is even when every measure I can find on the internet has been taken the website (https://ipleak.net/) is still able to obtain knowledge about:

My Screen Display (Resolution, Pixels & Colour Depth).
Information on all my installed browser plugins.
Types of documents my system can read.
The Referrer. (Website I Came From)

I would rather transmit as little as possible and feel some of this information obtained is completely irrelevant. I cannot find anything via the internet on any methods which I can take to resolve any of these issues and to stop the information being passed on. Looking for advice and opinions regarding this matter. Appreciated In Advance.

After deciding on using VPN service I conducted the following steps:

Set up Client VPN Gate Relay.
Configured IPv4 settings to set Ip address to static. Also changed
DNS Servers to 8.8.8.8 and alternate of 8.8.4.4.(Google Servers)
Disabled IPv6.
Patched known security flaw known as WebRTC which allows website
owners to attain both the VPN Server address as well as your ISP
assigned IP.
Configured and fixed the system so no DNS requests were being
leaked. In the leaking of DNS Requests cause a problem as information
can be obtained through the fact you are using the ISP Servers to
navigate through the internet.(I.E Browser Search)

Here are some Images showing the fact the the website can retrieve all this information while I am using VPN software even after everything I have tried and searched for.

taken from https://ipleak.net/

The information about OS etc. comes from the HTTP User-Agent header. You can install some plugin to fake the User-Agent to any other you like, or strip it out altogether.

The information about screen resolution comes from the Javascript layer and you can do nothing sensible about it. You could go and hack the browser binary, for example replacing "availHeight" and "availWidth" with "awailHeight" and "awailWidth". The browser will then no longer understand requests from "availHeight". The calling site will be unable to determine your screen size, and several sites you browse will appear broken (Also, several file integrity schemes will now trip and report your browser as corrupt, infected, or otherwise unreliable).

Another possibility is disable Javascript support altogether, but then many more sites will appear broken.

Finally you can install a virtual machine with different characteristics from your own machine, and browse from there.


How do I protect a Laravel backend API from hijacking/CSRF when there is a React frontend? I'm finding it really hard to find a solution to make secure requests via our API without a potential hacker being able to see sensitive secret information via Google Chrome dev tools (or any browser's dev tools), as React tends to show everything that's client-facing. Our backend hosts Stripe payment info (which may or may not be useful for a hacker), but also private user data.
The API endpoints we wish to protect are from frontend to backend, and they specifically retrieve user data from a MySQL table and backend scripts for features. It's for a public content platform, like YouTube or SO, where content is available for everyone whether they're logged in or not. (we have endpoints to show what content we want to display on the site and where - however each user has sensitive information that should remain private. I basically don't want anyone to get access to the MySQL user table).
Our Back-end and API use Laravel & PHP, and our Front-end uses React.
The current security set up is a password key that allows us to access our API, which changes every hour. Every hour, the key changes, and we use an endpoint to refresh the key (we have a 'master key' that doesn't change that allows us to do this). We pass this in the Authorization header. The issue with this is, a hacker can see this master key in dev tools. The header does not hide the key.
I've been exploring potential solutions, and these are the three potential solutions I've come across:
Solution 1: Send an encrypted token from the Authorization Header and decrypt it in the backend
Making a frontend request /requestToken that sends an encrypted token that is unique every time - only we just need to know the rules around building that token. Our backend knows how to decrypt it because it's in our special format.
A hacker will have to know the rules of how to build the token (they won't be able to copy and paste an existing one that they see in the front-end), as the token will be time unique, with any given token only being valid every 5 seconds.
This strategy is way more secure than our current one, but an issue I have with this is that a hacker can a) figure out how the token is encrypted because they can see it being built every time they make a request b) they can copy an existing token and use it for 5 seconds, and c) this encryption and request are happening on the front-end and so it can be seen by a hacker.
Issue: Everything happening on the client-facing React app is accessible publically (Source). I would use the solution in the link I just referred to, but it seems that it is for third party APIs rather than for an API that links our frontend to our own backend.
Solution 2: Laravel CSRF with React integration
Using Laravel's native CSRF tokens, and using it with React's frontend (not sure how to but scrolling to the bottom of this page gave some instruction). I have spoken to a few devs who have advised me to use Laravel Sanctum, but isn't it for SPAs (Single Page Apps)? My website has more than one page.
Solution 3: Using JWTs?
For JWTs, I found this solution, but it doesn't apply to me because my site doesn't require people to log in - and it seems that that solution requires people to log in in order for the API to be protected because it uses a password grant generated after a user has successfully logged in.
Which of these strategies are the best if any?

As you might be able to tell, I'm not a developer myself - I'm just trying to find someone who can help me protect my site's user data (which contains Stripe customer info in it, so the data is very important!). However, first of all, I need to agree on the best infosec strategy because I don't want to compromise on security at all.
The developers on this project are freelance without expertise in security.

Sensitive Data Exposure
You should ensure that no sensitive data is made available on the frontend simply by loading the page. The site should be designed such that sensitive data must be retrieved from the backend, and only after proving valid authentication/authorization to access such data.
CSRF
CSRF is only really an issue if you are using cookies for authentication; generally, CSRF protection is not needed for API endpoints. Since you haven't mentioned any need to log in or the use of cookies, I don't think this applies here.
Authentication

A hacker will have to know the rules of how to build the token (they won't be able to copy and paste an existing one that they see in the front-end), as the token will be time unique, with any given token only being valid every 5 seconds.

This seems like a problem; an algorithm should remain secure even if an attacker knows how it works (Kerckhoffs's principle); instead, security should rely on a secret key remaining secret.

a hacker can a) figure out how token is encrypted because they can see it being built every time they make a request

If you don't want an attacker to have the token, why do you give it to them in the first place? If it is needed to access the API, this makes little sense since it sounds like it is public already. If the token is needed for administrative API functions, the user/attacker should never be able to get your encryption key in the first place. So maybe the question could use a little clarity on what the API token is actually supposed to protect.

The developers on this project are freelance without an expertise in security.

Developers do not need to be security experts, but must have at least a general understanding of the security implications of the languages/libraries/frameworks they use. I suggest you find developers who have this awareness, or at least hire someone to do a proper audit of your systems before they go live.


Variable scope and security This question is directed at the .Net framework, but would hopefully be answered to encompass many languages & frameworks.

Let's assume I have a two methods, one which actually decypts data and one which takes the decypted data and returns it to the user:

private string Decypt_Data(string encryptedText, string EncryptionKey) {

    string plainText = "";
    using(SomeEncryptionClass  myObject = new SomeEncryptionClass()) {

        myObject.Key = EncryptionKey;  //lets not worry about how we create or store these
        myObject.IV = GetIV();

        plainText = myObject.DecryptText(encryptedText);

    }

    return plainText;  //REFERENCE 1

}

//specifically this is called from a controller after a POST
private ActionResult Read_Encrypted_Value()
{

    string encryptedEncryptionKey = GetDataFromDatabase("keyfield");
    string encryptionKey = Decypt_Data(encryptedEncryptionKey, GetKeyFromSomeWhereThisIsUnImportant());

    //decrypt data with plainText (ie. plainText is a key.. but this isnt important to the question)
    syromg encryptedData = GetDataFromDatabase("datafield");

    return View(Decypt_Data(encryptedData, encryptionKey));   //RFERENCE 2

}

Looking at the Decrypt_Data method, encrypted text is passed in and decrypted then the plain text is returned.

The question is... how secure is the value stored in "plainText" (at REFERENCE 1)?

The variable plainText only lasts for the scope of the method... but what then? Does that value remain in memory until the Garbage Collector deals with it? Does it get NULLed or something?
Should I do something like at REFERENCE 2, where I do the calculate and return the value together? Should I pass strings in as references, so that the variable returning the value doesnt need to be instantiated?

If the value remains in memory, is it not vulnerable? Can an attacker not read memory and steal the value? (I'm working on the princaple that this value is used to decrypt some other data... so the attacker having direct access to the database does not give him all the data).

The Answer

Thanks a lot everyone for your answers, I found this article: http://web.archive.org/web/20090928112609/http://dotnet.org.za/markn/archive/2008/10/04/handling-passwords.aspx in one of the links from user10008's answer. It pretty much covers everything you need to know + complete code listing.

You are right, this is a common problem for code handling sensitive data. In the .Net managed environment, even if you zeroed out your string, you would still run into problems, due to movement of the string as a result of garbage collection. The garbage collector wants to defragment the heap and therefore can move your string around. Moving of course doesn't zero the data, its rather copying. Therefore you should tell the GC to "pin" the particular string to prevent its movement. See above link on how to do that.

And no, the data doesn't get zeroed, it is possible that when your program exits (or before when it frees memory), this memory becomes available to possibly hostile other processes.

SecureString may store the data in a safe way, but you still need to interface it with the outside world. This question covers that topic.


Is there any security risk with a LUKS-encrypted hard drive being improperly unmounted? I have a portable harddrive that is encrypted with LUKS. On a computer I use it on, the computer bugs out sometimes and won't let me unmount it correctly. If the computer is powered off without a shutdown, or if the mounted HD is simply unplugged, is there any risk to the encryption on the disk, as in, could the keys be recovered more easily or would any data be partially decrypted or something?

I know there's a risk of data corruption, but I'm asking specifically about the security of the encrypted data after a sudden disconnection of the encrypted disk.

LUKS wont't write any unencrypted data to your encrypted partition. The keys are protected by locking them into RAM so they are not persisted.
I would pay attention to all non-encrypted partitions you have got. Make sure you wipe files instead of deleting them, and also wipe the free space of your unencrypted drives regularly to make sure they don't contain any unwanted leftovers. Also make sure your swap partition is encrypted if you use one. https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption


Why can't an anonymous server request a client certificate? In TLS a non-anonymous server can request a client certificate matching some criteria. However, it is a fatal error for an anonymous server to request a client certificate. Is there a good reason for this?

  A non-anonymous server can optionally request a certificate from
         the client, if appropriate for the selected cipher suite.  This
         message, if sent, will immediately follow the ServerKeyExchange
         message (if it is sent; otherwise, this message follows the
         server's Certificate message).

  [Further down...]

  Note: It is a fatal handshake_failure alert for an anonymous server
     to request client authentication.

Relevant part of the TLS RFC

In order to answer this I think it is important to look at the definition on what is a client according to the spec. In the Glossary a client is defined as

  The application entity that initiates a TLS connection to a
        server.  This may or may not imply that the client initiated the
        underlying transport connection.  The primary operational
        difference between the server and client is that the server is
        generally authenticated, while the client is only optionally
        authenticated.

This means that servers should always be authenticated and hence un-authenticated servers ( or anonymous servers) cannot ask for client authentication. In other words, since the client is initiating the TLS connection, the server should authenticate itself to the client before authenticating the client. I think the language could be clearer so there is no ambiguity.

In your comment you mentioned reversing the roles, so the TCP server becomes the TLS client and the TCP client becomes the TLS server. This is possible using some clever socket level programming. Take a look at STARTTLS which can be used to upgrade a plain connection to a TLS connection in a standard way. Netty is a Java library that provides such an implementation of StartTLS.


Is storing a short lived JWT on initial login in LocalStorage safe? I was reading this question and still have doubts about my use case.
I know it's unsafe to store a JWT in local/session storage due to XSS attacks. But what if it's for a JWT that only lasts 1 min when they first login? The client would then use this to get a longer + safer JWT to stay logged in from then on.
I'm using a third party identity provider to handle the initial login. The reason I have to do this is because their API that returns the JWT doesn't support httpOnly (for whatever reason). I still have to store the JWT temporarily somewhere before I get a new one in an httpOnly cookie from the server. Or should I store it in state (I'm using React)?
Is this approach safe? My reasoning is that even if they do get the JWT, it would only last 1 minute before it expires.
Overview

User enters credentials on login page. Identity provider returns a 1 min long JWT to the client.
Client stores JWT in local storage.
Client calls GET /getJWT with the JWT in step 2 in the payload.
Server validates the JWT. It issues a new JWT that lasts 15 min. Server sends a response with the JWT in an httpOnly cookie.

In this case. I would use a cache mecanism only for JWT tokens generated via backend. I would not recommend using session storage or local storage in any way. You may trigger a JWT token rotation for every two minutes or so. But be aware that this may slow down your application as it gets bigger by time.
In the last case where there is nothing to be done. I would recommend using server cross site-scripting header on the server to prevent XSS attacks and use the hidden html tag to store JWT Tokens and send it every request probably via an AJAX call if you work with it.


Is it safe to share a TLS Master Secret? I am debugging a client/server TLS communication issue with a 3rd party server vendor. For the client-side, I've captured a pcapng dump along with saved via a SSLKEYLOGFILE-like utility. Can I share the files in order to perform a Wireshark analysis?

The RFC 5246 describes Master Secret as being based on pseudo-random input per TLS session. Thus it seems it should be safe to share and not expose the risk of disclosure to other sessions.

I just need to make sure I don't cause a security breach.

The (Pre-)Master-Secret is unique per TLS session. If you want a third party to be able to decrypt a specific pcap with this TLS session but not anything else it is safe to give the party this secret, as long as the session is not reused anywhere else.

Note that a TLS session can span multiple TCP connections. To make sure that the session will not be reused anymore by the client it is usually enough to close the client, i.e. the client usually does not preserve session information over restarts. But you should also make sure that the third party has no access to other data captures from the same TLS session apart from the ones they are explicitly allowed to analyze.

Since a TLS session is always between a specific client and target you don't have to worry about the TLS session reused between the same target and another client or between the same client and another target. But "target" does not necessarily mean a single server - it is not uncommon that a domain has multiple servers and that these share TLS session information.


"1234 1234 XXXX 1234" in a statement from an ATM I got a statement from an ATM after I withdrew money where my card number was encoded like this:

1234 1234 XXXX 1234

where 1234 -- the real digits of my card. Since there're only 4 digits hidden, how vulnerable is it?

freeformatter.com has a nice overview of how credit cards are built up, and lets you easily verify if a given number is valid or not. Combining this with the fact that you only lack 4 digits, guessing your entire card number should not be too difficult.
So how bad is that? Well assuming your card's validity date and its CVC number is not compromised, it would still require some amount of guessing to get everything needed to abuse your card. Such info may be possible to discover in various ways, depending on what type of card you have (only Visa cards are susceptible to the particular method described here; others will block multiple failed payment attempts for a single card even if they originate from different stores).
So how do you minimize any risk here?

Well, first of all, avoid letting any such statement (I assume it was a paper receipt) lay about for anyone to find, and try in general to keep secret

Secondly, enable some kind of two factor authentication for your payment card, if possible. To quote the linked article:

Additionally, all payments secured with the 3D Secure technology (Verified by Visa, American Express SafeKey, or MasterCard SecureCode) are also safe. Payment card owners are urged to turn on 3D Secure details for their
accounts, which in most cases are provided for free.

Personal side-note rant: I think it's kind of absurd that basic info in clear text which everyone carries around with them everywhere is enough to carry out a transaction on someone's behalf. This is reminiscent of how a social security number can sometimes be used to do stuff that ought to require more thorough authentication. The issue in both cases is that what should be considered an ID number is treated as though it were a password. In an ideal world, some form of two factor authentication should be the default - then it would hardly even matter if both your card number and its expiration date were public information.


PGP/GPG verifying authenticity My boss recently implemented a new security system related to PGP/GPG.

The whole idea behind this is to sign files so that people know from who they came. They don't require us to encrypt them, just verify their authenticity.

The problem is that wrapping my head around such new and complicated concepts is getting harder and harder. We're using GPA Kleopatra.

So what I want to know:

Say I want to send a person a file, I don't know that person, it could be anybody, it doesn't have to be encrypted, and I want him to know it came from me, is there anyway for me to do that?

Again, no encryption, just authenticity verification.

You don't have to explain it to me step by step, a tutorial on some site will do. But keep it simple and straight forward.

While @schroeder's answer addresses the basic process for signature validation, there is an important step missing. The recipient needs to have a copy of your public key, received and/or validated from a trustworthy source, in order to verify your signature. Without a pre-existing trust in your public key, or in a signing authority which has validated your key, validation of the electronic signature is effectively pointless since the key could really belong to anyone.

The most common way this is handled for PGP systems, as @JayFromA pointed out in his comment is via a Web of Trust. An alternative method, typically used in enterprise environments, is Public Key Infrastructure. Both methods are essentially based on the same process though.

All clients must be configured to trust the public key(s) of one or more signing authorities.

In a Web of Trust, signing authorities can pretty much be anyone whose public key has been received and/or verified from a trustworthy source. The important part here is making sure that the keys you trust to vouch for the authenticity of other keys are themselves authentic, known to be well guarded against abuse, and belonging to users who are sufficiently diligent in verifying ownership of the keys they sign. At some point, this should involve some form of out-of-band communications such as a face-to-face meeting otherwise you've put yourself into a "turtles all the way down" trust model.
In a PKI system, one key will be assigned the role of Root Certificate Authority (Root CA) and will probably delegate its signing authority to a select few other CAs by signing their keys. Since this trust is enforced at the enterprise level (or built in to some applications, e.g. web browsers) it's generally very difficult for end-users to personally verify the trustworthiness of the public keys or signing practices of the Root CAs (and, by extension, their delegates). It is also imperative that the Root CA be extremely well guarded, and that the activity of all CAs is regularly monitored for abuse.

When a new client is added, their public key must be signed by a trusted signing authority in order to be trusted by existing clients.

In a Web of Trust system, the key may be signed by one or more users. Generally, a key's trustworthiness is increased by the number of trustworthy signatures on that key. Of course, trust can be placed in the key directly (and then you may choose to sign it yourself as well) if you have properly verified it out-of-band and you are confident in the user's ability to protect it.
In a PKI system, trust in the key is usually established by signature from a delegate CA. The Root CA should never be used, except to establish new delegates or revoke the trust of existing delegates when needed.

When any client wants to communicate with another, they must exchange public keys according to the protection intended for the communications. If the communication is to be signed, the recipient will need the sender's public key. If the communication is to be encrypted, the sender will need the recipient's public key. If it is to be both signed and encrypted, both users will need each others' public keys. An important thing to note here is that only public keys should be exchanged - nobody should ever be allowed possession or control of a private key that is not their own.

For both Web of Trust and PKI systems, this can be handled via any number of ways. Most commonly, public keys are published to a key server. However, they can also be transferred via e-mail attachment, removable storage, or any other electronic media. It's also quite possible, for some formats, to exchange keys on paper. However, transferring a key reliably from paper back into a computer system is hardly practical.

From here, steps 1-3 in @schroeder's answer apply for the signing process. After the message is composed, the sender generates an electronic signature (hash of the message, encrypted with the sender's private key) and attaches it to the message. The rest of this process is essentially handled the same regardless of whether you're using a Web of Trust or PKI.
Upon receiving the message, the first step in verifying the signature is to verify the trustworthiness of the key that should have signed it. If a key exchange (step 3 here) hasn't happened previously, the recipient must obtain the sender's public key by some means. Once they've obtained the key, they need to verify the chain of trust for that key. This essentially entails validating that the sender's key has been signed as described in step 2. If the electronic signature(s) on the sender's key cannot be traced back to one or more trusted signing authorities, then the sender's key (and therefore the received message) should not be trusted.
After the sender's public key has been verified (and perhaps, depending on the client software's configuration, regardless of it) the recipient will attempt to decrypt the electronic signature with the sender's public key. If decryption fails the message should not be trusted because this means it was signed with a key other than the one known to belong to the sender, and that the recipient will not be able to follow the next step since they don't have the proper key to use for decryption.
After the signature has been successfully decrypted, the recipient generates a hash of the message and compares it to the one provided in the signature. Though the specific algorithms used for this may differ, the process is effectively the same for both Web of Trust and PKI systems. If the hash generated by the recipient does not match the one included in the signature, that means the message has been altered in transit and should not be trusted.
Depending on the configuration, the recipient's client software will probably display the message to the user along with some indications of the results from the signature analysis. If anything went wrong with the signature verification in steps 6 or 7, or the trustworthiness of the sender's public key could not be verified in step 5, the client software will probably put up some red flags indicating that the user should not trust the origin or integrity of the message. At this point, it's up to the user to decide whether additional validation is needed before actually trusting the message themselves.

All that being said, most people receiving PGP-signed messages - and especially those without proper software to support it - probably just follow the XKCD validation method.


Why do some websites tell you they use cookies? I often visit websites that have a small box telling me that they use cookies. Most sites just store cookies and don't say anything. Is there a reason that some do and others don't?

For example:

The reason you see that message is Article 5(3) of Directive 2002/58/EC, as amended by Directive 2009/136/EC, according to which users have to give consent for the storing of information (read cookies) or retrieval of information already stored.

Some cookies are exempt from this rule, namely when the cookie

is needed for carrying your data over the network, or
required for the (requested) service to operate properly.

Or in legal jargon, when the cookie

is used for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or
strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.

  Directive 2009/136/EC, Article 5(3): Member States shall ensure
  that the storing of information, or the gaining of access to
  information already stored, in the terminal equipment of a subscriber
  or user is only allowed on condition that the subscriber or user
  concerned has given his or her consent, having been provided with
  clear and comprehensive information, in accordance with Directive
  95/46/EC, inter alia, about the purposes of the processing. This shall
  not prevent any technical storage or access for the sole purpose of
  carrying out the transmission of a communication over an electronic
  communications network, or as strictly necessary in order for the
  provider of an information society service explicitly requested by the
  subscriber or user to provide the service.

  Directive 2002/58/EC, Article 5(3):
  Member States shall ensure that the use of electronic communications
  networks to store information or to gain access to information stored
  in the terminal equipment of a subscriber or user is only allowed on
  condition that the subscriber or user concerned is provided with clear
  and comprehensive information in accordance with Directive 95/46/EC,
  inter alia about the purposes of the processing, and is offered the
  right to refuse such processing by the data controller. This shall not
  prevent any technical storage or access for the sole purpose of
  carrying out or facilitating the transmission of a communication over
  an electronic communications network, or as strictly necessary in
  order to provide an information society service explicitly requested
  by the subscriber or user.

The interested reader can also take a look at the Opinion 04/2012 on Cookie Consent Exemption document.

Note that a directive is not a law. "A 'directive' is a legislative act that sets out a goal that all EU countries must achieve. However, it is up to the individual countries to devise their own laws on how to reach these goals."


Public WiFi and Tor? I want to setup public WiFi Hotspot in very dense tourist zone where there's no single WiFi spot yet.

My worries are the security of such solution, in particular:

People logging traffic from other users
Concerns about internet line registered on me

I came up with this "solution" to enable only TLS enabled traffic (HTTPS, IMAPS, POP3S, SMTPS) and then pass it via Tor.

Do you think that there's something wrong  with this idea?

The point is to not expose users to security risks.

Do you think that there's something wrong with this idea?

Yes, quite a few points. Passing everything through TOR has the following consequences:

Much slower traffic, which on a public WiFi spot is killing
Constant security checks. Google, CloudFlare and Akamai all require CAPTCHAs. Every once in a while is OK, but on all requests can become irritating.
Blocked site that disallow TOR exit traffic.

TOR doesn't protect against people sniffing WiFi traffic at all. The TOR uplink can only be placed behind the WiFi access point. To prevent users from reaching each other you should enable AP isolation on the access point itself. Only allowing TLS/SSL/HTTPS etc.. traffic doesn't make much sense either. This limits users in what they can do without providing any additional security.


Why would the downloaded certificate show a different end-date as compared to the same certificate when viewed online? This is sort-of a follow-up to my previous question What fields in a suspicious certificate should I look at?

Chrome just presented the warning icon against the certificate presented by https://login.facebook.com (I always type the URL in) because it could not verify the CRL. For want of anything better to do, I downloaded the certificate chain and was surprised to see an expired entry against intermediary certificate in the chain.

The intermediary certificate was issued to www.verisign.com/CPS Incorp. by Ref. LIABILITY LTD.(c)97 Verisign

Validity Fields on this d/l certificate are as follows

From: 17/04/1997

To:   08/01/2004

When viewed in the browser though, this certificate shows an end-date of 25/10/2016

Hopefully it's not cause for concern, but I can't help wondering ...

Why would the downloaded certificate show a different end-date as compared to the same certificate online?

p.s. I tried downloading the certificate chain again to a different location, and still see an expiry date of 2004.

Dan Kamisky discovered and blogged about a very similar issue three months ago with Facebook.   He tracked down the issue to Facebook fielding some test load balancers based on old expired VeriSign certificates.  As always with his writings, the sleuthing is well done and presented in an excellent read.    The bottom line in his case is there was no threat.   The blog entry is a great read blog link


Who can read our customers email and try to hack our mailserver To ease tracking replies and bounces, we send automated emails such as - order confirmations, password recovery, etc with a unique sender address typically like this FROM sup-[custno]-[invno]-[hash]@sup.ourdom.tld

Now I see failed login attempts to our IMAP-server, with these addresses. Each address is tried 6 times, from IP-addresses all over the world, China, Taiwan, Africa, South America, so it is obviously a botnet.

These addresses only exist in transit and on the recipients device, how could they be picked up by hackers? Do we inform the specific customers that somebody is reading their email?

Are we even allowed to send unsolicited emails to these customers, or can that be considered mails concerning transactions we have had with them previously?

If the customer system is infected or email account is compromised then the attacker can easily get your details.

To answer your second point, I wont suggest to inform your customers about security breach. People wont trust on this part, and may lead to confusion and panic. Instead you can send email to make it look like routine security exercise in which you want people to change there password to have the communications secure.

Block those IP address at network level blacklist or hardware firewall level.
One more way is to get new email address for sending.


Securing internal REST service call via JavaScipt I have a public Single Page Application (SPA) that is calling my backend REST service via JavaScript. How can I secure the REST service so that it will only accept calls from my SPA and no other clients or users? Basically, my SPA should be the only allowed user of the service.

Any way that I can think to secure it would involving storing some kind of secret, however because the SPA is written completely in JavaScript anyone can view the source.

You can't, really. Anything sent via javascript can be tampered with. Because of this your SPA will be vulnerable to XSS and MITM attacks. An option would be using session tokens and obfuscation which is such a grotesque solution. Plus this will be an opening for CSRF attacks: CSRF. Otherwise, I recommend having your users login so that there will be some form of authentication.


Is it bad to let admins change a users e-mail when resetting passwords? I'm confused about how to implement password reset functionality. I'm testing a Web application with two roles - administrator and normal user. Only administrators can use the password reset functionality (not has MFLAC).

This function find a user and load a view with basic data, for example "TEST_USER" with e-mail "test@mail.com". The fields do not have the "readonly" attribute, so they can be modified by the administrator. When the user clicks the button "Reset" the application sends an email to "TEST_USER" with a URL (https://host.com/resetPassword.aspx?token=TOKEN).

The link loads a page with two fields, "new password" and "verify new password". Here I successfully changed the password and completed the process.

If an attacker changes the value in the field "e-mail" and enters "attacker@mail.com" then the application will send the link to the attacker, thereby letting the attacker change the password. It is important to mention that this function is susceptible to CSRF because it does not have a token.

So I think that this is a vulnerability because an attacker or administrator can change the e-mail and reset the password for any user without them knowing about it. Using CSRF an attacker can send a malicious URL that resets the password to an administrator.

So I think that this is not a correct way to implement this functionality because I have heard that a good practice is sending only a token to the email address.

I think that the correct way to do this would be:

Assure that the e-mail address belongs to the user whose password is being reset.
You should send only one token instead of an URL.
In the page ResetPassword.aspx paste the token.
Verify the user with security questions.
Let the user fill in "new password" and "verify new password"

Is this a vulnerability? Is this the correct way to implement this functionality?

Yes, this is definitely a vulnerability. Two actually:

The missing CSRF protection for a sensitive action
Not requiring a password when changing an email address

The first is obvious, and you have already explained why it is bad. The second is bad because it is essentially the same as not requiring a password when changing a password (which is bad), and it obviously lets an admin take over accounts. Combining these two issues, an unauthenticated attacker could take over arbitrary accounts.

Whether the second issue is something that needs to be addressed depends on the application. It might be desired that an administrator has far-reaching permissions, including taking over other users accounts. If this isn't desired, an admin shouldn't have the option to change email addresses, only users themselves should be able to do this.


Known flaws in Signal app's security Are there any known exploits in Signal's encryption protocol that could lead to messages being decrypted, or any other compromising information being released?

No, there are no known public flaw in Signal at the time of writing of this answer.
Source: there was only one CVE for Signal (for Android), in 2018. The only one listed (fixed in version 4.25.0 the 14 Aug 2018) could leak photos attached to disappearing messages.


Is CSRF possible if I don't even use cookies? I have REST api that is using access token which is sent either in header or as url query. I don't use cookies at all.

Am I still vulnerable to CSRF attacks? I know that I would if I would use cookies since other tab can send request and cookies will be sent as well but in my case Headers/UrlParam won't be sent at all.

No you are not vulnerable in that scenario.

The reason is exactly as you explain - a third-party site could generate a request to your site, but the authentication details will not be attached.


Get Device names of surrounding WIFI devices without authentication I am looking to get a list of devices which are in range of my Wifi antenne (monitor mode).

For example: "Tom's Iphone"

I can get the MAC's of these devices, but is it possible to get the name of these devices without them actually connect to my Wifi Antenne?

Or is this something that is not technically possible?

No  this is not possible. Generally the names you’re talking about come from NETBIOS, bonjour, UPnP, or some other broadcast protocol. These, however, only broadcast within their own networks so unless the device connects and then you capture a beacon you’re out of luck. You could potentially build something that was an SSID of ‘attwifi’ which deauths clients after they broadcast their name if you really wanted to collect device names.


Encryption and Compression I've read that encryption produces random data and compression works by removing patterns in data and as a consequence, encrypted data has high entropy. I'm a bit confused, though.

The reason I'm confused is that I thought that all encryption was supposed to do is make it as difficult as brute forcing the key to go from the cipher text to the plain text. It seems to me like there could be an AES key that would produce an all 0 ciphertext given a certain plaintext.

So, long as you couldn't use the all 0 ciphertext to figure out the plain text without brute forcing the key, it wouldn't break any of the goals of encryption.

Is it really that encryption is supposed to produce uncorrelated data to the plaintext, as though every bit was random, and this just happens on large plaintexts, for the most part, to produce high entropy ciphertexts?

There's no contradiction here as long as you consider the issue in probabilistic terms.  For example:

  The reason I'm confused is that I thought that all encryption was supposed to do is make it as difficult as brute forcing the key to go from the cipher text to the plain text. It seems to me like there could be an AES key that would produce an all 0 ciphertext given a certain plaintext.

Yes, it's certainly possible that some combination of key and plaintext might produce all-zero ciphertext.  But since keys are meant to be selected at random, if such a combination even exists the chance that it would occur in practice is just astronomically unlikely.

One of the key security notions for ciphers is indistinguishability under chosen-plaintext attack ("IND-CPA"), which says (roughly) that an adversary cannot efficiently tell ciphertexts apart from uniform random bits, even if they choose the plaintexts to be encrypted.  More precisely, any algorithm that succeeds at distinguishing the cipher must be prohibitively expensive (e.g., brute-forcing a 128-bit key).

This means that we can draw good conclusions about the compressibility of ciphertexts just by reasoning about the compressibility of uniform random bit strings.  And it comes down to this: for a fixed compression algorithm, if you pick an n-bit string at random, the chance that the algorithm will compress the string you picked to a length of m bits (m < n) goes down exponentially with m.  If you could write an efficient (non-brute force) algorithm that achieved better success than this at compressing ciphertexts, then the cipher's security would be suspect.


Is it possible to decrypt half of a TrueCrypt file container if the other half of the data is missing? Let's say we have half of a TrueCrypt file container (e.g. download was interrupted). If we know the password, is it possible to open it and get half of the data? The original container has 10 files, so is it possible (in theory) to get 5 files?

That is, I would like to understand how the encrypted data is stored in the file container. Whether the data is stored consistently(file-by-file) or all the data is mixed (with any editing/adding/deleting of internal files)?

Addition. But what if we have only the second part of the file?(I mean we don't have first 128 KiB of file) Am I right that we can not get anything out of this (it will be absolutely useless data)

Sort of. You can decrypt it as long as you have more than 128 KiB of data downloaded, as that is the end of the header and backup header and where the actual filesystem starts. However, even if you successfully decrypt it, remember that the filesystem will be cut in half too, meaning it will be massively corrupted. Depending on the filesystem, you may be able to recover all the files if they were stored at the beginning of the filesystem (I believe FAT does this), or very few, if they were spread out evenly (like in XFS). Now, the volume won't mount due to the corruption, of course, so you'll have to use recovery tools. But as long as you have the header, and the password, your question becomes "Is it possible to recover half of the files on a filesystem if the other half is missing?".

https://andryou.com/truecrypt_orig/docs/volume-format-specification/


Is there a length beyond which increasing password length provides no additional security? Assuming that the password is stored hashed and salted, and that it is a string of random characters, is there a point where adding to password length doesn't add security?

Since the hash will have a constant length, there are a finite number of possible hashes. So I would assume that at some very long length, the probability that a password's hash collides with the hash of a shorter password starts to climb, until we get to a length where all passwords have collisions with shorter passwords.

The strength of a password is a measure of what it could have been. That's how passwords work: they are something which a given user remembers, but is unknown to outsiders. How much unknown ? That's the tricky point.

If you consider a password consisting of 7 random letters (uppercase and lowercase) and digits, where each sign is chosen randomly, uniformly, and independently of each other, then there are 627 = 3521614606208 possible passwords and they all have the same probability of being chosen; so, for attackers, the best possible strategy is to try them all (no order is better than any other) until a match is found. On average, attackers will try half the space of possible password (hence 1760807303104, in this case) before hitting the right one.

So the strength of a password does not come from what it is, and in particular does not come from its length. The password length has no direct relation to password security. What makes a password strong is its randomness; and that's, strictly speaking, a property of the password generation method, not of the password itself. The indirect relation of length with security is that you need some room to exercise randomness: while a very long password is not necessarily secure, a very short password is necessarily insecure.

Moreover, if you create your password by accumulating randomly chosen elements (random letters, random words...) then randomness is increased by accumulating more of them, as long as they are chosen independently of each other (you don't get more randomness if you repeat four times the same word). In that sense, you may have the impression that length makes strength; but that's an illusion. Randomness makes strength -- and just happens to need space.

How much randomness do you need ? Enough to deter attackers. How many passwords an attacker can try per second depends a lot of the context. If the password is the PIN code for a smart card, then the attacker can try 3 codes, and no more (after 3 wrong PIN, the card locks itself permanently). If the attacker must talk to a Web server for each password try, then he will be able to try as many passwords per second as the server is willing to accept, based on the server CPU power and configuration. If the attacker knows a hash of the password, then he can try as many as he can based on his budget (for a simple hash function, this can range in the billions per second).

For each context, there is a limit to the number of passwords the attacker may try. If his chances of hitting the right password within his budget are too low, the attacker will deem it "not worth the effort", and then you win. You do not need to get more randomness than this point.

Since hash functions have a finite length, there is also another limit beyond which it is useless to increase password randomness, but it is much farther. It is not about collisions, but about preimages. Let's put figures under it. A realistic attacker, with a lot of budget, and faced with a simple hash function, may try up to about 270 potential passwords. We are talking about a budget of some millions of dollars here, and also a rather patient attacker (he will accept to spend a few weeks on that password). There are good reasons why this figure won't raise indefinitely with technological advances. Let's consider that the hash function has an output of n bits (e.g. n = 128 for MD5). The attacker's goal is to find a password which, when hashed, yields a given hash value; he does not need the password which was initially used, just a matching password. He has two attacking strategies:

He can try "potential passwords" that the human user may have come up with.
He can try random passwords until a match is found.

Strategy 1 will have cost P/2 where P is (more or less) the number of potential passwords that the user may have chosen. If P is beyond 271 then that's too expensive for the attacker.

Strategy 2 will have cost 2n-1. If n is greater than 71 then that's too expensive for the attacker.

Even the oldest, most basic hash functions like MD5 have an output size which is more than enough to make strategy 2 unworkable (MD2, MD4, MD5 have output size 128 bits; SHA-1 and RIPEMD-160 offer 160 bits; SHA-256 has 256 bits). In other words, the fixed hash output size could limit security only if it was below 70 bits or so.

For more on the subject of password randomness (often called "entropy"), see this answer. For more on correct ways to do password hashing (in particular, to do slow hashing, with salts to prevent parallel attacks), see that answer.


When to use SSL ? / When to send passwords via mail? Self-Proclaimed Experts are quick to say that for every time a password is being transmitted from a webserver to a user and vv, you need to use SSL. Because there will be people each time trying to get your password who are always in between you and the server you request data from. If you are in a crochet forum, there will be millions of euros being spent to get your password, even if you are a 90 years old granny with no money.

Same with sending passwords via email.

Given the fact that SSL certificates are costly, how should those two security issues be judged:

When is it necessary to have SSL?

Should you never send passwords using mail?

As a rule, if you run a website that requires authentication, you should run SSL.   And I'd debate your statement that SSL certificates are costly...I've just purchased one for a personal website of mine for less than 15 euros for two years.  It's cheaper than the domain name is, in fact.

You shouldn't send passwords via email either.   It's slightly more secure to email password reset links instead.

The real issue is not that someone might get Granny's forum password, but that Granny is statistically likely to have used that same password for her banking website.  And we can't have that stolen.


Will "Authorization: Bearer" in request header fix CSRF attacks? I have been reading on fixing CSRF attacks. From some research I understand that checking for a non-standard header would prevent CSRF attacks since the browser will not automatically send such headers.

So I was assuming to recommend using Authorization: Bearer tokens for the ASP application I am currently testing. Since this this header value won't be sent by the browser itself, I am assuming this approach would fix CSRF issue. But then I came to notice a stack overflow question which confused me a little. The answer still recommends to use the CSRF tokens.

So, basically I have two questions.

Would this approach actually work to prevent CSRF attacks?
I know If I am vulnerable to XSS attacks my cookies can be read and the bearer tokens can be stolen. But can the injected XSS create a the Authorization: Bearer header and append the stolen value from cookie?

Would this approach actually work to prevent CSRF attacks?

Yes. An attacker can't  make a browser send a request that include the authorization header with the correct bearer token. This is for two reasons:

The attacker can't set the authroization header.
The attacker don't know the correct value of the token, so they wouldn't know what to set it to.

However, this might be sensitive to changes in your application. For instance, if someone one day decides to change the authentication system to something cookie based, they may not realize that they are disabling your CSRF protection by doing that.

Also, in the case where the required header value is predictable, a CORS policy that allows that header to be set could spell trouble.

As for the linked SO question, I am not sure I understand the accepted answer. But if you look at the second answer, your situation is of type #2 and not type #1.

  I know If I am vulnerable to XSS attacks my cookies can be read and the bearer tokens can be stolen. But can the injected XSS create a the Authorization: Bearer header and append the stolen value from cookie?

Yup, you could do that if you can inject code.

If you have an XSS vulnerability, it will allow the attacker to bypass any CSRF protection you put in place. So concerns for XSS can't really be used to favor one form of CSRF protection over another - in the face of XSS they are all void.

A slight difference here is that your token cannot be marked as HTTP-only, since you need to access it from JS to put it in the header. Consequently, an XSS attacker can steal it and then conveniently send requests from her own computer. If the authentication token is HTTP-only the attacker has to make the injected code send the requests, which is a bit of a hassle but not impossible.


What are the security dangers of using Security Groups instead of NAT Gateways for isolating AWS RDS databases from public access? As I have learned, there are two main ways of isolating resources in AWS VPC

One through public/private subnet separation using NAT Gateways to route communications between resources (e.g. public web servers) in the public subnets and resources in the private subnets (e.g. Aurora RDS instances)

On the other hand, one could just have public subnets and all resources that should not be reachable from internet should not have public IPs and be inside Security Groups, which should only allow other resources in the public subnets to stablish connections with them

As I understand, both approaches attain the goal of impeding Internet connecting with private resources, but while NAT Gateways are quite expensive, Security Groups are available for free
So my question is, what are the security pros and cons between both approaches? Given that NAT Gateways seem to be much more popular for this purpose and Security Groups much simpler and cheaper, I would expect the former to have some kind of stronger security warranty
Until now the only "advantage" I have heard of is the possibility of forgetting the proper use of Security Groups, which I believe should not happen if one applies programming best practices to deploying infrastructure as code (e.g. Terraform, Cloudformation)

One through public/private subnet separation using NAT Gateways to
route communications between resources (e.g. public web servers) in
the public subnets and resources in the private subnets (e.g. Aurora
RDS instances)

^^^This approach is recommended by AWS, as it minimizes the attack surface by keeping the DB instances in a dedicated subnet and additionally host level access is controlled using Security Groups.

one could just have public subnets and all resources that should not
be reachable from internet should not have public IPs and be inside
Security Groups, which should only allow other resources in the public
subnets to stablish connections with them

^^^This approach does not enable the same behavior as the public/Private subnet design.
For instances present in a public subnet, you may use security groups to control host level access. However, a public subnet is "public" due to the presence of an Internet Gateway and an appropriate route entry in the subnet's route table. For instances in a public subnet to connect to Internet, a public IP must be assigned to them.
In your case, not assigning a public IP to a Database Instance in a public subnet would make it inaccessible over the Internet but it would also mean that the instance would not be able to access the Internet. A NAT Gateway/Instance solves this problem by allowing instances in the private subnet to access the Internet, without needing a public IP address.