Are we anonymous when not connected to internet on windows?

It really depends on a lot of factors. Generally, you should not worry, but this doesn't protect you against malware that saves what you're doing offline, and then uploads the data after you reconnect to the internet.

  When we don't use internet on windows, can windows or any Laptop vendor can access our Laptop (similar as connected to internet ). If yes, then How ?

This depends. If you want to know if someone can access your windows installation, then yes, it's quite possible. And you don't even need to be using Windows. If you think a laptop vendor is going to access your computer, then I don't think that's legal - and most of them don't have this capability anyway.

However, there exists anti-theft features on some hardware which, when activated, can help allow a vendor to find where the computer is being used in the world.

If you mean, "is it possible for malicious software and devices to allow access to an air-gapped computer?", then also yes, that is possible as well. There are many methods which aid in doing so, but I'll list a couple and try to keep it short:

The Ultrasonic Malware Method

Let's say there's a trojan on your computer which sends data over the speakers, and receives it over the microphone, and you can't hear that because it's on the ultrasonic level. Yes, it's possible. It's very possible, in fact.

The Implant Method

If you're being targeted by a nation-state actor, there are cables which can help assist in spying on you. You can read more, and find example pictures in the leaked NSA ANT catalog. Notable examples include:

A monitor cable that, when installed, allows what's happening on your monitor to be recorded.
A hardware keylogger that monitors your keyboard's input.
Implants that modify the USB connector which provide air-gap bridging support.

Some of this malware seems to be obtained through supply-chain interdiction, wherein the NSA intercepts your shipments from retailers such as Amazon, Best Buy, et al., and replaces them with hacked variants.

However, air-gap bridging malware can be installed through software exploits as well.

Of course, this is not limited to the NSA. There are very likely other countries whose intelligence agencies use the same tactics and technologies.

Further reading

If you'd like to learn more, Bruce Schneier has a good article on avoiding malware that jumps airgaps. However:

His cloud-based anti-virus upload idea will not work against malware that hasn't been detected in the wild. Nation-state malware can usually get around this very easily. It's actually relatively easy to bypass anti-virus programs.
His idea for using Tails is not that great. If there's a vulnerability in the tails OS, you have access to that session while it runs in memory. Qubes would be a better idea.
He thinks disabling speakers and microphones is, "too paranoid for him." At the time he wrote this, I don't think he was aware of malware that exclusively uses microphones and speakers.


How do you evaluate and audit Central Authentication Service (CAS)?

I have not seen a compliance guide for evaluating the security posture of CAS, but I have some urls that might be useful.

Securing Your New CAS Server
https://wiki.jasig.org/display/CASUM/Securing+Your+New+CAS+Server

Auditing and Statistics Via Inspektr
https://wiki.jasig.org/display/CASUM/Auditing+and+Statistics+Via+Inspektr

Enabling auditing will generate logs, but you might want to look at something to ingest logs and provide some analysis (like Splunk).

I hope this gives you a place to start.


First, may I ask why you think the app is not as secure as the website?  Generally speaking, from a security perspective, one of the worse things you can possibly do is to involve PHP, which has more security pitfalls then, well, probably all of the other common technologies combined.

Additionally:

if you're any sensitive traffic from the app to the website, it needs to be over HTTPS.
Do not submit passwords as querystring parameters.  This practically ensures that they'll be logged in plaintext, even if transported over HTTPS.  Then need to be POSTed as form values instead.
Hashing the token doesn't do much for you.  If you're submitting it over HTTPS, a MitM can't get it.  If you aren't, an attacker can generate an MD5 just as easily as you can.
Saving the used tokens is a good idea, from an anti-replay perspective.  You don't really need to save the ancillary information..It'll take up storage and probably won't give you much in the way of useful data.
However, saving the tokens can be a problem if you aren't using HTTPS, because an attacker who knows your scheme (and you should assume that an attacker will know your scheme) can pre-calculate the next token and hijack the session going forward, not only impersonating the real application, but also DoS'ing the real application out, because when it sends the next tokens, they'll already be in the used tokens table.

There are likely other issues here, but these are the first few that I've seen.

The bottom line is that I think this scheme needs a re-think, and a trip back to the drawing board.


Gmail spam from contacts. How does it work?

I have helped people who have experienced exactly the same thing that you are describing and it was simply the result of an infection. A program connects to her gmail account, and searches for emails in her contacts and folders, including the deleted items folder. Then, spam is sent out.

I know that you have scanned her machine, but scans do not always catch the very new variants of malware. In the last case I worked on, I was able to trace the infection to a file the person opened that was also sent to her by one of her contacts.


Setting up home lab with Snort and Vyatta - looking for resource recommendations or advice

If you set the network type to your virtual machines to Internal Network with the same internal network name (an arbitrary string of your choosing, but the same for all machines), and then configure (in the Advanced settings) the promiscuous mode to Allow All, then the VM will be all hooked to a virtual hub which is like a switch which mirrors everything everywhere. See the screenshot below:

These settings can be applied on a started VM but will take effect only when the VM is next shut down and restarted.

With a virtual hub, every packet sent by any VM will be visible to all machines, which should be enough for what you want to achieve (if I understand your situation correctly).

For mor details, see the Virtual networking chapter of the VirtualBox manual.


Can someone explain, in simple terms, how the FREAK attack on browsers works?

In simple terms:

Your browser starts to connect to an HTTPS website, asking to use a strong cipher.
The attacker intercepts this request and replaces it with one asking to use weak "export-grade" encryption.
The server gets this modified request and responds to your browser with an export-grade encryption key.
Your browser doesn't notice the key it got is weaker than the one it asked for, and finishes setting up the SSL session using this weak key.
The attacker can now record your session and break the encryption on it in a matter of minutes to hours, or if the server re-uses keys (most of them do), use a previous break to read (and potentially modify) your traffic as it goes by.

Note that the "FREAK" attack requires three things in order to work:

A server that still supports export-grade encryption.  Less than a quarter of them do.
A browser with a buggy SSL library that doesn't notice that what it asks for isn't what it got.
An attacker sitting between a vulnerable browser and a server with an out-of-date configuration.

As far as I can tell, the "FREAK" vulnerability affects the SChannel library (Internet Explorer and related Windows browsers), Apple's SSL library (Safari and other MacOSX/IOS browsers), and OpenSSL (most Android browsers and a scattering of Linux browsers).  The NSS library (Firefox and Chrome) does not appear to be affected.


No, there is no need to ever encrypt loopback traffic with SSL. Loopback traffic never leaves the machine, since the interface is virtual. The traffic never even reaches a real NIC's device driver.

In order to capture the loopback traffic, an attacker would need to execute a capture program on your machine. Once an attacker has code execution on your machine, you are owned. Game over.

Encrypting the traffic is pointless when they can just read the source data, or read the plaintext buffers from memory.


Here's a possible website you can use to find out more: http://www.openculture.com/2013/01/the_enigma_machine_how_alan_turing_helped_break_the_unbreakable_nazi_code_.html

A Summary:

Legitimate Method: The Nazis released a monthly code sheet with the appropriate settings for each day of that month. Once you knew the settings, you could type in the nonsense into an Enigma set that way and get the original message.

Cracking the Enigma: We knew that no letter in the Enigma ever encrypted to itself (ie, typing in "a" never yields "a"). We also knew how the Nazis sent messages (ie, their weather reports at 6 AM always had the format "The weather today is __ and _."). So we took their messages and, knowing that they had to contain certain words in certain (rough) locations, we matched them up with a limited number of slots that worked (because no letters in those slots were in a corresponding place in the word). From there, we were able to reverse engineer one of the settings by a clever brute-force attack. After that one setting, which produced by far the greatest variety, was broken, it was a simple matter to get the positions of the rotors (there were only a few thousand). The code was re-broken every day by a computer, which took about 20 minutes.


Can you do an overflow to the heap space from a stack?

A stack buffer overflow usually overwrites previous stack frames or the return address.  The stack grows down and buffers within the stack "grow" (they don't) up.

On most systems, the stack grows down and is above the heap.

A stack overflow can't overwrite anything on the heap because the heap comes before the stack.   An underflow however would force the stack to overflow, causing the program to crash before anything gets overwritten.

If pointers are unsigned integer, incrementing a pointer far enough could make it point to the heap.  But since buffer overflows usually write to all the addresses in the overflowing buffer, the program will crash when it has gone beyond the beginning of the stack.  And even if the stack begins at the highest address, there will be a NULL pointer dereference, attempts to write to text and attempts to write to read only data sections, before the heap comes.

On rare systems where the stack grows up and towards the heap, a stack buffer overflow could overwrite data on the heap, assuming the system does not create a no-man's-land between the stack and the heap.

Some systems automatically allocate memory to the stack as it grows, other have a pre-allocated area for the stack.  Auto-growing stacks are limited by either policy, and/or on 64-bit systems: available memory and swap.

A normal buffer overflow on these systems won't hurt the heap because it hits the no-man's-land before the heap.


C library functions in statically linked ELF32 binary no longer use int 0x80

int $0x80 is indeed executed by some of the C library functions in the statically linked binary, but not by nearly as many library functions as one would expect given how many library functions are included in the binary:

$ objdump -dj .text binary | grep "cd 80"
 8049401:   cd 80                   int    $0x80
 806c465:   cd 80                   int    $0x80
 806ea5e:   cd 80                   int    $0x80
 806f040:   cd 80                   int    $0x80
 807b5c5:   cd 80                   int    $0x80
 807b5ce:   cd 80                   int    $0x80
 8092651:   cd 80                   int    $0x80
 8094092:   cd 80                   int    $0x80

Let us examine a few of the library functions to see what is going on:

_exit

$ objdump -dj .text binary | grep -A10 "<_exit>:"
0806c451 <_exit>:
 806c451:   8b 5c 24 04             mov    0x4(%esp),%ebx
 806c455:   b8 fc 00 00 00          mov    $0xfc,%eax
 806c45a:   ff 15 f0 a9 0e 08       call   *0x80ea9f0
 806c460:   b8 01 00 00 00          mov    $0x1,%eax
 806c465:   cd 80                   int    $0x80            <---
 806c467:   f4                      hlt
 806c468:   66 90                   xchg   %ax,%ax
 806c46a:   66 90                   xchg   %ax,%ax
 806c46c:   66 90                   xchg   %ax,%ax
 806c46e:   66 90                   xchg   %ax,%ax

No issues here. Note that exit is different than _exit.

__execve:

$ objdump -dj .text binary | grep -A10 "<__execve>:"
0806c470 <__execve>:
 806c470:   53                      push   %ebx
 806c471:   8b 54 24 10             mov    0x10(%esp),%edx
 806c475:   8b 4c 24 0c             mov    0xc(%esp),%ecx
 806c479:   8b 5c 24 08             mov    0x8(%esp),%ebx
 806c47d:   b8 0b 00 00 00          mov    $0xb,%eax     <-- 11 in eax == sys_execve
 806c482:   ff 15 f0 a9 0e 08       call   *0x80ea9f0
 806c488:   3d 00 f0 ff ff          cmp    $0xfffff000,%eax
 806c48d:   77 02                   ja     806c491 <__execve+0x21>
 806c48f:   5b                      pop    %ebx
 806c490:   c3                      ret

__libc_open and __open_nocancel:

0806cdb0 <__libc_open>:
 806cdb0:   65 83 3d 0c 00 00 00    cmpl   $0x0,%gs:0xc
 806cdb7:   00
 806cdb8:   75 25                   jne    806cddf <__open_nocancel+0x25>

0806cdba <__open_nocancel>:
 806cdba:   53                      push   %ebx
 806cdbb:   8b 54 24 10             mov    0x10(%esp),%edx
 806cdbf:   8b 4c 24 0c             mov    0xc(%esp),%ecx
 806cdc3:   8b 5c 24 08             mov    0x8(%esp),%ebx
 806cdc7:   b8 05 00 00 00          mov    $0x5,%eax      <-- 5 in eax == sys_open
 806cdcc:   ff 15 f0 a9 0e 08       call   *0x80ea9f0
 806cdd2:   5b                      pop    %ebx
 806cdd3:   3d 01 f0 ff ff          cmp    $0xfffff001,%eax
 806cdd8:   0f 83 82 32 00 00       jae    8070060 <__syscall_error>
 806cdde:   c3                      ret
 806cddf:   e8 cc 1b 00 00          call   806e9b0 <__libc_enable_asynccancel>
 806cde4:   50                      push   %eax
 806cde5:   53                      push   %ebx
 806cde6:   8b 54 24 14             mov    0x14(%esp),%edx
 806cdea:   8b 4c 24 10             mov    0x10(%esp),%ecx
 806cdee:   8b 5c 24 0c             mov    0xc(%esp),%ebx
 806cdf2:   b8 05 00 00 00          mov    $0x5,%eax      <-- 5 in eax == sys_open
 806cdf7:   ff 15 f0 a9 0e 08       call   *0x80ea9f0

It looks like many of these library functions are making system calls through an intermediary beginning at the address in location 0x80ea9f0 which is in the .data section.

$ readelf -SW binary

[23] .got.plt          PROGBITS        080ea000 0a1000 000044 04  WA  0   0  4
[24] .data             PROGBITS        080ea060 0a1060 000f20 00  WA  0   0 32
[25] .bss              NOBITS          080eaf80 0a1f80 00136c 00  WA  0   0 32
[26] __libc_freeres_ptrs NOBITS        080ec2ec 0a1f80 000018 00  WA  0   0  4
[27] .comment          PROGBITS        00000000 0a1f80 00002b 01  MS  0   0  1
[28] .shstrtab         STRTAB          00000000 0a1fab 00014c 00      0   0  1

Let's take a look inside the .data section:

readelf -x .data binary | less:

0x080ea9d0 00000000 00000000 00000000 00000000 ................
0x080ea9e0 00000000 01000000 00000000 00000000 ................
0x080ea9f0 40f00608 b0ad0908 07000000 7f030000 @...............
0x080eaa00 03000000 02000000 00100000 107a0908 .............z..

Remembering that x86 is little-endian, we read 40f00608 as 0806f040.

Good news: 0x0806f040 is in the .text section of the binary:

[ 3] .rel.plt          REL             08048138 000138 000070 08   A  0   5  4
[ 4] .init             PROGBITS        080481a8 0001a8 000023 00  AX  0   0  4
[ 5] .plt              PROGBITS        080481d0 0001d0 0000e0 00  AX  0   0 16
[ 6] .text             PROGBITS        080482b0 0002b0 075b64 00  AX  0   0 16
[ 7] __libc_freeres_fn PROGBITS        080bde20 075e20 000b36 00  AX  0   0 16

Let's take a peek at the code at that address:

$ objdump -dj .text binary | grep -A5 0806f040
0806f040 <_dl_sysinfo_int80>:
 806f040:   cd 80                   int    $0x80      <--- !!!!!!!!!
 806f042:   c3                      ret
 806f043:   8d b6 00 00 00 00       lea    0x0(%esi),%esi
 806f049:   8d bc 27 00 00 00 00    lea    0x0(%edi,%eiz,1),%edi

The memory address 0x0806f040 contains the first instruction of function   _dl_sysinfo_int80, which is the int instruction followed by the interrupt vector 128.

In conclusion, every library function that calls *0x80ea9f0 is making a system call via function _dl_sysinfo_int80. No dynamic analysis necesary.


Is it Feasible to Block Connections That Windows 10 Uses to Push/Pull? - ie: Phone Home, Watchers, Monitors, Onedrive, Cortana, Bing, Shadyness, Etc?

Since I think this is a battle you can't win, I've resorted to simply not having Internet available by default for my Windows 10 box.  Instead, to get access to the internet, you have to go through a firewall with a proxy setup.

If an Application needs internet access, I configure its proxy server settings (but NOT the native Windows proxy).  This covers 99% of my needs, as Firefox, Chrome (with plugin) and Thunderbird all have these settings available.

For the other 1% of my Internet needs, I configure the firewall to allow certain IP ranges only (for a few games I play).

This also convienently blocks almost anything that normally annoys me (applications that are not supposed to use the Internet, incessant checking for updates, giving me news, etc..)

Sure, the Tiles etc won't work -- I don't care.

Runs like this for 3 months now, I'm happy.


None of these technologies will protect you from (D)DoS attacks. They will only (try to) prevent bots from accessing (a certain part of) your application. A (D)DoS attack could make the page of your Captcha unavailable, and you would have the same problem.

(D)DoS attacks can, for example, be prevented by adding advanced firewall rules, or by using paid services (e.g. Cloudflare). I suggest you search the web on how to protect yourself against (D)DoS attacks.


How can I detect if IETF TokenBinding is in use for bearer tokens?

When a server supporting the Token Binding protocol receives a bound
     token, the server compares the TLS Token Binding ID in the security token with the TLS Token Binding ID established with the client.  If
     the bound token came from a TLS connection without a Token Binding,
     or if the IDs don't match, the token is discarded.

(draft)

The problem is that I don't believe any client is implementing token binding which follows the draft. So you should create a test client yourself and then clear or change the private key and the bearer token should be dropped.

I wouldn't know why a client would want to have this tested on its servers. Are there any clients (software clients) who support token binding? It seems like .net is one of the first pieces of software to support the protocol. Also, the protocol is still a draft so it will take some time until we see adoption.


Form input fields of type password don't show the contents, or allow copying. My assumption is so that someone else cannot press 'back' after your logout and read the copy the content out on a shared computer.


Theoretical home grown password options, or what is it that SCrypt, BCrypt, PBKDF2 does that is so special?

Well, it is a mixture of "no peer review" and "something you do bad". The thing you are (apparently) doing poorly is your salt selection: you call it "randomdatabasesalt", which hints at the idea that you would use the same salt value for several hashes, if you had to store several password hashes (e.g. because your framework has several users). This is a sin: it voids most of the reason why you would use a salt in the first place. Salts should be per-instance: each user should have his own salt, and the salt must be changed when the user changes his password.

As for the rest: anybody can create a cryptographic scheme that he cannot break. The hard part is to create a scheme that nobody else can break it either. The really hard part is to make sure that nobody else can break it (because we want security, but we also want to sleep at night).

Cryptographers thus rely on peer review and slow-paced development. When they want to design a new function, they organize a competition in which people are encouraged to submit candidates, complete with specification, test vectors and reference implementations; and then they spend some time (years) to try to break each other's creations. Survivors are then deemed "probably secure". This is what was done for AES and SHA-3, for instance. And, right on cue, there is an ongoing competition for password hashing functions.

This presentation is a nice introduction on password hashing, and lists some features that good password hashing functions should have. Have also a look at that answer.

(One way of designing cryptosystems which does NOT work is a fast comment-modify cycle. It usually happens as a dialogue between a wannabe designer, and an amicable and knowledgeable cryptographer. The designer, full of zeal, will submit an endless stream of minor variants of his scheme, each adding some random construct to answer to the last comment from the cryptographer. This always ends up with the cryptographer being fed up and ceasing to respond; the designer then claims victory and writes a colourful Web page, and then fails to become rich overnight when the rest of the World does not acknowledge the genius of the new algorithm.)


Attacking admin and non-admin User accounts on the same PC

Whenever you detect that an attacker's code has been executed, it is best to act with the assumption that all data on the system is potentially compromised. This is especially true if a privileged user was compromised, as even if they require affirmative action to don their privileges (sudo, etc), they will at some point do so. At that moment the attack code can fully compromise the system.

Even if the infected user has no privileges, a number of local vulnerabilities may exist (unknown to the administrator) that could grant the code increased privileges without any privileged user ever logging in.

It is a problem of 'unknown unknowns', and with local access the attack surface is simply much larger.

It's worth considering that local network communications can be generated, sniffed, and spoofed by the attack code so you can't merely assume that information and accounts on other machines are secure.


Is there any CBC based ciphersuite which are secure for known attacks like LUCKY13?

No, all TLS CBC cipher suites have the same problems: most old implementations and a minority of currently deployed implementations (some unpatchable, some where the vendor could not be contacted by researchers, etc.) have a variant of lucky13 or poodle (both have many named variants).

The Mozilla list is likely from before the discovery of the new variants of poodle which finally caused SSL Labs tester to mark all CBC cipher suites "weak".

It is possible to implement CBC cipher suites correctly, but it is too hard. If the effort is made to implement them correctly, it would be better to spend the effort at supporting GCM or CCM or ChaCha20-Poly1305.

If the other side can support AEAD, you should use AEAD. If the other side can't support AEAD, you have to be very suspicious and test its CBC thoroughly. TLS is supposed to be secure without first testing the other side, so if you can drop CBC support you should do that. This means you drop support for TLS versions below 1.2.

Of course, for business reasons, many will choose to support CBC cipher suites for a long time. When can a business drop support? When no such clients exist in practice. When will users stop using clients (or proxies) that can only do CBC? When such clients can't connect to important servers (e.g. google, facebook). This will take a long time.

Chrome might show UI for "insecure" for sites that require CBC cipher suites next year, but dropping them completely - I guess not. Google's servers can't show UI for insecure - they either allow connections or not, so I think they will allow connections with CBC cipher suites for a long time (though they have published they want people to upgrade to AEAD and only promise to support ECDHE with AEAD).


Why does the server ssh public key not look like the key in client known hosts?

For privacy.
With modern versions of OpenSSH, the known_hosts file on the client contains a hash of the server name (or IP address), rather than the name directly. The reason for only storing a hash is that if someone obtains a copy of this file (e.g. leaked backup), they can't discover which servers are recorded, i.e. they can't discover which sites you connected to. They can verify guesses, of course: that's unavoidable since the legitimate client must be able to do this.
The ssh-keygen utility has a few options to manipulate the known_hosts entries, but of course can't convert a hash to the non-hash format. You can set HashKnownHosts no in your client configuration (~/.ssh/config) to turn off hashing, then the entries will be in a format where the public key is clearly visible.


Can application connect to database without exposing password to anyone?

It depends on your database. Trying to protect a resource where the resource is physically compromised by a bad actor is a hard problem because the bad actor has access to all resources: disk, network and memory. I'd be tempted to threat model the application and consider how you can mitigate the bad admin.  If you don't trust the admin then there you do have a problem, but it might be that you can store credentials in an external source such as a Hardware Security Module.  There is a whole industry around privileged account management where companies such as Cyberark claim that they can control access to your database.  These products typically record privileged account access: they won't stop an authorised person going on a frolic of their own.

For the specific question of how to prevent someone with full access to the environment from reading a specific file: it's not possible.  You could try to set access permissions ownership etc but you can't stop someone who has the access from getting to it.  Putting the data into an HSM to which the actor does not have access will mitigate but you need to ensure that your database can talk to the HSM.

To really prevent someone who has legitimate root/admin to the system I think you will need to split up the systems to implement segregation of duties, then change your database authentication model: one admin looks after the user credentials store while the other admin looks after the database.

You could require every individual user to have their own login to the database.  The web app then performs the login, assuming the admin can't hook into the web app (which they can). Perhaps not scalable, but possible.

For MS SQL you can use Windows authentication mode. doc This uses the windows authentication to the domain via kerberos.  Your admin won't be able to get the credentials.  You could of course have a service account and put that service account in a domain that your DBA does not have access to

For MySQL you can use LDAP via the pluggable authentication link

For Oracle take a look at Oracle Key Manager link


Reversing encryption by analysing executable

Reverse Engineering a Windows Binary
Get a Disassembler
I'd start by downloading the evaluation version of IDA. Because it is the evaluation version it has a pop up and won't let you save, but it should be good enough to get started. Note: This won't work for a 64-bit binary. Go check out this page for alternative disassemblers if necessary.
Inspect the Strings
Before you dig into the actual code, start by inspecting the strings. IDA has a tab (or an option in the "views" menu) that will list all the strings found in the binary. Oftentimes, encryption libraries will accept a string like "SHA-256" to indicate what kind of algorithm to use.
Additionally, look for anything that could be a key. The kind of key being used depends on the algorithm, so you may be looking for a password, passphrase or not a string at all but a block of data.
If you can find the name of the encryption routine as a string, you can cross reference it (the x key in IDA) back to the original encryption function. If you can find the encrytion function make note of the address.
Dynamic Analysis
Some of the Disassemblers mentioned above (including IDA) also include a debugger. I personally like OllyDbg. Set a breakpoint at the encryption routine you fund above and then run the program. Inspect memory and attempt to find the encryption key.
You can also use your debugger to dump the memory of the program. After dumping the memory of a live program, you can use a utility like strings in sysinternals to attempt to locate a key.


Is Power Failure an Environmental or Structural Threat?

As @ConorMancone says, there's no reason it can't fall under both categories.
When a hurricane takes down power lines and imposes a power outage, that's an environmental threat.
When the power supply company lacks sufficient capacity and inflicts brownouts and blackouts on its customers, that's a structural threat.  (Peabody, I'm looking at you).
These both meet the posed question, "Susan has lost power to her building" so such a question would be wrong without more details to indicate which interpretation is more valid.


Best practices for connecting USB key to secure computer?

The main issue with this approach isn't the reuse of the same USB stick. If you're defending against state-sponsored attackers there's a good chance they are able to tamper with your supply of USB sticks and give you some with their malware already preinstalled. However, since the machine has no way of talking back to the outside world to leak the secrets, getting malware on it may not be a big deal.

The problem is that since the machine can write to the USB sticks, it can use those to exfiltrate data. Whether you use new sticks or reuse the same ones, the problem still exists (unless you take great care of securely erasing/destroying the one-time use sticks before discarding them).

What I would recommend is using physically write-once media. An optical disk padded with random data (otherwise there may be a way to burn more data in the free space even on a non-rewritable disc), or a trusted USB stick (with firmware you made yourself or audited) with a physical write-protection switch. That would give the secret machine no way to leak its contents, assuming we discard theoretical attacks like encoding data in the CPU's EMI interference, etc.

You could also use a physical one-way connection like an Ethernet cable with the sending pairs cut, a serial cable with the TX line cut from the secret machine, or an audio cable connected to the audio input of the secret machine. That way it could receive data digitally without requiring human intervention to deal with storage media while having no way of talking back to the outside world.


How to avoid GAE app traffic being abused?

There are two types of automation that you should be concerned with in regards to automation.

On one side of the coin there are search engine spiders that will pull down whatever they can,  you can direct these spiders with a robots.txt and sitemap.xml.  Which is a simple problem to solve.

On the other side of the coin there are the (very uncommon) content scrapers.  These are virtually indistinguishable from search engine spiders.  They often use the same user-agent,  and use about the same amount of bandwidth as a search engine spider becuase they both want to be up-to-date.  To find a spider that is breaking the rules you could specify a blacklist request handler in your robots.txt,  and if anyone hits that page,  you could ban them.   Although,  the number or malicious spiders is very, very small,  and this could be leveraged as a CSRF-DoS attack,  whereby an attacker forces a victim into loading the blacklist request handler.

...  that being said 1GB is TON of text,  and its very unlikely that you would go over this limit unless you where the victim of a DoS attack.


What's the Impact of the CloudFlare Reverse Proxy Bug? ("#CloudBleed")

Compared to the famous HeartBleed bug leak, this is similar in some ways: the uninitialized memory exposure means unrelated private data is disclosed.

The things that are better

This only affected code running on CloudFlare, and the bug ceased to function an hour after notification. No new data can be leaked via this bug.
If somebody had awareness of this bug, they couldn't target an individual with it. The dumped sessions appear to be random.
CloudFlare has logs, and they have disclosed no indication that anybody knew of and exploited this bug.

The things that are worse

The size of the uninitialized memory dumps is huge. They regularly capture full HTTP headers and substantial sections of the request body. This pretty much gives away all the data required to hijack a session, and if a login session was captured, it would of course include the password.
It was free-session-roulette. Repeated requests to invalid URLs would just dump more and more random data.
If somebody were aware of this, they could have crafted a page that caused it to create nearly arbitrary size data dumps, or even just repeatedly hit an already existing invalid URL.
An end user could be compromised without any weakness in the part of the website or the user.
A few unlucky users will still have that leaked data existing in caches after this disclosure, and they're going to be very widely disclosed. If those session cookies aren't invalidated, it's practically guaranteed somebody will log into their accounts.

How can somebody address an incident like this?

Limiting session token lifetimes and making use of proper two-factor authentication would address the long-term leaking of data, preventing somebody from acquiring a long-lived session. Customers of CloudFlare could invalidate all session cookies and force rotation of all passwords, though that's unlikely to happen.

What does this mean to me?

CloudFlare claims that no private SSL keys were leaked as they did termination within separate processes, so while the class of bug would normally raise concern there, it doesn't in this particular case.

It's a great lesson in the security community of thinking about possible long-term bugs that have a massive blast radius. Most people are likely completely unaffected, though as noted above a few people will have lost the Bad Luck Lottery.


Should we build a generic security unit test suite

Yeah, I'm having the same debate with my teams and I am equally conflicted about it.
Arguments for security unit tests:

Reusability / automation of security testing (ie you can re-use security unit tests against new products / features without needing time from the appsec team for manual testing)
Regression testing: continue testing for these security defects in the future, not a point-in-time manual test.

Arguments against security unit tests:

pen testing is often highly intuition-based relying on experience and training of the security tester, and typically not things you would think of if you just sat down to define the positive and negative test cases, and/or not even possible to test via unit tests. Pen test cases are also often complex. For example, is someone likely to write a junit test for "Do the login flow up to but not including MFA; take that mid-flow JWT and try calling APIs with it". Or "Create a JWT with sub= for each value in this XSS payload list then navigate around the UI and see if any of the javascript payloads execute". In fact, I'm not even sure how you do the later in junit.
junit tests are usually testing individual methods. You may find real security issues there, but the high-value security issues typically happen at the boundary of software layers; ex.: you have a GET controller that assumes CSRF protection is being applied to it, but Spring is only configured to do CSRF on POSTS. Or tomcat is listening for /admin reqs on :666 and the firewall had better be blocking that externally. (plus the ones in the previous bullet; mismatch between login and access control parts of the code; a mismatch between JWT and UI).

I guess where I've landed is that some of your manual exploratory appsec testing will be automatable. Like, at the end of a Burp or ZAP session, go through your history, find things that would be good automation candidates, export as curl, throw them into unit tests. Great, value added. But recognize that the high-value security issues will likely not show up in unit tests, so question whether this is the best use of your appsec time budget.


Can an Intrusion Prevention System (e.g. Snort) prevent CSRF and XSS attacks?

Intrusion Prevention System is a broad term. It basically says only that it is a system to prevent intrusions and does not imply a specific technical implementations. Therefore a variety of systems which somehow had the goal to prevent intrusion, were marketed as IPS when the term was hot. Therefore a generic statement about the capabilities of IPS to solve a specific problem cannot be made.
As for systems like Snort or Suricata: These basically try to match pattern in the network traffic using predefined fixed signatures. They are capable of parsing HTTP traffic and do basic analysis on it. These capabilities can be used to create custom pattern to detect specific and pre-known CSRF and XSS attacks. These are not enough for a more generic approach - simply because such attacks cannot be generically detected with simple string matches and regular expressions in the first place.
Additionally Suricata and Snort are not capable to analyse HTTPS traffic by their own. This means they must be strategically placed in the network so that they get the unencrypted traffic for analysis.


Can a webcam be turned on when disabled in Windows' device manager?

Most malware is likely to just iterate through all webcam devices and attempt to turn them on. Disabling the device in device manager is very likely to protect you against 99% of cases.

On a more anecdotal level, I've come across around maybe ten or so different bits of malware over the years that have various remote webcam capture functionality, but not a single piece of malware that has attempted to enable hardware devices that were previously disabled by the user.


Is there a safe way use a private key from a shared server?

Considering your explanation:

  I'm not worried about them seeing the contents of my GitHub repository - I'm concerned about them being about to use the private key to impersonate me and wipe our repo or clone other private repositories that aren't already copied onto the server.

You may consider using GitHub feature called read-only deploy key.

In a non-hostile environment you can use SSH agent forwarding, which lets you use the key on your client machine without the need to save it on a springboard server, but this method is exploitable by administrators.

If the machine you use as a springboard is controlled by a malicious admin, there is no way you can fully protect your key or your GitHub account.

Please mind that whatever method of protecting the key you use, the git command (which you might legitimately execute and authorise) could be replaced with a one doing harm.


Getting access and logging into employee's laptop - Can IT get access without the employee's own credentials?

This question is not actually specific enough to answer definitively.

Are you asking if they will be able to login to Windows on the computer using a domain account? (Yes, they can just reset your password)

Are you asking if they can access information contained on the laptop? (Also yes, unless there was encryption that you configured and only know the password to).

Are you asking about some other "network account"? (Still probably yes, businesses like to be able to manage employee access to products like this, which often involves resetting passwords)


Is there any difference between hiberfile.sys file and RAM dump made with 3rd party software for Volatility.py?

When entering hibernation:

Apps and services are notified
Drivers are notified
User and system state is saved to disk in a compressed format
Firmware is notified

(Per Microsoft's documenation on system power states.)

If an application or rootkit is so designed, it could attempt to hide or clean itself in response to the power state change. There is a timeout period after steps 1 and 2 to allow applications and drivers to prepare for suspension/termination.

This notification is both intentional and necessary: applications/services may span across multiple systems, and drivers must plan for data stored on volatile device memory to be lost. A similar notification occurs prior to system shutdown, albeit with a different status code.

A forensics-oriented tool may avoid "tipping off" the malware in some cases. It is also possible that malware from nation-state actors may detect common forensic tools.

I would expect that moderately sophisticated diskless malware will respond to power state changes, but it may not be capable of detecting forensics tools. So overall, I would expect to see an occasional benefit from using it. I cannot personally speak to the completeness or reliability of that particular tool, however.


Is it a good idea to combine words from different languages to increase a password's strength?

All that matters when calculating the strength of password generation strategy is how much entropy is involved in the generation of the password.

Using multiple dictionaries does not weaken the pass phrase. How much this strengthen the pass phrase through, depends on how exactly you choose your pass phrase.

From the perspective of calculating entropy, using a combined dictionary from multiple languages is exactly the same as increasing the number of words in your dictionary.

For example, standard diceware strategy used a dictionary with 7776 words. The strength of a 4 words diceware password is 7776^4 ≈ 2^51.7, or 51-bit. If you modified this strategy so you use a combined dictionary of 7776 English words and 7776 a Italian words, then the strength of your passphrase would be (7776+7776)^4 ≈ 2^55.7, or 55-bit, which is just 4-bit stronger than the standard diceware.

If on the other hand you decided that the first two words is going to be English and the last two words is going to be Italian, or if you decide you're going to use a combined dictionary of 3888 English words and 3888 Italian words, then these do not actually increase the strength of the passphrase from entropy perspective.

Generally, it's more fruitful to increase the number of words on the passphrase rather than increase the size if the dictionary. If you used 5 words standard dice ware passphrase, the strength of your password is 7666^5 ≈ 2^64.6, which is a nearly 13-bit increase from 4-words diceware. To get a 13-bit increase in strength by increasing the dictionary size from 7776, you need to use a dictionary that is 9 times the size of standard diceware dictionary (9*7776)^4 ≈ 2^64.4 (i.e. You need to use 9 languages).

It wouldn't hurt to increase the size of the dictionary, but it doesn't really add much entropy. From entropy perspective though, passphrase length matters more than the size of the dictionary.


Is this bank website secure enough? No https in login page

doesn't use Https protocol

The website you provided does support HTTPS, but not HSTS or HTTP to HTTPS redirect. That is why you could be directed to an unsecured HTTP site. SSL Labs analysis.

  Moreover your password can be at maximum 10 characters

Oddly this is common of online banking. I have experienced a bank which defined the following rules for a password {az-AZ-09} with a character limit less or equal to 10.

  there's no 2 step verification...

Despite this becoming a norm in security. Some still have configured their infrastructure with primitive security, given modern attack vectors. 2FA should be a must. Most banks will either provide a "secure key" or access to a one-time password from their mobile banking app.

My personal advice. Avoid online banking with this bank, and look for an alternative which can satisfy your security (OpSec) needs.


Security Standards for storing private customer data

Various countries have their own regulations on this, for example the UK has the Data Protection Act 1998 ( http://www.ico.org.uk/for_organisations/data_protection ) and there is HIPAA in the US ( http://www.hhs.gov/ocr/privacy/hipaa/understanding/index.html )

Also some regions such as the EU mandate data protection regulations for their member states.

All the major IT audit firms, such as EY, KPMG etc can do data protection audits.


The Need for includeSubDomains in HSTS RFC

I think the way to read those three points is as three parts of one vulnerability, and are best read in a different order. HSTS does make a difference on HTTPS connections, and in fact a very significant one: HSTS does not allow users to click through a warning from the browser. All certificate validation errors with HSTS are fatal; the browser will not allow the user to add an exception, which is the biggest issue with relying on certificate warnings alone to prevent MitMs. So, if the attacker registers that subdomain, the issue is (in different order from in the RFC):

The attacker's site serves up a TLS certificate. If it's considered a valid certificate by the browser then HSTS doesn't help (because HSTS doesn't include pinning), but it's likely going to be an invalid certificate.
The web browser warns of a certificate issue. Because the subdomain doesn't have HSTS set, the user can add an exception or otherwise override the certificate warning to go to the site.
The domain cookie is sent to the attacker's server over the TLS connection.

With includeSubDomains, the following happens:

The attacker's site serves up a TLS certificate; again, if it's valid, the user is hosed.
The browser warns of a certificate issue. Because HSTS is set, this is a fatal error. The connection is terminated before an HTTP request is sent.
There is no 3. The connection was terminated in step 2.

(As a side note: certificate validation always occurs during TLS connection establishment; no HTTP requests are sent until after TLS is established. So no cookies are ever sent over HTTPS before certificates are checked.)


How can the nmap tool be used to evade a firewall/IDS?

There are various ways that comes handy with nmap to evade the basic rules of firewall or Intrusion detection system.

1) Packet Fragmentation:

This option evade pattern matching detection technique. Since packet reassembly can be quite processor intensive, it's common for admin to disable it.
In snort, fragmentation reassembly functionality is disabled by default.
Usage: #nmap -f <other options>

2) Decoy Scan:

We can add some random hosts either from the attacker's subnet or from victim's subnet while scanning the target.
In firewall logs, there will be multiple hosts along with the attacker's IP making it difficult to trace the attacker.
Usage: #nmap -D <ip1, ip2,...,ME> <other options>

3) Spoof source IP address:

Attacker can spoof the source IP address (from the victim's subnet) so that it'll appear to IDS/firewall that it's legitimate user and will be passed.
Usage:#nmap -S <spoofed ip> <other optins>

4) Spoof source port:

Attacker can spoof the source port no. while scanning the target to bypass the rules in the firewall that allow requests from few ports (ex. Port 53).
Usage: #nmap --source-port <port no> <other options>

5) Scanning Timing:

There are various timing options included in the nmap to send successive packets. It can be used to evade some of the rules in the firewalls or IDS.

T0: Paranoid (Waits 5 minutes between sending each probes, not detected by IDS/IPS)

T1: Sneaky (waits 15 seconds)

T2:Polite

T3:Normal

T4:Aggressive

T5:Insane (easily detectable)

-Usage: #nmap -T<0-5> <other options>

There are other options like Data-length appending and Badsum which can also be used. IDLE Scan is the best that I'll suggest for evading the firewall.
Although, all the methods mentioned above claim to evade the firewall/IDS, but if rules are set properly your scan can still be detected.


How did Wanna Cry get past Antivirus Programs

Antivirus software usually detect malware threats in two ways:

signature-based detection
heuristic detection

Antivirus software products did not have a virus definition or signature for WannaCry since it had not been seen before (previously undetected threat) being a newly created malware. So it escaped all signature based detection.

Heuristic detection relies upon observing active execution of a binary. For example, if an antivirus observes a virus scanning for and modifying or appending executables on a system, it would flag the binary as possible malware or suspicious. The way WannaCry works is by accessing specific crypto libraries on Windows (for the process of generating keys and subsequent encryption) and then scanning for common document file types such as DOCX, XLSX, JPG etc to encrypt. The antivirus heuristics engine fails to detect this as a typical malware infection. They will possibly add heuristic capabilities to stop ransomware as it is executing by observing its behavior some time in the near future. For example: https://www.wired.com/story/shieldfs-ransomware-protection-tool/

Also, as you mentioned, it is possible that a lot of users who got hit were not using a properly updated and effective Antivirus solution. If they were big on updating software, they would have updated their Windows OS and had a patch for MS17-010 Eternal Blue vulnerability.


Server side validations for file upload to prevent DoS on HTTP server

One easy thing you may do is limiting maximum POST size, as well as upload max file size.

For exemple, using PHP, you may tweak :

post_max_size integer
    Sets max size of post data allowed. This setting also affects file upload.
    To upload large files, this value must be larger than upload_max_filesize.
    If memory limit is enabled by your configure script, memory_limit also
    affects file uploading. Generally speaking, memory_limit should be larger
    than post_max_size. When an integer is used, the value is measured in bytes.
    Shorthand notation, as described in this FAQ, may also be used. If the size
    of post data is greater than post_max_size, the $_POST and $_FILES
    superglobals are empty [...]

max_file_uploads integer
    The maximum number of files allowed to be uploaded simultaneously. Starting
    with PHP 5.3.4, upload fields left blank on submission do not count towards
    this limit.


You will need a wireless nic that permits a 'monitor' mode, and that requires some special drivers and special nics.

Kismet's list of cards for Linux
tests on different cards
pineapple device (special device)
airpcap nic (specialized nic for Windows)

Once you get a card, you will need software to deal with the data and Kismet is the leader in this area right now.


How to provide personal User Page after User already signed up without Password?

The traditional method of allowing users to enter a username and password works, changing it for a substitute of you creating their password or, worse yet, eliminating it completely seems a little odd.

I'd recommend sticking to the traditional way, however, in the interest of the question;

Sending them a unique URL

This has so many follow up questions, but on the assumption they sign up and you send them a url to access their "data"?  There isn't a safe security practice behind this, you've said it yourself, if someone else obtains that URL, you have a compromised user. Stick to the tried and tested method of correctly implementing sessions into your website. Along with minimizing security breaches, you also then won't need to worry about hosting X amount of separate web pages for every single user.

Sending user a password

I don't see any reasoning behind why you'd want to do this, letting a user set up their own password is no additional effort to you at all. Sending them a password runs the risk of emails being compromised.

What happens if an email that's meant for "Jake" is compromised by "John". I don't think Jake would be all that forgiving because you insisted on creating, and sending a password to him.

If you do insist on using these types of methods, be very, very careful with regards to what information you store and what kind of information users can access.


Why is phishing becoming synonymous with ransomware?

Phishing is simply a delivery mechanism that works by duping the recipient into believing a message is benign.  They're cheap to deliver, and often target old, unpatched systems (that still have active users.)  The only definition that matters is "trickery".

Ransomware is the malware of choice simply because it's the most instantly profitable crimeware on the market today.

It's not a surprise that people conflate the two. Try not to be bothered by the terms people misuse -- it's a waste of your focus.


Do command substitution and piping prevent prying eyes from seeing hashed password being passed from process A to B?

While the approach may have some advantages, there are several ways the password still may be intercepted.

The bash history will show the password in plaintext, the makepasswd command may be compromised, the shell may be compromised and so on. There is little reason to do this honestly. Generally, what an attacker can do depends a lot on his privileges, but I would not consider either of these approaches more/less secure. As far as I can tell, 1 and 3 are about the same in terms of security. A pipe may seem  better, as it bypasses shell, but shell already has the plain-text password, so there is really no reason to worry about that. Still, I would probably go with the pipe.

PS: Both of these may still show plain-text password in the process list while makepasswd is running.


How come  calls do not violate the Same Origin Policy?

This is considered acceptable because scripts are limited in interacting with cross origin images unless crossorigin="anonymous" is set, which tells the browser not to send cookies or other credentials when retrieving the image. Without setting crossorigin="anonymous" scripts are allowed to retrieve dimensions, but not pixel data from the image due to the tainted canvas.

This is fine in theory, although there have been side channel attacks in the past that leak pixel data.


What stops us from using an  tag to stop XSS?

I don't think it would actually help.

If I understand correctly, you are proposing a scheme like this:

<antiscript>
    "$user-supplied-input"
</antiscript>

correct?

So what's stopping me from breaking out of it by providing the input:

"</antiscript>

so that the page source will be:

<antiscript>
    ""</antiscript>"
</antiscript>

The page is parsed, my  will not be inside the <antiscript> </antiscript> in the DOM. (the HTML that follows it will be broken, but since HTML parses top-to-bottom, my payload will make it into the DOM, so who cares?)

You address this in the question:

  It would be rather easy to detect someone trying to break out of this non-scripting context because the tag would need to appear.

But that means that under no circumstances could the string "</antiscript>" appear as text anywhere on the internet. That seems like a problem. What if, for example, you wanted to write a blog describing how to use this feature?


What are the security risk of enabling cors on localhost?

The answer really depends on what API you created and how it works.
This site gives a very good explanation on the goods and bads of CORS. In short, the author creates a fictional API that is used to send e-mails from another domain. He states:

If you are using authentication based on session cookies, you probably shouldn’t allow CORS requests by everyone. A malicious website can issue e-mail sending requests to api.yoursebsite.com via an AJAX request without the specific permission of your user.

This is (in his hypothetical case) the answer to the question "what are the risks of enabling cors"? In that case, he also gives some more information about how to think of mitigation:

If the user has valid session cookies in their browser, they will be used to authenticate on api.yoursebsite.com and that would lead to unwanted e-mail sending. In most cases, dangerous requests will be “preflighted,” which means the domain needs to be approved before they can even send a request. This will prevent any malicious activities from happening.

This states (in a slightly hidden way) what dandavis already said: CORS has not much to do with security. The security is done on server side. The SOP won't be obeyed by hackers anyway.
In your case, from what I understand, you want to enable localhost as a domain via CORS so that requests can be made through some different domain?
If that is correct, I think that you will face no real security issue. Under the precondition that you opened some socket bound only to the loopback address (localhost), the only way someone would be able to access that (in a malicious or in another way) would be: He already has access to the loopback address. That means: He already gained access to the device.
Based on Conor Mancone's quite right comment: CORS primarily protects against unauthorized read requests. It is not protecting the server from writes or triggering unauthorized actions. This has to be enforced by an authorization concept.


This is a feature of Facebook to make logging in easier by not having to enter a password every time.

How does it work? Cookies.

Facebook uses cookies to identify you so that when you log out, you're able to login again without a password. This feature can be disabled as follows: Settings -> Security and login -> Login using your profile picture -> Turn off profile Picture login.


My first instinct is that it's some homebrew algorithm. It might be online somewhere, but there are a million of these homebrew algorithms. It's unlikely you could find it if it's something obscure, though you can try a few top google hits just to see.

Another idea is that it's encrypted and stored with some weird encoding (since I see letters but it's not base64). Or it might use some custom encryption.

It could be a fun challenge to crack this system but we'd probably need to be able to create our own hashes. For example if you have two users with the same password, do they have the same scrambled password? Does the algorithm do something funny when you pass it all zero bytes (0x00)? Etc.

I'm not sure what you need this for, but I'd look at ways around it. If you bought a website and it uses this, just replace the hashing algorithm with bcrypt or something. Or if you're looking at software to potentially buy, you can tell the vendor you're interested in the security of their product and ask details about the hashing algorithm. If they refuse to give it, that's a big red flag. Nobody who understands security evades or denies questions regarding their use of algorithms.


I am not aware of an existing solution. Assuming you are using something like nc -l -p 4444 -e /bin/sh, you could write a script that would be called instead of sh and acts as a password protecting wrapper for sh.


Use explicit_bzero() to zero entire memory

If you could zero all of your memory, then yes it would cause the system to crash immediately, as none of the OS data or code would exist anymore, the system would not be capable of continuing to run in any capacity.

But you would not be able to do this just by calling bzero from a userspace application. The kernel generally restricts an applications memory access to within its own address space, so this would not be allowed.


Is open-sourcing the code of a webapp not recommended?

It's a complex matter because there are several aspects to consider, with pros and cons, and there might not be a definite answer.

The security advantage of open source software is supposed to come from a "law" that Wikipedia calls "Linus's law", which says that "given enough eyeballs, all bugs are shallow". To start with, you'd have to ask yourself how many eyeballs you are going to have. For example, is your project going to be shared, forked, used extensively by lots of users and reviewed by a large community? Or is your software only going to be used on your website and no one else will care about it? Or maybe no one else will be able to reuse it because it doesn't come with a free-software license? In the end there are going to be white-hat eyeballs and black-hat eyeballs, so you need to be willing to accept that on one hand you will get some security improvement from ethical hackers, but on the other hand you will also be attacked by black hats. Will attackers be especially interested in targeting your project, or is it just going to be subject to non-targeted attacks? These are all things you should consider, and it might not be easy to draw a conclusion. It's also worth remembering that in several open source projects there were security vulnerabilities that had been there for a long time despite all the eyeballs of the community (see Linus's law on Wikipedia).

Security by obscurity is another concept that is often misunderstood, because its name makes it sound like it's all about keeping something secret. It's not so. Security through obscurity is when a significant part of your security comes from the secrecy of the methods (the implementation). Here's an example of security by obscurity:

// Login without password if URL has parameter dev=debug
// I'm a stupid dev, so I believe this is secure because nobody knows about it!
// But this source code can't be published or I'll be hacked at once
if ($login_password === $password || $_POST['dev'] === 'debug') {
    login_ok();
}

Anyway, even if your code is correct and you rely on security by design, nothing stops you from using a layer of obfuscation on top of it. That is, keeping the source code private can help you because it will slow down a potential attacker. The important thing to remember is that obscurity is ok and can be considered a great asset only if it's just a layer on top of good design.

In conclusion, I'd say you'd better not publish the source code unless you have a reason to do so (for example because you want your software to be free/libre and you want to create a community around your project). If your only goal is to improve the security of the application, you won't gain anything from just publishing it on GitHub, for example. If you are really worried that your software might contain mistakes and you'd like someone else to help you by providing more "eyeballs", you might consider paying for a professional security audit.


How effective would a heartbeat sensor be at stopping spam?

As the comments say, security needs to be done server-side, not client-side.

If somebody wanted to send spam to your server, they would not use your app to do it, they would sniff the data packets that your app is sending to the server and then build their own app that sends those same packets with their message instead.

For this reason, in security analysis we always treat the client as if it is malicious and make sure the server is not relying on the client to perform the security checks. In the case of a captcha, the results are sent to the server to be verified before it will process your request. You could send the heartbeat data to the server, but I'm not sure what that accomplishes because the spammer could just record a heartbeat and send that over and over. You could also probably make a heartbeat generator pretty easily based on a random number generator.

Inventing new security technology is hard, it takes a lot of people and a lot of failed attempts to get it right. There's an old saying "Anyone can create something that they themselves can not break, but creating something that nobody can break is much harder". I like that you are thinking outside the box and asking questions. Keep exploring :)


Script injection on different hosting servers = FTP hacking?

It's also possible that all your websites have a common element (an insecure file upload) that's being targeted. Or someone is snooping on your network (which is why SFTP/SCP is better than FTP) But it's likelier that your passwords have been stolen.

It's generally a bad idea to store sensitive passwords in an unencrypted form on your local machine. Saving passwords is useful, but I personally use it for passwords which I don't care much about. (Even things like Firefox's master password feature can be circumvented by copying the entire user data directory). If you want to store sensitive passwords on your own machine, be sure to keep the machine secure with an antivirus and a strong firewall.


Security against IP Spoofing without consulting network administrator

Under normal circumstances, the NAT / PAT rules on the router will change the source IP address to its own (public) address.  This is done by the router/gateway itself, and can not be set by a client (unless [mis]configured to do so).

The target webserver will still get packets from the real (public) IP address.


Monitor websites being visited on network

The exact answer to this depends on the level of control you have over the wifi network.

Assuming that you can dictate things like proxy servers, then the best option might be to install a forward proxy (something like squid) and then have that do the logging for you.

If you need to know actual URLs rather than just sites, you'll need to set-up SSL interception which involves things like deploying SSL root certs to your clients and also places a large responsibility on you to secure the proxy and certificate infrastructure (failing to do so could impact the security of everyone on your network), so I'd avoid that unless you really need to.


if one goes to my site via www.example.com , it will work without any certificate warning , correct?

Yes.

  how to call then this type of certificate ? Wildcard SAN certificate?

Whatever marketing department comes up with.

There is no fixed term "SAN certificate" -- it is a shorthand, possessive expression: a certificate with the SAN extension defined.

  if a wildcard certificate applies to a given domain, example.com in this case, can I include different domains e.g. example.com, test.com, adam.com in a SAN [ ]

Yes, you can.


The solution is: Certificate System manager

Some of the candidates are:

DogTag
Red Hat Certificate System (based on DogTag)
EJBCA
OpenCA


SSRF when user input is appended to hostname

As mentioned in the comments, always sanitize user input.  Always assume the user may be malicious.  While your snippet doesn't appear to be directly exploitable, you should also consider that not all URL parsers behave the same and the library you're using may affect what sort of exploitation you may be vulnerable to.

In a perfect world, you may be safe, but it's always good to do additional checks just to be sure.  For example, if you only want users accessing certain pages, you should set up a white list.  If they're not supposed to access subdirectories, make sure no slashes exist in the URL (encoded or otherwise).


A Method for Generating Un-Guessable Client Identifiers

OAuth documentation states that client identifiers are public and simply need to be unique for all clients of that authorization server. They also advise that the ID not be easily guessable to decrease phishing attacks.

The method you proposed is valid, but doesn't provide any additional security over a randomly generated number.

The client secret is the part that has to be cryptogrically secure.


How to secure handshake system-to-system in RESTful API calls without user/pass?

Here are my "off the top of my head answers", which may change after I give it more thought.

1) I'm not sure if there is much point to a salt here.  In normal usage a salt protects a leaked password database against rainbow attacks.  That certainly isn't relevant here, and moreover I don't think there is any other reason for the salt.

2) Hashing also doesn't add a whole lot of security, I think.  Hashing is used to hide a secret during storage, not transit.  If you hash it and pass along the hash, then that means your hash effectively is your secret, and a stolen hash is no less dangerous than a stolen secret.  Therefore, in a very real sense, you might as well just send the secret itself, especially since it will change regularly.

In summary, you effectively have two defenses in place: a shared secret (which changes), and IP white-listing.  Your shared secret is going to be primarily vulnerable to things like replay attacks or request eaves-dropping: if anyone happens to see it in transit, they will know the secret until it next changes.  You mentioned this is system-to-system, so depending on whether or not your systems are in the same security zone will probably determine whether or not such a request needs to happen over TLS/SSL.  If these systems are communicating between data-centers, you'll probably want to be communicating exclusively over TLS/SSL.

Your second level of security is via IP white-listing.  This is primarily vulnerable to IP spoofing, which, depending on your network setup, may or may not be be an issue.  I'm sure there are more options as well, but I'm not a network expert.

For a completely different approach you can try implementing a handshake.  The basic idea is that when server A sends a request to server B, server B validates the request by contacting server A directly, passing it the full request that it received, and getting back a YES/NO response (the "no" obviously being returned if server A did not send the request in question).  Only once it receives the "YES" does it actually process the request.  This takes more effort to setup and also takes more network/server resources, so may not be preferable depending on your application needs.  The advantage is that it rules out IP spoofing, and also makes the secret exchange unnecessary.  However, it may not prevent more direct network attacks (i.e. MITM and the like).

Edit to add:

The handshake idea isn't actually my own.  I've used that general flow in my applications to validate server-to-server notifications.  The idea itself I stole from paypal (it is how they validate their IPNs), although it probably isn't originally their idea either.  I point this out simply because it is a practice that has been in use for a long time, so you can both read their documentation to understand the flow and (potentially) look for information about past security issues that may have arisen due to that flow.  Presumably though, since paypal relies on it for a critical part of their payment infrastructure, it is fairly secure:

https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNImplementation/


How would I brute-force a Bitlocker recovery key?

Well you have to brute-force the 48 character recovery key (https://blogs.msdn.microsoft.com/si_team/2006/08/10/bitlocker-recovery-password-details/)

As I remember it visually shown when 6 character sub-key is successfully entered so I guess it is possible but if there are tools available I'm unaware of.

Good luck


Ultimately, the user has the ability to trigger actions on your API, via some chain of authentication. The difference between storing the JWT in a cookie, and storing it on a separate server, is the number of steps in that chain: does the user's browser authenticate directly to your system, or does it authenticate to an intermediary, who then authenticates to you?

Encryption is largely irrelevant here: the user does not need to know what the token means, they only need to be able to send requests including it. If the browser can do so, anyone with access to that browser can also do so. If you want information in the JWT to be confidential, you can use an encrypted rather than signed JWT.

Moving the JWT from the user's browser does not automatically add any security, but it allows the intermediary to perform additional checks; for instance:

If the permissions granted to a particular JWT are quite broad, the intermediary can narrow those down by only passing on some requests.
An intermediary which is closely coupled to the UI can more easily implement defense against CSRF, ensuring that requests are only passed to your API if they originated from a valid application flow.
The intermediary can implement its own invalidation flow - if the user has a stateful session in some key-value store, that store can be cleared to log them out, and the user has no way of retrieving the JWT.

It is possible for all of these checks to be implemented in the primary API, so this partly comes down to "purity": you can make certain assumptions in your API design if it will always be accessed via a trusted server which you cannot make if it is accessed directly by untrusted clients.


Does keeping a password history increase the risk for the user?

If system A stops people from reusing passwords (and therefore keeps a password history) it is good for the security of system A. It ensures that passwords are regularly changed.

If it takes a year to crack the average password, but passwords are changed every half year an attacker can not get much value out of a data breach. Sure, you don't have to be a genius to guess what comes after password1 and password2, but it is still better than just keeping password.

You are right to point out that storing multiple hashed password gives an attacker more value if they want to attack system B, where users might have reused passwords from system A. But if your main concern is to protect the assets of system A, and not protecting your users in general, that doesn't count for much.

So I would say it is a question of what you want to protect. If you only care about your own system, go for a password history. If you care about users that are reusing passwords being vulnerable on other systems, then don't. What one should or should not care about is inherently subjective, so it can not be answered here.

(There is also an argument that forcing password resets makes users pick worse passwords, and therefore should not be done at all. I'll left that aspect out of this answer since I don't think that was what the question was about.)


Are salted SHA-256/512 hashes still safe if the hashes and their salts are exposed?

The question doesn't state how many rounds of hashing are performed. And the whole answer hinges on that point.

All hash functions are unsafe if you use only one iteration. The hash function, whether it is SHA-1, or one of the SHA-2 family, should be repeated thousands of times. I would consider 10,000 iterations the minimum, and 100,000 iterations is not unreasonable, given the low cost of powerful hardware.

Short passwords are also unsafe. 8 characters should be the minimum, even for low value targets (because users reuse the same password for multiple applications).

With a $150 graphics card, you can perform 680 million SHA-1 hash computations per second. If you use only one round of hashing, all 6-character passwords can be tested in a little over 15 minutes (that's assuming all 94 printable ASCII characters are used). Each additional character multiplies the time by 94, so 7 characters requires one day, 8 characters requires 103 days on this setup. Remember, this scenario is a 14-year-old using his GPU, not an organized criminal with real money.

Now consider the effect of performing multiple iterations. If 1,000 iterations of hashing are performed, the 6-character password space takes almost 12 days instead of 15 minutes. A 7-character space takes 3 years. If 20,000 iterations are used, those numbers go up to 8 months and 60 years, respectively. At this point, even short passwords cannot be exhaustively searched; the attacker has to fall back to a dictionary of "most likely" passwords.


What are the best practices to secure an Angular & Spring web project?

[AngularJS] Common Pitfalls

AngularJS makes it very easy for developers to get in to some dangerous territory. Here's some common things that I see when I assess websites using AngularJS, regardless of the backend:

Lack of server-side session validation
Lack of server-side input validation
Decoupling the frontend from the backend and forgetting things like output encoding

Lack of server-side session validation

The near-universal pitfall I see is that the frontend handles all of the session checking and routing, but I can just call the backend endpoints and be anybody I want to be. AngularJS also has this cookie thing it does with defining the user permissions in the cookie. Don't do that. I can manipulate that cookie and send it to the server.

To avoid this, do your session checks server-side.

Lack of server-side input validation

Another common pitfall I see is that AngularJS gives a lot of nice tools to developers to do things like routing, input validation, all in a nice, rich UI. However, those input validations aren't done server-side.

To avoid this, enforce validation checks on both sides.

Decoupling frontend and backend

As mentioned, AngularJS gives nice things to developers. However, when the backend and frontend are decoupled for things like UI generation, routing, it is easy for developers to forget where the data is coming from and forget to properly output encode. AngularJS does do some things to help you, and newer versions target output encoding specifically, but ensure that you do it correctly.

[Spring] Common Pitfalls

For the most part, the advice I give is independent of any framework chosen. However, the backend is much larger, and I could write a book. So instead, I'll try to limit it a bit, especially given the question.

Ensure the framework is properly configured. Frameworks like Spring come with out-of-the-box with developer-friendly tools. In the case of Spring, be sure to read up on the production-ready endpoints, for example.
Maintain your patches. No framework is without bugs, and Spring is no exception, having experienced significant security vulnerabilities in the past. Keep your pom/gradle versions up-to-date and you'll be fine.
Review deployment practices. While this is probably starting to get outside the bounds of your question, I want to bring it up because it is part of the learning process.

Encryption

With that all said, now the encryption. Unless you are doing something where the user should be the only one with knowledge of the key, doing encryption in JavaScript is highly discourage.

With user passwords specifically, industry standard, and recommended approach, is TLS. Anybody between the browser and your server will not see or be able to manipulate the data. TLS certificates are free these days, so there's really no good reason not to if it is on the internet. Without knowledge of what kind of data you want to encrypt, I can only give you some common pitfalls of doing something like this in the browser:

Key generation, expiry, storage, and revocation
Ciphertext storage
Encryption algorithm

Keys

Putting aside for the moment your explanation of wanting to use the user password, encryption requires key management. You need to handle generation, storage, expiry, and revocation. This means that you need to have sufficient entropy to generate the key, decide how to handle the key once it is generated, how to handle the key when it approaches expiry and once it has expired, and when the user decides they want to change their key.

In your case, this actually becomes a little more difficult, because now you have to build functionality that'll rotate the keys when they change their password. Otherwise they'll lose access to their old data.

Ciphertext storage

Now that you have the key management, how and where do you store the ciphertext? This becomes a question that matters more for the data you want to encrypt.

Encryption algorithm

Inevitably, you'll need to chose how you want to encrypt the data. Do you use symmetric or asymmetric keys (your stated use case is symmetric)? Now you need to choose algorithm and mode of operation. And randomly generating an IV.

Conclusion

Engineering a solution that can handle encryption on the frontend safely is hard. Really hard. A lot more difficult than handling it on the backend. There are legitimate reasons for doing the encryption on the frontend, but since this is a learning project, I'd encourage you to start on the backend and then work towards the frontend.

There's a lot in this area that I haven't covered and can't cover here for space reasons, and without knowing much more about your objective. In my professional line of work, questions I'd typically start with include:

What data are you trying to protect?
Who are you trying to protect it from?
Are you prepared to handle the unique difficulties on the frontend?

This isn't to discourage you, as there are legitimate reasons for doing this encryption on the frontend. But it is hard to get right, and using the user's password has additional complexities that need to be solved for, some of which I mentioned above.


Hashing Email Address and Contacting User

Hash collisions involving non-hostile users and real-world data are vanishingly rare if you use a cryptographic hash function.  For example, if you were to use SHA-1 as your hash function, you would need to have 1,200,000,000,000,000,000,000,000 users before you'd see a 50% chance of two of them having the same email hash.  There may be reasons to use a method other than hashing to secure the email addresses, but collisions aren't one of them.


Certificate Signing Requests are independent of the issuer at this point.

It only binds the requester information (including public key) together with a signature which prove the CSR has been made for a public/private key you do possess.

Any CA can then proceed to issue a certificate with this information.


Verifying hardware-backed key pairs with Key Attestation

The certificate extension data is certified by hardware-backed keystore/strongbox (TEE) using its private key. The corresponding public key of TEE is certified by Google that acts as root of trust which is a mandatory requirement for all GMS licensed android 7+ devices. Device manufacturer injects certificate chain into the device's TEE at the factory.
The intent of key attestation is that apps can ensure that whether the provisioned secure environment is not emulated by the user by root access on the device. An emulated TEE cannot extract private key of real TEE so its chain of trust has to be fraudulent. To verify the chain of trust, the querying app needs to acquire Google root certificate and match it with the attestation data.
Local verification of attestation data can be manipulated by code injection by an app with root access. Code injection can feed fraudulent Google root certificate to the querying app to pass verification. Whereas forwarding the attestation to the web service can verify chain of trust externally and the client is let known about the attestation result. Online verification also allows web service to refuse service to the client if valid secure environment is not provisioned.
Certificate revocation can also be manipulated by the user. E.g. An emulated TEE can use compromised but valid chain of trust whose revocation status has been manipulated to pass local verification. Web service can verify certificate revocation status externally and discard attestation data if the certificate is found to be revoked.


From the point of view of the server, all that can be seen is the client certificate (a public object, which is basically a bunch of bytes that everybody knows) and also a signature from the client (the signature is computed during the SSL handshake). The signature, being verified, offers some guarantee to the server that whoever is talking to it also knows the private key (which corresponds to the public key in the certificate).

The private key is everything. In cryptography in general, you are what you know. "The client device" is then defined as "whatever systems who can compute signatures verifiable with the device's public key". If an evil admin can slurp all the private information from a device, then he will be able to get the private key and impersonate the device with, say, another hardware element or even a PC. There is nothing you can do about that server-side: from the server, there are only zeros and ones over wires to be seen. The server cannot know that any piece of hardware even exists.

In order to achieve the kind of resistance you are after, then you need some tamper-resistance: make it impossible, or at least very hard, to extract all of the private information from a client device. That's typical smart card area. Now you see why mobile phones have a SIM card...


Which is safer as a URL storage, favorites or browsing history?

The advice is usually in the context of avoiding phishing links:

  Don't click on links in emails! Bookmark your banking websites and
  always use the bookmark!

I think using browsing history as a similar safeguard is probably fine also (within the parameters you described), as long as you've never clicked on a malicious link in the past.

However, it's probably not widely mentioned because:

Browser history will often have many entries for a single website because of all the individual pages on that site that you've visited
Browser history should be viewed as temporary. It can be easily cleared deliberately or accidentally. Bookmarks are much more permanent.


Is there a good site I can use to convert a string into any encoding?

You can use CyberChef. It allows you to try out a lot of encodings, compression, etc and you can chain them together. Can run in the web or you can clone your own copy.


How would someone execute a Perl script on a webpage?

As stated on stackoverflow, the Perl script in this attack vendor serves as "launcher" of the attack, not as part of it. Important part in it is the null byte \0 part, which can theoretically fool the blacklist, as java\0script does not equal javascript. The %00 vendor you have specified is null byte too, however in URL encoded form. It will only work if you find website, that is has vulnerable part of the URL. Burp Proxy can however be used the same way like Perl script, but you're looking for the Hex value to change, rather than injecting \0.


Running code generated in realtime in JavaScript with eval()

Using eval in this context doesn't create any vulnerability, as long as an attacker can't interfere with the arguments passed to matchCondition.

If you find it easier to read / program it this way, and you're confident that no untrusted input will ever go into your expression compiler, then go for it.

eval isn't evil, untrusted data is.

Please note that it's entirely possible to avoid eval, by extracting the predicates then handling them with your custom functions, for example:

if (predicate === 'isLoggedIn()') {
    return Π.isLoggedIn();
}


Risks of using a root container to manage Docker daemon

Will this approach reduce the possibilities of an attacker trying to get control over the socket?

Maybe, but probably not much. Why bother? Opening port 2375 for everyone is not the way Docker is meant to be configured and documentation rightfully warns against it.

Follow the Protect the Docker daemon socket guide and set up the TLS port with the TLS client verification.

Or use the Docker Machine which, given the SSH credentials to the machine running the Docker Engine, will automatically set these things up.


Why is Webauthn not used as primary authentication method?

It is not as flexible.
I am at my friend's place and I get an alert on my phone that someone wired some money out of my bank account! I need to login to my bank's site to check whats up. But, my public key/cert is in my computer and I have not registered to the bank using my friend's machine. Or I forgot to carry my Yubikeys with me. Now what do I do to quickly login?
It does not have the necessary client support yet.
We use webauthn for some of our internal workflows in our organization. It works flawlessly for web browsers but it doesn't have the necessary support for other clients yet. For example, there are several applications that run as Desktop clients on Windows/Linux/Mac etc.
If you look at the support matrix on FIDO alliance's website, their support for some scenarios is still work in progress:

Source
Electron is a popular application framework based on Chromium browser. It doesn't have a clear answer for U2F support yet. Some users claim it works while some can't get it to work.
If your application is going to be supported outside of just a browser, then currently you don't have much choice.
One of the major device makers, Apple, joined FIDO alliance to move users away from passwords as late as Feb 2020. So, there wasn't enough urgency to even support many of the user scenarios.
It is not an easy job to replace passwords entirely
Getting rid of passwords means changing user behavior. That takes a while. Here, usability of your security mechanism plays a huge role.
Before Face ID, Biometric auth in phones and Windows Hello, there was no cheap way for general public to use anything other than passwords to login. And these are fairly recent technologies.
Mobile phones have done a great job so far of integrating separate authenticators like Swipe patterns, biometric etc to replace passwords. But till we get such easy and free technologies available to mass market for Desktop, it is going to be hard to replace the passwords.


Can a Cisco ASA 5505 block this DDoS attack?

You have a number of separate queries here, so I'll try and get through them.

If you have the IP addresses then yes, you can get the 5505 to block - that's pretty simple - just add the IP addresses to the block list (or depending on your needs, block everything except traffic from known good IP's - whitelisting)

Cisco offer SYN Flood protection - worth looking at to see if it fits your particular situation. It's very basic, but works very well for certain scenarios.

A 5505 will not help on the GET request - you'd need a Deep Inspect capable firewall. Depending on your webserver, you may be able to do this here.

You say the proxy ddos mitigation was not useful. This is actually a very useful and successful solution thousands of companies use, so maybe you need to look at how you are using it.


How can I make sure nobody is accessing my computer with DameWare or something similar?

[Edit]

Well, your edit makes the question specific to Dameware, rendering the below answer not so useful. In that case, assuming you have the privilege to edit firewall rules (which i doubt a little), you can block the inbound and outbound traffic on the ports used by Dameware.
Here is the list of ports used by dameware: -
http://documentation.dameware.com/dmg/Content/dmg_port_requirements.htm
[Edit End]

Use wireshark.
It's a great tool for monitoring your system's live network related activities.

You can start wireshark on whatever interface you are connected to (like Ethernet or WIFI). It will start capturing each and every packets that leave your system or enter your system ie. Inbound and Outbound traffic. While doing that, make sure you are also accessing or using your exposed port like 80, 443 (or other ports that you know are open), reason being I have seen many malwares that lie dormant and are only triggered when user do some activity, so that it can hide it's traffic under user's traffic.

After doing the capturing for some time stop the capture, save the pcap file and you can again analyze it using wireshark. It has great filters to help you out of the heap of packets.
Here is a quick start guide for it: - http://www.howtogeek.com/104278/how-to-use-wireshark-to-capture-filter-and-inspect-packets/

Assuming that you do find something suspicious, you can mitigate them accordingly.
Hope this helps!


Is it possible to create an executable file by hashing a different file?

Well... rather than worry about the statistics, which as you mentioned is unimaginably small. Let’s take another angle.

Depending on the hash function, the output is usually 256-512 bits long, but according to this the smallest possible exec in Windows is 97 Bytes — which is 776 bits.

Hence if you’re using Sha256 or Sha512, I Guess the answer is definitely no, as there’s just not enough bits in the output to make the file.

Different hash functions that can output hashes that are at least 776 bits Long are the only ones that are possible to ever be able to make an exe by hashing another exe.

Nice theoretical question — but again, very very very Low probability.


One important part of OCSP which you might not be aware of is that the OCSP response is signed and has a limited life time. This means it actually does not matter where the TLS client got the OCSP response from because the OCSP response itself can be verified independently of how the client got it. This property is used within OCSP stapling in that

The TLS server (i.e. web server, mail server ...) asks the OCSP responder about the validity of its own certificate.
The OCSP responder returns an OCSP response, which is (directly or indirectly) signed by the CA which issued the servers certificate. This OCSP response can be cached for some time by the TLS server.
The TLS server can include this OCSP response when doing the TLS handshake with the TLS client. This is called OCSP stapling.
The TLS client can treat this stapled OCSP response the same way as if the client would have asked the OCSP responder, i.e. verify the signature and life time on the OCSP response and only use it if the signature is valid and the response is not expired.


The difference between risk assessment and risk analysis

Risk analysis is part of the risk assessment. The risk assessment combines risk analysis and risk evaluation (the process used to determine risk management priorities by comparing the level of risk against predetermined standards).


It might be vulnerable, but we can't tell reliably without more information.

But first, you are not really escaping tags, you are closing tags.

In most situations, closing tags is not necessary, as the parser will happily ignore any possible errors. You can just inject your img payload at the beginning, and it will work (there are a few exceptions, such as textarea, title, script, etc; but b and font are fine).

Regarding the filter, we can see that everything after = is cut off. You should investigate further by supplying more input, such as a=b (to check if it is only cut off inside a tag). You could also try to encode = as %3D.

If bypassing the = problem doesn't work, you should try a payload that doesn't require it. A simple example would be <script>alert(1)</script>.


Microwave is not secure physically, but then again no Layer 1 network is secure (modulo physical security like burying, hardened cables, thick walls, and armed guards).  Wireless, particularly through public airspace makes physical security a non-starter, so we have to move up the stack instead.

You enable security on top by using IPSec for Layer 3 (Network), TLS with AEAD for Layer 4 (Transport).  Other options are possible.

I would treat the microwave network like the Internet in that is untrusted and anything you put on it is assumed to be readable as sent.  This is pretty much what the white paper is advising as well.

For example you can achieve message integrity and confidentiality on an untrusted physical network by using TLS with AEAD cipher suites like TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (or many others).


the state of ASLR, PIE, SSP on Debian in 2018?

you can check if a binary is compiled with

PIE
stack protection
fortify source
RO relocations
Immediate binding

by using hardening-check. E.g. hardening-check $(which sshd)
Package devscripts contains the hardening-check

On Debian testing i get the following output:

root@root:~# hardening-check $(which sshd)
/usr/sbin/sshd
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes (some protected funcions found)
Read-only relocations: yes
Immediate binding: yes

See the following answer on stackexchange