How could disabling 'Hide File Extensions' in Windows make a system more secure?

Consider a file named doubleclick.pdf.bat.  If "Hide extensions" is enabled, then this will be shown in File Explorer as "doubleclick.pdf".  You, the user, might go ahead and double click on it, because it's just a PDF, right?  It'll load up in Acrobat if you do that, right?  When, in truth, it's a batch file, and whatever commands it contains will run when you double click on it.

That's why "Hide extensions for known file types" is a stupid move in Security terms.  It allows an attacker to create wolf files that look like sheep.


It sounds like Qualys is probably your preferred option: ongoing and repeated vulnerability scanning provides a long-term security blanket which will comfort your customers.

That being said, you should understand the difference between vulnerability scanning and a targeted security audit (often "pentest").

Vulnerability scanning will make sure that your infrastructure is, and stays, secure.  It will detect when you the web server software you're using suddenly becomes vulnerable because someone released a new attack against it.  It will detect if your server starts offering FTP to the world.  It will notice if certain known vulnerable configurations of the web server show up.  What it won't do is provide any real insight into the security of your application.

That's what a pentest does.  The pentester will look at your application with experienced eyes and specialized tools, and try to discover if you made mistakes when you wrote the application that an attacker could capitalize upon.  They'll also look at the same sort of "vulnerability scan" things, but the real value-add is to have a human think things through.  People can make connections that computers can't, recognize patterns that indicate subtle problems.

So in an ideal world, you'd have your application pentested at the start, and again whenever you make major code changes to it.  And you'd also have Qualys (or an equivalent, of course) run regular vulnerability scans to look out for all the simple, straightforward stuff that regularly bites people in the posterior.

If you're just checking a checkbox, though, that's more money and effort than you're looking to spend.  Go with the regular vulnerability scanning, you'll get the seal of approval to show people and you'll get helpful defense against the "low hanging fruit" - easy for attackers to find, usually easy to fix.


Is suggesting a correct url in a 404 page bad practice?

If Bob is trying to type products and mistypes product, he already knows there's a URL in the website for products and so you're not telling him anything he doesn't know. If you don't suggest URLs that shouldn't be public, you won't have any issues.
Why use a 404 message though, and not do an immediate redirect?


Preventing License protection circumvention in Java software

Not much, really.
When the attacker has access to the code, he can modify it to his heart's contents.
You can make it more difficult, by using code obfuscation for example. But you cannot render it impossible.

You could make the code connect to a server via the internet to verify it's integrity, but the attacker could re-engineer the code to call on his own server, too. (And it will hinder any legitimate users whose connections are down...).

So you have to prevent the attacker from having access to the code.
Assuming your user has a reliable internet connection, this could be done by offering your code as a service (SaaS).


Can a signed downloaded file be securely verified if you only control the private key and the download/verification algorithm?

No, your update process is flawed, and anybody trying to comprimise it will succeed.

I assume you are not using TLS/HTTPS, as you don't mentioned them in your question.

That's why:

Your public key is to be obtained from the Internet

This allows the attacker to intercept the connection and provide a tampered public key. All your verification process was already defeated.
Your zip is downloaded and verified using a possibly tampered key

As soon as the file gets downloaded it will be checked against the public key (now tampered). The attacker has already compromised the public key, and can create a new zip with a malicious payload and sign it with the generated key. Your program will happily accept it.

At this moment, the malicious payload gets executed with root access. Game over.

A (somewhat) safer approach is this:

Use SSL/TLS

This makes harder to intercept and tamper with the files over the internet.
Use certificate pining

It makes even harder to tamper the files, as a self signed or unrecognized CA will not be accepted.
Put the public key on your updater

This way it will not be easily fooled into accepting a forged update package.
Protect the updater

Your device must not allow access to the memory or the contents of the filesystem where the updater is installed. If you fail at this, the public key inside it could be changed.


Can someone send a text to a phone and make it appear on another person's phone text message?

The origin of the text could be an application that has the privilege of sending SMS from the owner of the phone that it's running on and reading the phone's contacts. I suggest looking through applications on the phone in the systems menu and determining what the privileges allowed for each app is, especially newly downloaded or newly upgraded apps.

If you find an offending app with privileges that you don't want it to have, either uninstall it or revoke the privileges you don't want it to have and be more careful next time when installing outside applications on your mobile device. Always read the list of permissions that an app is requesting on installation AND when upgrading.


What can cause a changed ssh fingerprint?

The correct assumption in this case is that you are connecting to a different server.

Maybe a MitM attack or
maybe your DNS is spoofed or
maybe your data center has just removed your machine for a second because they got a call from the government and you are accidentally trying to connect to their "server unreachable" catchall machine or
maybe your server has crashed under the sudden load and the aforementioned holds or ...

There are plenty of reasons you might be connecting to the wrong machine and you should definitely not proceed.
There are a couple of harmless reasons as well, false positives that make people sometimes connect anyway.
False positives I can think of right now:

The server has removed an old ciphersuite which it doesn't want to support anymore.
The server IP has changed and you have "CheckHostIP yes" in your config (default on many systems).
You have connected to the same server using a different hostname (think about something like gitlab) since the default ciphersuites have changed. (This is really obscure but I have run into it.)
The server has multiple SSH servers installed, and you're connecting to the same machine running a different SSH server (e.g., due to improperly configured startup behavior), which has its own separate keys.

Do note that as described here public key authentication prevents MitM attacks. It does of course not prevent you from simply logging into the wrong machine and then typing in your sudo password. So caution is still required.


Company can tell if new and old passwords are too similar. Is there a security problem?

Usually, when users change their password on a system, they're required to input their old password as well, along with the new password.

Now, this old password is hashed and checked against the hash stored in the machine(password is not stored in cleartext). If the hashes match, then the system proceeds to compare the old password and new password. If it finds that the 2 passwords are too similar, then it throws an error, informing the user about the same.

In case the passwords are sufficiently different according to the system logic, then the new password is hashed and this new hash value is stored in the system, hence successfully changing the user's password.

In case the users are NOT required to input their old password, I'd recommend you better check with your IT support team, and raise a concern with the system owner...

UPDATE:
As pointed out in the comments, there's one more way to get around this issue without asking for user's old password. When the user enters the new password, the system generates the variations of the new password entered, hashes each one of them, and compares each hash against the old password's hash. If any of the hash matches, it throws an error. Else, it successfully changes the password.


Is it unsafe to show message that username/account does not exist at login?

This is a consideration between security and usability, and therefore there is not really a right answer here. So here follows my opinion.

If you can keep usernames secret, then do so. In this case there is no way to figure out whether a username exists, and the login reacts the same whether a user exists or not. Note that this also means taking the same amount of time to return an error message.

This behavior may not be possible. For example if users can register themselves and choose their own username, you have to notify them when a username already exists in the system. If this is the case, make the login as easy to use as possible by providing the most detailed error message. If someone can figure out whether a user exists using the registration function, there is no use in hiding this at the login.


What is the risk of allowing users to change Windows 10 wallpaper?

Purely from a risk perspective:

The risk posed by an image file containing a payload of malicious code is not changed by the fact that you allow users to change their desktop wallpaper.

I mean, if it's got a nasty bit of code in it, then opening the file in paint or even generating the thumbnail view in explorer would execute the code too.

At worst you may be increasing the likelihood, because your users might be allowed to grab wallpapers from the web and use them.


You aren't hacked.

Well, not by this link anyway.

I opened the link you provided on a cloud instance and proxied the connection through Burp Suite so I could track exactly what happened with the redirects.

Turns out it is a grabify.link link. Grabify offers url shortening and provides some level of detailed information about who follows the link. This includes IP address, user-agent header, hostname, and time the link was followed. This is all standard metadata that gets sent every time you send traffic anyway. At this point the person knows at least your IP address and the type of operating system/browser you are using (unless you modified your user-agent already, which many do for privacy reasons anyway). If you have open ports/ listening services on your router, there is a good chance they will try attacking these if they are malicious.

The bad news:
They have any info they can glean from your IP, hostname, and user-agent header. This includes your cable provider since your cable provider owns the netblock you are in.

The good news:
They can't do much with this alone. They can scare you by pretending to have hacked you, but by this link alone they haven't gained access to your network/phone.

What to do now:

If you have a dynamic IP from your ISP (most do), release and renew your DHCP lease. This will change your IP address, and they will no longer know how to find your router. Sometimes you can do this in your router, some ISPs you need to call them and say you want to release/renew your DHCP lease. You can verify this worked by googling 'what is my IP' before and after the release/renew.
Check what ports are open and what services are listening on the router.

This is easiest to do on a linux machine, but can also be done on
   Windows and Mac by getting the nmap tool. For reference, this is
   the command I use on linux to scan my own public IP address when I want to see
   what ports I have exposed:

dig +short myip.opendns.com @resolver1.opendns.com | xargs nmap -p0-

This gets your public IP address and scans all of it's ports. If this looks strange to you, I would google around for how to scan you public IP, or search other answers. This is not the most standard way of finding and scanning your public IP but is efficient on linux, especially when the first half of the command is aliased to whatismyip.

Bottom line:

You are probably safe.. for now.
If every one of your ports on the WAN side of your router is closed, you're fine. If you release/renew your DHCP lease through your ISP, you're extra fine. If you have ports open/ services listening on the WAN side, definitely get new DHCP lease, as the person can now sit back and try to find vulnerabilities in them, and possibly hack you from there. If you happen to be an unfortunate soul with a static public IP (unlikely), buckle down and figure out how to best secure your router, because this person knows its address now.


How effective is the ProxyGambit at allowing access to the internet without revealing true location and IP?

From the ProxyGambit website:

  This is an insecure, bare bones proof of concept. The fragmentation of data through alternate mediums is a useful and effective concept and those interested in privacy, anonymization, or deanonymization should explore this area further. Entropy is both gained and lost with these methods and many risks are involved when deploying any system of this nature.

It is not meant to be used as-is, but as a starting point for further research. It does not bring any new ideas to the table and in fact does not even use existing secrecy techniques for wireless devices, such as spread spectrum communication to provide LPI/LPD (Low Probability of Interception/Detection).


Do public keys make Kerberos more secure (RFC4556)?

From RFC4556 :

  In the AS exchange, the KDC reply contains the ticket session key,
  among other items, that is encrypted using a key (the AS reply key)
  shared between the client and the KDC.  The AS reply key is typically
  derived from the client's password for human users.  Therefore, for
  human users, the attack resistance strength of the Kerberos protocol
  is no stronger than the strength of their passwords.

Therefore PKI extension is supposed to improve security of this initial Authentication Service exchange.


Embedded systems are usually on a plain of their own due to them being highly customized to the specified needs subject to the use case scenarios. It really depends on how the system is going to be used and how the system is built.

For example, if you're using Wind River Linux on an embedded system, there is no single use case / misuse case that we can plan for considering it's going to be a custom build depending on the customers needs and as such, there is only so much we can do. You need to define your requirements and then define cases in which you can defeat the security requirements (Misuse cases). From there you can dictate attack vectors and start pen testing.


How can javascript files represent a flash-based XSS vulnerability?

Flash applications can run JavaScript code in the context of the page that they're embedded in. Flash objects can also take external input, e.g. via the URL or flash parameters, or through a scripting API via JavaScript.

Together, a vulnerable swf file can be used to perform XSS on the site that hosts the swf file. For example, see
https://gist.github.com/cure53/df34ea68c26441f3ae98f821ba1feb9c

Based on your error message, I guess that the specific vulnerability was disclosed by this report:
https://hackerone.com/reports/299112 (currently with limited visibility in the details). According to the report, the bug was reported 4 months ago. If you really want to know the exact details, you can look up the changes from the past four months at https://github.com/mediaelement/mediaelement


What are the reasons that would encourage deploying authenticated boot in the system rather than secure boot?

Because the device owner owns the device, and often owners are developers. See also: people interested in "rooting" / "jailbreaking" their mobile devices.

Secure Boot is currently largely deployed, but in detail you might have some options to control the boot.

Consider for example TPM-based full disk encryption (1, 2) where the system won't necessarily refuse booting a different kernel (e.g. a recovery suite), but simply the TPM won't release the key(s) unless the boot environment is secure, so you can't snatch the key from the recovery toys. This falls in the middle of your question

Another great example is the Android ecosystem. Android has a true Secure Boot implementation where you can't boot or flash software that is not signed by the vendor. For example, a number of Nokia devices (manufactured by HMD) can't be unlocked. Why did I use bold?

Because in the Android world there are a number of ways to actively disable Secure Boot, which then becomes an optional, yet recommended, feature. As the owner, you can disable Secure Boot and install your own kernel. You will have full control over the device, and will even be able to experiment new technologies with your own device.

The goal of Secure Authenticated Boot is to provide a sane environment to applications, e.g. banking applications. If you unlock the bootloader of your device to run untrusted (e.g. rooted) software, your bank will be particularly mad and could refuse to interact with you through their mobile application because the system is not certified to their security standards.

As soon as you can revert the Authenticated into Secure boot, everything will revert back to the "trust zone".

Note that, as a security feature, most Android devices require wiping the encryption keys of storage when the bootloader security state is changed. This happens to protect the data, especially if an attacker with physical access to the device wants to exfiltrate data without user's consent (or if the user is unavailable/dead/etc) by flashing a recovery solution.

  In my point of view, it makes more sense (from security point of view) to deploy the secure boot.

Points of view are always relative. In my point of view (security point of view), switchable Secure Boot is the best option. I could choose to deploy SB to my old grandparent's phone and keep it disabled for myself.

On the counterside, consider devices physically given to third parties, like POS/cash, kiosks etc. Of course, we both want Secure Boot to prevent unauthorized third parties to mess with the software and steal financial information, or create duplicate transactions.

All depends on the effective point of view. There is no "generic" security point of view

  Any recommendation of reading about Trusted Computing and secure boot?

This article from the FSF seems outdated but highlights some points. Outdated because it ages from the Windows 8 era. Following is my comment.

The problem with secure computing environment, which today happens with gaming consoles, but not (yet) with mobile phones, is market barriers. It's not a real problem for the final user, but trusted computing could be leveraged in the future to create walled gardens where software vendors may be kept out.

The "app marketplaces" concentrate the offer of software applications. If a marketplace has oligopoly (e.g. Google) or monopoly (e.g. Apple), then they have power to choose who can deploy their software, ask for money, exclude certain competitors or certain parties for political reasons. This was especially true in the age where "ipa" applications could be sideloaded only via jailbreaking.

Today, no console natively allows to run "homebrew" games. Regardless of software piracy, homebrewing means the ability for a small start up born in a garage to deploy software to the martket, and not be forced to pay exhorbitant fees (e.g. 30% commission, along with Gov taxes) to the app store owner.


user account management: is it acceptable to keep an account locked after the password is already reset

This depends on why the account was locked in the first place.

If the account was locked due to too many failed login attempts and the password reset procedure is also used to "recover" forgotten passwords (as in, the 'forgot password' link on the login screen sends the user into the password reset procedure), then it serves no purpose at all to keep the account locked after the password was reset successfully.

On the other hand, if the account was locked for administrative reasons (for example, the user got a temporary ban due to misconduct), then a password reset should definitely not unlock the account.

And there are many other situations somewhere in-between.


Well.. that's quite a broad question, but, let me see what I can uncover for you. Let's start with your questions:

Some services may even have that specified on the API level, for example a public service with some internal API calls (is that a bad idea?).

I'm not sure I understand what is being asked here. When you say "internal API call", I am assuming that you are referring to a private service that the public API is accessing. This is indeed "ok", assuming that the internal service is behind a strict firewall.

How should the infrastructure interconnecting the services reflect the security policies? Are there any standard approaches to this?

Let's start with the creation of a new service. I highly recommend viewing this book, especially for access controls. Essentially, a newly created service or subject should assume the following:

A secure default policy should be applied to any newly created subject
The attributes of the system should not be expressed in terms that can easily be forged such as an IP address.
A user ID or service ID should remain permanently assigned to a service/subject

Once created, the service will then need to communicate with your internal services. In terms of security and policy, this is rather difficult to answer since it depends on what you choose for transfer protocols / messaging / etc...  For example, using an internal architecture such as ESB. Here are a few articles to outline utilizing ESB:

Intel's, "SOA? ESB? What is all this?"
Mulesoft's ESB
JBoss ESB

and a few security focused articles outlining SOA ESB:

this article.
NetworkWorld's Article

However, I do know that amazon does not use ESB via this article, though I did find a few articles that may help as well:

Amazon's "database" solutions
General SOA Security

Again, the security policies will reflect what the transfer protocol / messaging protocol, etc for service to service. For example, services communicating via proprietary ports (all behind a firewall).

Hope something in there can help!


Failure on correct credentials with the consecutive success?

Outside of the obvious flaws in that it will increase communication overhead and that it will piss off users, how long do you think it will take before everyone realizes what's going on? My guess is somewhere between immediately and almost immediately.

And once it's known that your service is rejecting the first login attempt, what stops hackers from just running each hacked password twice? Or thrice?


Should I password protect all my archives from cloud?

"The Cloud" is marketing speak for "Other People's Servers". I will use that term for the rest of this post.

When you store your data on other people's servers, those people are technically capable to look at your files and also show them to anyone who asks.  Whether or not they are allowed to look at them and/or let others look at them should be described in their privacy policy which you should be able to find easily on their website (when you can't find it easily or would need a lawyer to translate it for you: that's a big red flag). Also, some of these people prioritize your convenience over your security and might be easily convinced that someone else is you (remember those mass releases of private photos of celebrities a while ago - the images were mostly obtained from other people's servers through guessing passwords and security questions). Keep in mind that most people who let you store your data on their servers will allow government officials to look at your files when they ask.

When you want to store files on other people's servers, putting them into encrypted ("password protected") archives before you upload them is certainly not a bad idea (just make sure it is proper encryption. The standard ZIP encryption, for example, is very weak. I recommend the 7z format). But you might miss out on some convenience features other people's servers might provide when they have access to unencrypted files.

An alternative to storing data on other people's servers is storing your data on your own servers. There are quite affordable consumer-grade NAS (network attached storage) servers available which you can keep on your home network. When you want more physical distance between your computer and your backups (for example in case of a fire or burglary), you can also rent a server in other peoples network centers and install a solution like OwnCloud on it. This gives you more control over your files because you have more control over the environment it is stored on, but remember that it still runs on other people's servers: When you don't control physical access to a server, it is not your server.


How to delete one exe file that is probably malware?

Malware files by themselves are not special in any way, they're just like any other file albeit with a malicious purpose.

So, you can simply delete it as you would any other file. If for some reason you feel that someone (yourself included) might go digging through your computers recycle bin, you can also empty it to prevent accidental retrieval.


Is OpenPGP insecure if it only supports PCKS#1 v1.5?

As you may have noticed, section 11.3 of RFC4880 enumerates the legal packet compositions. In practice, you will observe that the signed payload is embedded in the encrypted message, so you can only check the signature after decrypting the message.

Regarding other matters, your statement "OpenPGP is considered secure" is wrong under some circumstances.
OpenPGP is, regarding many aspects, not secure against oracle attacks (mainly because of the lack of authenticated encryption scheme) and should probably not be used in automated decryption procedures unless you are a crypto expert knowing how to appropriately mitigate all of the possible information leaks. This statement is supported by many OpenPGP developers and this risk is clearly documented by some of them (e.g. End-to-end team).

For what it worths, next CT-RSA conference will host a talk about some new OpenPGP CCA vulnerabilities that were found in many OpenPGP implementations : http://www.rsaconference.com/events/us15/agenda/sessions/1761/chosen-ciphertext-attacks-in-theory-and-practice

edit:typo


What is the main function of xp_cmdshell in SQL Server and what are its related security issues?

It allows to run commands from the SQL shell provided by MS SQL Server. Meaning you can pass commands to be executed by the operating system. Attackers use these to gain complete access to the underlying operating system, rather than just the database and its data.


What type of permanent damage could be done to my computer through remote access (TeamViewer)?

On some CRT monitors there was a relay that was engaged when changing screen mode.  By changing screen mode repeatedly very fast, it was possible to destroy this relay.

Apparently some modern monitors can be wrecked by forcing them into invalid screen modes, but they must be pretty rubbish monitors.

Someone has mentioned flashing the BIOS to wreck that.

The microcode on some CPUs can be amended: wreck the CPU.

If it is a laptop, it may be possible to wreck the battery by reprogramming it: http://www.pcworld.com/article/236875/batteries_go_boom.html

With flash memory based SSDs or USB drives, re-write the same part of memory over and over to have it reach its end of life sooner.

On a cheap hard drive, forcing the stepper motor to push the drive heads fully one way beyond the end of the drive and then step back, repeatedly, could knock the heads out of alignment.  I've known drives where the heads could get stuck if sent beyond their proper range (Tulip brand PCs in the 1990s).

I also wonder if you could change any BIOS settings such that the RAM or CPU or even GPU could be damaged, by overclocking or changing the board voltages.

Cook the GPU by driving it hard after over-riding its automatic temperature control.  Ditto for the CPU.

Change BIOS settings to turn off the CPU fan then drive the CPU hard enough to cook it.


Why do services like Twitter have tokens and secrets for 3rd party apps?

One provides the identity, the other provides authentication.  Generally, the idea is that the identity can be given out to clients of the third party, but the secret is used for communication between the third party and the server.  The access token allows them to know which account it is associated with.  It's not really any different from having a username and a password.  I can tell you to send bob@mail.com an e-mail without you knowing Bob's password.  I'm not sure if this is specifically how Twitter handles it, but it's a fairly common situation for the application to have an identifier and a secret.


Unidirectional continuous data transfer to an air-gapped computer

I've seen this implemented many times in secure environments:
Simply connect the two computers via optical fiber and disconnect one side of the fiber.
That guarantees your one-way connect.
Protocol wise, the connection uses UDP protocol with a:

Start-Block
Data-Block
Stop-Block
Checksum-Block

Typically the Start and Stop are whole files, not chunks.
The Receiver simply checksums the data and compares with the checksum sent. If it matches, you're done. If not, the receiver indicates an error that has to be manually checked with the User having to manually re-send because there is no automated feedback.
This simplistic approach works quite well because with a direct fiber one-to-one connect, classic concerns about UDP mostly don't happen.

Order is guaranteed because it's completely sequential.
Reliability while not assured, is extremely high without network contention.
Verification only requires a simple checksum.

Some systems opted for multiple retransmissions as a simplistic error correction but errors are rare with a direct connect.


Which attributes of a X509v3 certificate are never really used?

Take care that the set of possible extensions is, by definition, not bounded (at least not practically; there is an internal limit a bit of about 1282255). There are standard extensions which are described in the X.509 standard, but there could be a lot more elsewhere. In particular, Microsoft's implementations (e.g. AD Certificate Services) tend to use a few Microsoft-specific extensions (such as an extension which designates the "certificate template" which was used to issue a given certificate).

Among the extensions described in RFC 5280 (which is the standard for "X.509 on the Internet"), the following are rarely used in practice:

Policy Mappings: people rarely get policies right anyway, and to use mappings meaningfully you have to understand how certificate policies work.
Issuer Alternative Names: this is not a very useful extension, since name chaining in a certificate path uses Distinguished Names, so there is little reason to give extra names to the issuer (if extra names are needed for an entity, they will be as Subject Alternative Names in the certificate for that entity).
Name Constraints: support from existing implementations is, let's say, a bit lacking in reliability. Also, the semantics are convoluted and contrived, so even if someone says that they implemented it, you cannot be sure that they implemented it properly and it is hard to test. Thus, nobody really uses them.
Policy Constraints and Inhibit anyPolicy: same reasons as for policy mappings.
Subject Directory Attributes: too new, too broad in scope.

All other standard extensions are commonly used (not always used, but common enough). However, some features of these extensions are rarely used, including indirect CRL (where the CRL issuer is not the CA), CRL scopes which do not cover all revocation reasons, X.400 addresses,...


Is there a dictionary of visibly similar Unicode characters for Spam processing?

I would add to my spam classification algorithm something that detects multiple encodings in the same word/sentence.  E.g., lαѕт having a Latin l, greek/coptic alpha, cyrillic dze, cyrillic te seems very suspicious.  A very quick and dirty thing in python could be done using unicodedata.  That is

>>> unicode_str = u"""мy вυddy'ѕ мoм мαĸeѕ $74/нoυr oɴ тнe lαpтop. ѕнe нαѕ
вeeɴ lαιd oғғ ғor ѕeveɴ мoɴтнѕ вυт lαѕт мoɴтн нer pαy cнecĸ wαѕ $19420 jυѕт
worĸιɴɢ oɴ тнe lαpтop ғor α ғew нoυrѕ. нere'ѕ тнe ѕιтe тo reαd мore something.com"""

>>> import unicodedata
>>> for uc in unicode_str:
        print uc, unicodedata.name(uc).split(' ')[0], unicodedata.category(uc)
м CYRILLIC Ll
y LATIN Ll
  SPACE Zs
в CYRILLIC Ll
υ GREEK Ll
d LATIN Ll
d LATIN Ll
y LATIN Ll
' APOSTROPHE Po
ѕ CYRILLIC Ll
(...)

Where "Ll means lowercase letter" and we only use the first part of the unicode name for letters to get its category.  So then we can do something like

>>> def count_letter_encodings(unicode_str):
        unicode_block_set = set()
        for uc in unicode_str:
            category = unicodedata.category(uc)
            if category[0] == 'L':
                unicode_block = unicodedata.name(uc).split(' ')[0]
                if unicode_block not in unicode_block_set:
                    unicode_block_set.add(unicode_block)
        return len(unicode_block_set)

>>> map(count_letter_encodings, unicode_str.split(' '))
[2, 3, 2, 3, 3, 1, 2, 3, 2, 2, 2, 2, 2, 2, 2, 2, 2, 3, 2, 2, 2, 2, 3, 0, 3, 2, 1, 2, 3, 2, 1, 2, 3, 2, 2, 3, 2, 2, 2, 1]

The fact that there are several words with 3 different letter encodings is highly suspicious (even two is suspicious).  As well as other suspicious things; e.g., the soft-hyphens alternated by one character (codepoint 0xad) in the .com.

Pulling some brief foreign text samples off the web, you find that most of the time words should only have one encoding:

>>> greek_text = u'Ελληνας ϰαὶ δὴ ϰαὶ γράμματα'
>>> spanish_text = u'¿Cómo estas? Espero que todo esté bien. Hace bastantes años que estoy'
>>> russian_text = u'Все люди рождаются свободными и равными в своем достоинстве и правах. Они наделены'
>>> for text in (greek_text, spanish_text, russian_text):
        print map(count_letter_encodings, text.split(' '))
[1, 1, 1, 1, 1]
[1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
[1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]

Obviously, you would have to thoroughly test with machine learning as there may be benign circumstances where encodings are mixed, but this could be useful input to your spam classifier that's trained on a large dataset.


Mail address spoofing : how to protect myself

To stop others from sending emails in your name you can use SPF. This is a DNS-record that publishes all IP-adresses that are allowed to send mail from that domain.

You can also use DKIM to sign a message with a private key, the public key is published in a DNS-record and the receiving server can verify with that key if it was really you who send it.

By implementing both SPF and DKIM you should be able to stop other people impersonating your email-address.

To keep track of when mail delivery fails you can use DMARC. This can be configured as to what a mail-server should do when the SPF or DKIM verification fails and also what email-address to send a report to.


Standards for physical Access Control systems

So when it comes to security standards for physical security, I would recommend looking over the Department of Defense. Here's a relatively recent posting, but if you've ever spoken with anyone in their IT, they've got literally millions invested in the R&D behind security both physical and IT. Here's a (rather dry) read on the subject. I'd specifically recommend Enclosure 4: Physical security planning.

http://www.dtic.mil/whs/directives/corres/pdf/510076m.pdf


Do not trust all intermediate certificates

Your trust store should contain the certificates you trust. If you trust only a single intermediate CA, and not its root, you should include the intermediate CA's certificate and not the root's.

Once a chain of trust can be built to a certificate in your trust store, it doesn't matter if that certificate was issued by another CA or not.


How to protect certificates and keys in peer to peer application

However, I've done some rudimentary research on my own, and I cannot wrap my head around the question, is having a keystore and a truststore on the (classloader) directory of my application a security vulnerability? Could it ever be one?

I am aware that keystore stores the private and public key of the server, and truststore stores the public key of the server, which it verifies & uses when contacting the server. How can I protect my keystore's and truststore's certificate password, when they must be on the application's directory? Does it need to be protected, even?

Actually, the truststore contains a certificate (or several, one of) which is used to validate the server's certificate or (in general) chain. Normally this is a cert of a CA which issued the server cert directly or (now more common) indirectly e.g. root CA (cert in truststore) issued cert for intermediate CA (in handshake) which issued cert for server (ditto). Using a self-signed cert is a special case where the server cert is also its root, and thus put in the client's truststore.
This information is indeed vital to security. If an attacker can steal your keystore data, they can impersonate you to others, or if you use (or used) ciphersuites in 1.2 that DON'T support forward secrecy (i.e. 'plain RSA' suites/keyexchange) they can decrypt eavesdropped connections to you. If they can alter your truststore data, they can impersonate others to you.
Whether and how this is a risk depends on what possible attacks and attackers you must defend against, or as usually phrased here, "what is your threat model?" If your endpoints are themselves secure, and the application containing the security data can be deployed to them securely, you're fine. If attackers can run things on your system(s) or otherwise access your file(s) it gets more complicated, and there are no generic or very easy answers; in general most of the answers that actually work involve hardware, either custom or platform, and thus aren't cross-platform and often aren't cheap. See for examples
Where to store a server side encryption key?
https://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi
https://stackoverflow.com/questions/3038608/how-do-i-store-a-java-keystore-password

What encryption algorithm should my keystore use? I'm heading for really strong encryption, future proofing as much as possible along with keeping up as much backwards compatibility as I can without reducing the application's security.

Don't use JKS, which was designed deliberately weak because of US export restrictions back in the 1990s and was the default through j8; higher versions default to PKCS12, though keytool still accepts JKS and JCEKS automatically. (It warns about the better standardness of PKCS12, but not the better security.)
Java's version of PKCS12 (like most) uses 3/3DES for privatekeys, which is what you should care about; (again like most) it 'encrypts' the certbag with RC2-40, which is very weak and basically useless because certs aren't secret. While not the theoretically strongest possible, 3/3DES is strong enough against any near-term conventional attack. What experts fear sometime vaguely-soon-ish is quantum attacks, but no one yet knows what the 'correct' solution for post-quantum crypto (PQC) is; the few experimental algorithms that exist now (1) aren't used for keystores (2) may well be changed, perhaps incompatibly (3) may turn out to have problems. If you really want, you could use PKCS12 and superencrypt the file with (some) PQC; BouncyCastle has a few options in a special provider, if you (can) use that. That way even if the PQC turns out to be useless you still have the 3DES, and if you need to change it you can just re-encrypt the file without needing to understand the contents.

Is there an issue with the certificates being self-signed considering I'm solely using them between peers of the same application?

Less so than otherwise. It does mean you can't use PKI to revoke them, but must have some other means, that works reliably -- unless you don't need revocation because all your endpoints are controlled, top to bottom, by people who never make mistakes or have the personal situation change (e.g. marry, divorce, get a job, lose a job, etc).

Considering I'm doing Java, do SSLSockets/SSLServerSockets create a "brand new session" for every new connection, as in, do they reuse the private or public key? Are private keys generated when making a handshake with a client?

SSL and TLS through 1.2 allows session resumption, which does an 'abbreviated' handshake that reuses the session 'master secret' from a previous connection's full handshake, as long as (in both senses) both endpoints have cached it. Most servers implement this and (AFAIK all) browsers use it extensively; Java JSSE implements it by default, although you can limit the number (size) or timeout. There is also a less-used option which stores a 'ticket' on the client only and uses that; see What are the differences between Session Ticket and Session ID based Session Resumption? SSL/TLS Session Resumption with Session Tickets and (my) https://crypto.stackexchange.com/questions/15209/compare-rfc-5246-sessionid-re-use-versus-rfc-5077-session-resumption . JSSE does not implement this. Either of these eliminates all the public-key crypto operations on the new session (when successful).
TLS 1.3 eliminates both of these and instead has a new mechanism which reuses the authentication but optionally does a new keyexchange (XXDHE); see my answer on the crypto.SX link above. This eliminates all or only some of the PKC (again when successful). In versions that implement TLS 1.3 (j11+) JSSE does implement this, apparently (per the debug log) only the with-XXDHE option, but there was at least one bug, see https://stackoverflow.com/questions/53913758/java-11-https-connection-fails-with-ssl-handshakeexception-while-using-jsoup .
For full handshakes in TLS 1.2 (and below) which use 'ephemeral' keyexchange (DHE or ECDHE in the ciphersuite), and for all full (non-PSK) handshakes in 1.3 as well as PSK handshakes that elect XXDHE (which as noted above Java does) both endpoints generate an ephemeral keypair used in the keyexchange. Otherwise not. (The 'export' ciphersuites in SSLv3 and older TLS could sometimes use a uncertificated keypair that might, or might not, be ephemeral, but those ciphersuites were obsoleted long ago, even before the older protocol versions that supported them.) If you are concerned because RSA keypair generation is expensive, don't be; DHE or ECDHE (XXDHE) keypair generation is cheap, at least in CPU; it does require some randomness, but SSL/TLS always requires a random nonce for the protocol, and also random IVs if you use a CBC-mode ciphersuite in 1.2 or 1.1, and I'm pretty sure JSSE reuses the RNG (SecureRandom).


Criteria for selecting fields and network protocols for fuzzing

I think you're going to often find that your criteria is constrained by several factors, which actually limit what you can test.

The tools you have access to, and the licences you're operating under (terms of service, DMCA, etc.) can limit the scope in some cases. Any fuzzing that requires destructive interfere with another user is probably out, as well as any which could be seen as an attack on a service provider.  So fuzzing a connection with a cloud service is somewhat risky.

Then you have local protocols like SSH, a web server, SMTP, etc. on a router/IoT device. Those services can be fuzzed with relatively low risk. There are many tools focused on web protocols so if your device has a web interface focusing on the OWASP top 10 may be a good starting point.

For more physical connections such as a JTAG or other hardware debug port, you may find some interesting unpublished functionality. If you have the adapters and the tools to debug JTAG that may be a good use of time.

Overall fuzzing is highly dependent on the target, the scope of the engagement, and the experience of the investigator.


I have used mod_auth_tkt, which uses a very similar scheme.
I would suggest very careful consideration before use of the SSL session key: the user (application) session, TCP/HTTPS connections, and the SSL session ID and key are all distinct things. They don't necessarily have the same lifetime.
Further, reusing or repurposing cryptographic material is usually frowned upon (though I can't say that's there's definitely something wrong with its use in a HMAC, the problem is determining the opposite).
In the case of a conventional browser/web app, this sort of scheme can have immediately evident problems, e.g. when browser tabs don't share state.
What you have authenticated is a browser "state", tying it to anything else (SSL state or IP address) is fraught. Tying to SSL Session ID is more common (though has a history of MSIE problems). One of the better ways to achieve this is through the use of client certificates, not trivial to implement and manage of course.
See this for many more considerations: https://www.owasp.org/index.php/Session_Management
and (now complete) RFC 6896 Secure Cookie Sessions (draft linked to in the accepted answer to the question you link to) has a section devoted to replay issues.


You can inject a stub in your target file, and make that this stub would be metamorphic and so as when it will be loaded into memory, your pe will have a lot of differentt signatures. But it's very long to create and to realize.


ISAAC pseudorandom stream - why is this considered strong crypto?

I decided not to use ChaCha for my purposes - /dev/random might already use it and I didn't want accidental correlation.

You might want to rethink that. Firstly, /dev/random is not the one using ChaCha20, /dev/urandom is. Secondly, there is no "accidental correlation" to worry about. You can safely use ChaCha20 multiple times and it will remain secure as long as the key:nonce tuples are all unique.

  Wherever I see it mentioned, I see it referred to as strong enough for crypto work. But I haven't seen who decided that, and looking at the implementation in C, it looks for all the world like someone picked arbitrary constants for shift operations and fiddled with add operations until they got something that had good statistical properties

ISAAC is considered secure simply because no one has broken it yet, and because analysis appears to indicate a solid and secure design. As for the rotation constants seeming arbitrary, you're right, they often are! That is often how people choose such constants. They try different values and see which ones have ideal diffusion characteristics. I'm not aware of any heuristics for choosing specific rotation constants for an arbitrary cipher. Even ChaCha20 and Salsa20 use constants that were chosen (in part) this way.

  The one paper I found that does any analysis promptly diagnoses a bunch of weak keys and proposes ISAAC+ - which no one seems to have discussed at all. A website for ISAAC says it's never been cracked, but given the lack of online discussion about it, maybe only two persons ever tried.

It's not weak keys that were found, but weak states, which are far more hypothetical and harder to generate. ISAAC+ is likely less researched because it is not an entirely new design, but a small tweak on the original design. Such tweaks do not always warrant a significant amount of new analysis.

  If it's great and unbroken after all this time, why isn't it a mainstay?

Simple: There are better, faster alternatives like ChaCha20. While it is true that there are no known practical attacks against ISAAC, it's really not that brilliant a design to warrant significant attention. It got some rudimentary cryptanalysis and cryptographers in general feel it is secure, but there is no compelling reason for it to be used, resulting in less attention from the cryptographic community.


Why aren't hardware R/W switches used to defend hard drives?

SATA has no separate wires for reading and writing so a pure hardware solution is not possible.

You actually have the same problem with Ethernet too: with Fast Ethernet you had separate Tx and Rx (Transmit and Receive) wires and thus could simply built a guaranteed passive network tap by not connecting the Tx lines. With Gigabit Ethernet this is no longer possible so network tapping at this speed will be controlled by software which makes it harder to guarantee that the tap stays passive all the time.


Probable hack: email "from" names being corrupted

It might be a browser extension. Have you checked those for anything unusual?


How confident is MIME blacklisting on a proxy server?

On older browsers, the answer is yes, this kind of attack is possible, due to some browsers' support for MIME content-type sniffing.  You can Google for content-sniffing attacks and you'll find a lot more details.

To defend against it, set the header X-Content-Type-Options: nosniff (only supported on IE8 and IE9, I think), and make sure to serve a valid content-type in the Content-Type: header.  Those will disable content-type sniffing on many browsers (on IE8, IE9, and non-IE browsers, at least).

See also
Using file extension and MIME type (as output by file -i -b) combination to determine unsafe files?,
Does X-Content-Type-Options really prevent content sniffing attacks?,
What are the security risks of letting the users upload content to my site?,
How can I be protected from pictures vulnerabilities?,
Is it safe to serve any user uploaded file under only white-listed MIME content types?,
MIME sniffing protection,
Why should I restrict the content type of files be uploaded to my site?.

I also recommend that you serve user-uploaded content from a separate domain, to sandbox the user content and ensure it cannot tamper with your content.  For instance, you might host your content on www.example.com and host user-provided content on uploads.example.com.

Update: I just learned that setting the Content-Type and X-Content-Type-Options headers are not enough for security.  Apparently, Flash ignores the Content-Type header, which could allow loading a malicious SWF, which can then do everything you'd do with a XSS.  (Sigh, stupid Flash.)  Unfortunately, no amount of headers can stop this attack.  Consequently, it appears that the only safe solution is to host the user-uploaded content on a separate domain.


While there is some overhead in those calculations, this is generally not a problem as DDoS-attacks tend to exceed the network interface's capabilities before the RAM or CPU are overwhelmed with TLS-handshake calculations.

The calculations done for a regular, state of the art dynamic website delivered over HTTP do exceed the TLS handshake calculations by at least an order of magnitude. Thus, counting on the open TLS connections DDoS-ing a webserver seems somewhat superficial. Yes, there is some overhead, yes, it takes up ressources - but not enough to bring the machine(s) to a halt. Just actually making the machines deliver the content can be way worse.

Furthermore, this way DDoS amplification methods can not be utilized - attacking the network connection directly is more promising, from an attackers point of view.


isn't it a security gap if TLD hostname doesn't send the strict-transport-security header?

First off, it is apparently more complicated: A bit of testing reveals www.google.com will, apparently, only send the HSTS header if it sees a user agent string that indicates a modern browser. Without a user agent string, e.g. with curl -H https://www.google.com, you will not receive a HSTS header at all. In fact, the google search page will still work via http if it doesn't see a modern browser's user agent string.

Google obviously still wants to support plain http access to that page, and not force certain browsers to https. I'm not sure why, but they might want to support some old, broken clients which would actually recognise the HSTS header but would fail to connect due to a broken SSL/TLS implementation.

The security risk to google itself is actually zero (as there is no confidential data on the search page), though there is a small risk to the user that a search term is exposed.

Other google domains like mail. that are on the browser preload lists and therefore always secured in practice.

The reason that Google is rejecting reports for missing HSTS? That has nothing to do with wether Google thinks that it should be fixed. Bluntly put: They are working on HSTS and they already know that it is not there. It doesn't help them if people report what they already know, so they aren't going to hand out rewards for that.

They may still fix the problem in the future, but until then they don't want to deal with a lot of folks reporting the same thing over and over again (and demanding a reward).


What is preventing us from sniffing the mobile phone communication?

For telecommunications, check out GSM, CDMA, TDMA, and EDGE. The two competing protocols in the United States are GSM and CDMA. The resources linked below are lacking when it comes to CDMA, but using site:defcon.org and site:blackhat.com in your Google searches will turn up some presentations.

For interception of GSM, I refer you to a white paper Intercepting GSM traffic from the BlackHat conference:

Intercepting GSM traffic - Black Hat Briefing - Washington D.C., Feb 2008

  Abstract: This talk is about GSM security. We will explain the
  security, technology and protocols of a GSM network. We will further
  present a solution to build a GSM scanner for 900 USD. The second part
  of the talk reveals a practical solution to crack the GSM encryption
  A5/1.

The corresponding video of the presentation:

DeepSec 2007: Intercepting GSM traffic

Also a talk on cellular privacy and the Android platform:

DEFCON 19: Cellular Privacy: A Forensic Analysis of Android Network Traffic (w speaker)

and a whitepaper on the Lawful Interception for 3G and 4G Networks (though see first comment on this answer):

Lawful Interception for 3G and 4G Networks - White Paper by AQSACOM

  This document will first provide a brief description of the various
  evolutions of public  mobile networks that have been commercially
  deployed, followed by a discussion on the  evolution toward the newer
  “long term evolution” technologies.  We then discuss possible
  configurations for lawful interception of the evolving mobile
  networks, followed by descriptions of approaches to 3G / 4G
  interception solutions now available from Aqsacom.

And a SANS article on GSM security:

The GSM Standard: an overview of its security

Also note that smart phones typically just automatically connect to networks with SSIDs it remembers. Sniff the airwaves for beacons that it is sending out and set up an evil access point with a matching SSID. Launch a remote attack across the network or man in the middle the device and launch a client-side attack appropriate to the device.


How realistic and possible is this sort of attack

Allowing SSLv2 with weak ciphers exposes you to several potential attacks and is not worth the risk. If you only plan on using strong ciphers, is easy enough to restrict the SA VPN to only allowing SSLv3 and TLS1 with 168bit ciphers on the Configuration>Security tab.  You will even note that there is a warning on that page indicating known vulnerabilities with SSLv2.

One example MITM attack against SSLv2, during session negotiation an attacker can remove the strong ciphers from the available list in the conversation and force the server to negotiate with a weak one.  The rest of the traffic can be collected using a packet sniffer and decrypted later. The user would have no indication that this happened and 40 bit encryption can be decrypted in less than a day on today's hardware.

Unrelated to your question but since you mentioned it... you should also replace that factory supplied SSL certificate with one signed by a trusted CA.  Nessus should have also flagged that as an issue.


How can I verify that a root certificate is authentic?

Authenticity can be kind of checked if you search for the fingerprint online and find the certificate where you would expect it. But this is not foolproof because this might be a fake site which is just looking good and has a trustable host name. In any case you don't know the party personally and authenticity does not mean that the party can be trusted.

At the end you have to trust the vendor of your OS or browser that it is doing the right thing, because effectively you have no way to really verify it. But this kind of trust is not uncommon, i.e. you trust your supermarket that the food is edible and not expired or even poisoned, you trust your gas station that the gasoline is not dangerous for your car ... - i.e. you already trust others in security issues. And you hope that if this trust is no longer justified you will somehow be notified.

Trust can go wrong as can be seen in the Superfish affair where one trusted the vendor (Lenovo) to ship a trustable computer. But this computer contained a software to injects ads and additionally the software installed its own root certificate to man-in-the-middle connections in order to inject ads into https traffic too. This certificate was definitely authentic, but most people would not consider it trustable.


How does small dish satellite secure their signal?

Essentially, each subscriber has a key in their smart card. When a new subscriber is added or changes their service, a new group key is sent over the broadcast system, encrypted with that subscriber's key. The keys to actually decrypt individual programs are themselves encrypted with the group key for the set of services that program belongs to. Legitimate subscribers decrypt the program keys using the group keys, which they decrypt using their subscriber keys.

If someone changes their service, change messages are sent over the system. They're repeated at random intervals to make sure someone gets a new service even if their box was off or missed a signal and to make sure someone eventually gets a service removed if they stopped paying for it or request it be removed.

All of this takes place inside the smart card, a physically secure computing system. Typically, the smart cards can be reprogrammed, but the new programming must be signed. To upgrade smart cards, new programming is sent over the satellite and is signed so existing cards accept it. The service provider knows what smart card each subscriber has and can run multiple distinct security systems concurrently, provided everyone who wants to watch the same show, and is allowed to do so, winds up with the same key to decrypt the actual contents.

There are many ways to pirate cards, but typically a number of pirated cards are all clones of a single subscriber. The system is one-way, so it can't tell if a card has been duplicated. When a card is "hit', that means the operator figured out the card was duplicated (often by one such duplicated card falling into its hands). They then de-authorize that subscriber, shutting off all the pirates using that particular subscriber key.

The pirated cards may be smart enough to ignore the de-authorization. But even so, as soon as the group keys are changed, they'll stop working, since they no longer have any way to decrypt the group keys and thus no way to decrypt the keys needed to decrypt the programming.

Sometimes cards are also "hit" by the provider simply changing the logic in the card. The change can be minor, but enough so that the pirated cards become incompatible with the system. This can be either because the pirated cards reject the update and become incompatible because the protocol has changed or it can be because the pirated cards accept the update and cease to be pirated cards. This can affect every pirated card of a particular type in existence, even if they all use different accounts.


For every file format, a program meant to process is associated. For example, a PDF can be processed by a program capable of parsing pdf format. While processing each format, certain parsing and processing of data is involved. Malware is crafted to exploit the vulnerabilities of these processing programs. By assigning an extension, the file format is easily identified by the OS and the corresponding program capable of parsing it is fired up. Thus, vulnerabilities in widely used software make the users more vulnerable, like in case of Surtr family of malware exploited the vulnerability in MS Word.
Renaming an extension is a solution only until the corresponding program for which the file is crafted is not launched. For instance, a .pdf malware renamed as .txt is not harmful until the data is processed by a pdf reader (which malware targets).


Should ability to access login page after authentication be considered a security flaw?

This doesn't seem to be a vulnerability. Even if you would allow a user to log in multiple times on the same page, this doesn't imply any security flaws because the session and user management could still be secure. However, being logged in as multiple users is a design flaw. If you can login again as a logged in user, the panel should be redesigned to display your profile etc including a logout button instead of the login form.


Where to download OpenBSD release ISO's over HTTPS?

There is a file called SHA256 which contains the checksums. Technically you only need that file to be transmitted securely; you could get the ISO through any mean, and just verify the checksum. This would be as good as getting the whole file through HTTPS.

The OpenBSD people do not seem to maintain a public HTTPS web site with a copy of the SHA256 file. Also, HTTPS is as secure as the X.509 PKI model allows for, and OpenBSD folks seem to be somewhat queasy with regards to X.509 and the preinstalled CA in Web browsers (which is quite understandable); they seem to prefer the OpenPGP model. I think that in older days, the announcement for a new OpenBSD release was a PGP-signed email (sent to various places, including Usenet), which contained the digest for the main ISO -- thus realizing full ISO integrity relatively to a PGP public key. But I am not sure they are still doing that.

Otherwise you can order a physical, tangible CD set (or DVD). They are not expensive.


Discord itself is entirely server-based, as described in this Discord blog post. In other words, your client is always directly communicating with a Discord server, which then re-sends your data to other clients. That means any potential attacker will see the Discord server's IP and not yours.

However, that doesn't have to be the case for other online services, which you can link in your profile. When you join a server, other users, as well as bots and user-bots, in that server will gain access to the data in your Discord profile, which they can scrape and potentially use to track down your IP. You can see which services you have linked to your account by going to the User Settings and choosing the Connections category.

Your best course of action right now is staying calm. They might try to use the pressure to their advantage and try to direct you to a phishing site to get your Discord credentials or scan a login QR code. By just following an official Discord invite (the https://discord.gg/xxxxxx format), your credentials are safe.

Furthermore, the things you described do violate the Discord's Terms of Service in multitude of ways. You can report the server to Discord's Trust and Safety, as described in this support article.

After you're done with the report (since it requires you to get the server ID, which requires you to be present in the server), or immediately, if you're not planning on making a report, I recommend you to leave the server and report + block anyone trying to threaten/blackmail you afterwards. You're most likely not dealing with a nation-state or an organized crime group, just a group of kids having no better way to entertain themselves during the quarantine, and are safe to ignore their threats. After all, credible online threats can still be subject to prosecution and should things escalate even more, you can report them directly to the authorities.

Lastly, as a general advice, I'd highly recommend enabling two-factor authentication on Discord if you haven't done that already.


Logging in a user after password reset via link

From a security point of view, whether the "password reset" logs you in automatically or not is rather neutral. Neither behaviour is inherently more secure than the other. I suppose that most sites do what was simplest to implement on the server side.

A point to consider is that security is achieved as long as everybody cooperates; in particular, the principle of least surprise is of paramount importance. That principle, applied to security, means that trouble is afoot when things don't occur as the human user expects it. In this case, the human user may or may not expect to be logged in after a reset. Let's see what happens if the user is "surprised":

If the user expected to be logged in, and is not, then he may be somewhat irked by the necessity to enter his password again. However, consequences stop there. Notably, the requirement to have to enter the password a third time will not induce the user to choose a weaker but easier to type password, because, by definition, he was not aware of this third entry when he chose the password.
If the user did not expect to be logged in after a password reset, and still is logged in, then that user may simply not notice that he is logged in, and remain so. This contradicts the user control of open sessions (the reason why most sites have a prominent "logout" button).

In that sense, a (rather weak) case can be made against logging the user automatically on password reset: security consequences of an unnoticed login can be worse than consequences of an unexpected lack of automatic login.


We are developing customized malware for our customers to simulate APT (advanced persistent threats) within professional penetration tests. Disabling malware in our case has an important purpose: To prevent activities (e.g. infections) after the end of a project.

In case of malware in-the-wild the goal might be to prevent further access to other resources like web server. For example if the developer knows that the C&C servers won't be around at that future time anyway.

Highly professional malware with stealth capabilities might deactivate itself to prevent detection or to make a reverse engineering much harder. The attackers might want to get access and then steal a specific set of data or switch to another communication capability. The malware for the initial break-in shall stay unknown because the technique might be very valuable or the approach might reveal something about the source or targets.


Can hackers find secret tokens passed to HTTP GET requests?

You're relying on a principle called security through obscurity, which is generally frowned upon. There is a widely-accepted principle called Kerckhoffs's Principle which states:

  A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

An alternate, and more general, form of the principle is called Shannon's maxim:

  The enemy knows the system.

Essentially, this means that you should never rely on an obscurity mechanism to protect your system. You should assume that attackers know the code, and can discover any vulnerabilities like this.

As such, your access mechanism should involve proper authentication - e.g. entering a set of credentials that can be checked on the server side, using proper password hashing. This means that even if an attacker knows your code, he cannot exploit it.


By default, RDP connections are encrypted using the RC4 stream cipher, which is not considered secure anymore.

If possible you should tunnel your RDP session through TLS or set up an encrypted VPN between your RDP server and your workstation.


It's a bit unusual to publish a CSS file which the minify process failed on, and may be indicative of other issues (e.g. insufficient monitoring of the deployment process), but CSS files are used by end user browsers, so the content shouldn't be sensitive. At most, it might include styles which are applied to pages or controls which the current user doesn't have access to, but applications should not rely on styling for access control, so this should not cause problems in a sensibly designed application.


NIST recommends using a random IV for AES-GCM. As GCM is a variant of CTR mode, you should never reuse the same IV with the same key, or an attacker can recreate parts of the plaintext if he knows something about its structure.

Encrypting the IV does not add much, as any security protocol must keep data secret when only the key is secret. If disclosing anything but the key compromises the security, then the process is not secure. AES-GCM is proven to be secure, so encrypting the IV is redundant.


The most current documentation already posted (by the Trike team, anyway) is in the Help spreadsheet, which you can find here:

http://sourceforge.net/apps/trac/trike/browser/spreadsheet/trunk/docs/help/TrikeHelp.xlsx

I also have a very rough draft of the documentation for how to actually do the first half of the methodology using the spreadsheet.  I am running it by some of the people who use the tools already & expect to post it somewhere on http://www.octotrike.org/ sometime next week.  I will post/update here when I post there.

If you are in the San Francisco or Seattle area and are willing to take notes for more documentation, I am willing to show you how to do it.


Which symbols can I whitelist to remain safe against SQL injection, XSS, and all other injections attacks?

tl/dr: You simply can't protect other systems from malicious input.
  Protecting against injection attacks depends too strongly on the way
  in which the data is used.  The best you can do is try to prevent
  obvious malicious payloads from sneaking in, but even your proposed
  white list can leave severe vulnerabilities if the application on the
  other end isn't practicing proper security.

Unfortunately what you are trying to do is nearly impossible, because ultimately securing against injection attacks depends completely on the context (aka how the application is using the data).  To pick one random example, imagine someone reflects your input into an HTML page like this:

<script type="text/javascript">
var dataFromIlyaChernomordik=[DATA];
</script>

Note that the data is injected directly into javascript without any double quotes.  Unfortunately, the data that went into your site is:

eval(String.fromCharCode(97,108,101,114,116,40,39,72,73,39,41))

Which translates into:

eval("alert('HI')")

I'm sure you can see where this is going.  Using only A-Z0-9,.(), combined with a lack of proper input handling at destination, I can now inject arbitrary javascript.  Game over.

So let's get rid of everything but: A-Z0-9-:

Yeah, but that hyphen there - it looks dangerous, and it has a variety of possible meanings in bash.  Is it possible that someone might be using this input to build strings to execute in a command line?  Is it possible they might forget to escape the data properly?  If so, you should ditch the hyphen.  Spaces and a colon also might cause trouble if someone is using your data inside an eval command in a python script.

The point is, anything can be dangerous in the wrong context.  As a result the only way to properly secure a system against malicious user data is to understand the context in which the user input is being used.  The only input that might be safe in an unknown context is an empty string (but man you'll be in trouble if you accidentally use a null character instead of an empty string!)

In essence, you're attempting to build a WAF, and while those can play a role in providing security to web applications (which is already a very specific context - a WAF will by no means protect against everything), anyone who has done enough penetration testing has plenty of stories about circumventing a WAF because of oversights in its rules.

Can you try to filter out the most obvious malicious payloads?  Yes.  Can you stop all dangerous payloads in all contexts?  Definitely not.


What are possible security problems of enabling HTTP2?

HTTP/2 is a way more complex and new protocol than HTTP/1.x and thus bugs are at least initially more likely. In fact a simple search shows several implementation problems and also some new or updated attack vectors due to the changed design of HTTP/2.

  The WAF might not work with HTTP2 because it doesn't support the protocol

This is probably less of a problem. A WAF is usually either integrated into the HTTP stack of the server or is an active component with its own HTTP stack. Due to the way HTTP/2 is designed an implicit downgrade to HTTP/1.x will happen if the server or WAF does not support HTTP/2. This is also true for proxies and other active components.

It will be a problem for purely passive inspection as done in some Intrusion Detection Systems or firewalls. But a purely passive inspection has problems with inspection of TLS traffic anyway and HTTP/2 is only used together with TLS. If instead the passive inspection is augmented with SSL interception then usually a downgrade to HTTP/1.x will happen again unless the SSL interception explicitly or unknowingly forwards the ALPN TLS extension to the HTTP/2 server during SSL interception.


Is there a way to secure an API key on iOS?

The answer you linked, from 2013, is out of date. You can have secure enclave-backed Keychain private keys now. See Apple's article on how to store private keys in Keychain.

You will have to re-architect your API to use a public key scheme, but there is no way around this, since any fixed API key will require the key to be in memory at some point anyway.


Do we still refer to a threat as a threat once it has been realised?

You may be looking for 'breach'.  As described below, the original threat remains, a breach has occurred, and additional new unmitigated threats may exist where the attacker may be able to do additional damage now that they're inside.

Threat: the possibility that something could try to happen

Threat Actor: the person or other entity who will try to make the bad thing (threat) happen

Vulnerability: a hole in the design of the defenses that may allow a threat actor to cause a threat to happen

Asset: something of value

Exposure: an asset has been placed behind a vulnerability, thereby exposing the data to the threat

Exploit (n): the mechanism by which the threat actor will make use of the vulnerability to get to the exposed asset

Exploit (v): the act of using an exploit (n) to make use of a vulnerability to access the exposed asset

Breach(v): the successful act of exploiting a vulnerability. Breaching the defenses

Breach(n): the event during which a breach(v) occurred. A breach in the defenses.

incident: a detected breach or exposure. In some environments, a detected vulnerability, without an exposure

Mitigate: to reduce the severity of an actual or potential breach

Control something in place to mitigate, detect, or prevent a breach

Note that a threat that successfully breaches the security of some of your assets may not have successfully accessed all your assets, and may attempt to re-enter at a later time. Thus, you have a breach by an ongoing threat, with possibility of a wider or repeated breach, using one or more exploits to exploit one or more vulnerabilities that exposed one or more assets to the threat of a threat agent.


Microsoft Exchange: Email and attachment encrypting

There is little you can do. While encryption is supported every step of the way, the only part under your control is your client to your server.

To use encryption when sending from your server to other server, both servers have to support encryption and the receiver client server connection is completely out of your control.

You should disallow unencrypted connections to your server (from your clients). There is no reason not to.
You may refuse to connect to other servers without encryption, but this will cause e-mails not to be delivered to people, who use servers that don't support encryption.
There is no way you can force encryption between recipients server and client, that part is out of your control.

That is why end-to-end encryption (using third party tools such as enigmail) is much superior when communicating using e-mail. E-mail is inehrently insecure, because it has to support variety if legacy servers and clients.


What CPUs does the Spoiler attack affect?

Their whitepaper says "The leakage can be exploited by a
limited set of instructions, which is visible in all Intel generations starting from the 1
st generation of Intel Core processors,
independent of the OS and also works from within virtual machines and sandboxed environments"

In a table of results they show a Xeon CPU being vulnerable specifically Intel Xeon E5-2670v2 and Intel Xeon E5-2640v3


Why are passphrases protecting GPG / SSH private keys needed?

An encryption key is kept in memory for as long as it is being used. For disk encryption, the key is necessarily present in memory for the time the encrypted partition is mounted (for FDE, this is the entire uptime of the computer). Encrypting private keys ensures that the sensitive key material will only be available for very brief periods. The chances that a passive physical attack (one where integrity is not violated) will occur within the brief period that a private key encryption key is in memory is very small.
An arbitrary disk read vulnerability or DAC bypass may allow a malicious local process to read disk contents, potentially including SSH or GPG keys. Full disk encryption does not mitigate this, but key encryption does.
A malicious program that passively reads from your disk and does not set up a keylogger would be able to bypass FDE, but could not decrypt private keys if they are encrypted. In some cases, it won't set up a keylogger because it simply can't, for example if it does not have access to the X11 cookie.


If someone knows my wi-fi password, will he know what I am doing?

The answer is yes, he can see what you're doing on the internet when he is connected to your WiFi network.

The encryption protocol used is pretty much irrelevant. Whilst WPA2 will generate a unique session key for each client association, if the attacker captures this he can still decrypt your traffic. Even if the attacker doesn't capture it, he can forge a disassociation and capture the session key when you reconnect, revealing all of your subsequent traffic.

Once someone has your WiFi password, consider it to be the same as them having a LAN cable plugged directly into the router. The WiFi password offers no additional security beyond limiting access to the network itself.


What International laws should one in the InfoSec industry we be aware of?

The world is increasingly interconnected, and it is more and more common that actions by people in one country can affect people in other countries and be regulated by laws there.

Here is a brief sampling of some of the issues to consider.

A security researcher from Russia was detained while visiting the US by authorities for distributing free copyright circumvention software.  See http://en.wikipedia.org/wiki/Dmitry_Sklyarov
Web sites can have traffic from all over the world and laws in many different countries pertaining to privacy, copyright, libel, etc. may apply to the web site owners, operators and probably even contributors.

See e.g. http://en.wikipedia.org/wiki/Information_privacy and
European Union Aiming To Create New Privacy Laws
Information considered a public service in one country can be seen by others as illegal.  See e.g. the NPR story on Seeing The Internet As An 'Information Weapon' of which this is an excerpt:

  [In 2009] Russia successfully
  sponsored an even sharper version of
  its cyber disarmament proposal at a
  summit of the Shanghai Cooperation
  Organization, which includes China and
  four Central Asian countries as well
  as Russia.   The accord defined
  "information war," in part, as an
  effort by a state to undermine
  another's "political, economic, and
  social systems."

http://en.wikipedia.org/wiki/Shanghai_Cooperation_Organisation


Is stealing the HTTP Basic Authenication header possible via CSRF?

CSRF is a write-only read-none action. Because of the Same Origin Policy the attacker can make a request happen, but he can neither read the details of the request nor read the response. This unreadable parts of the request include cookies (incl. session cookies) and also the information for Basic Authentication.


Is there a difference between GET and POST for web application security?

Option 1 may introduce a number of non-security related issues anyway:

The resulting URL may be cached by the browser, or bookmarked, causing users to resubmit.
The resulting URL may be shared by users, causing third parties to submit.
The URL may be sent to your browser vendor, who may hit the site.

But this is about security, and it introduces a few risks not present in option 2:

The URL with its parameter may end up in the proxy logs of everything along the way, revealing your data.
Your decode function is now an additional attack vector. (Does it handle unicode correctly? Does it have length restrictions?)
You may be tempted to think of your encoded string as somehow secure, when it's just security through obscurity (and not very much obscurity), or perhaps more appropriately, security theatre.

That said though; they are otherwise largely equivalent in the security they offer. They both submit plain text data in the HTTP header, and base64 isn't exactly rocket science (and you can base64 encode your POST version).

Neither offers any meaningful protection for your data.

If it's information you don't want the user to see; why are you sending it to the user to begin with? Consider the architecture you're using and see if there's a way to simply remove the risk entirely by not handling that information on the client side.

So, to answer the question: with regards to sending data - both reveal the same information to an attacker; choose whichever option is more appropriate for the situation (this Treehouse blog post may help with that), but you should not rely on either method to actually protect anything.


What causes Windows security logs saying an attempt was made to reset an account's password?

I just audited the event logs of all workstations in my environment (about 2000 windows 10, 4000 windows 7).

None had that error message in the last 3 days.

It's definitely not a normal occurrence. Do you have any 3rd party password management or MFA/2FA login devices for AD?

I'd post a comment but for some reason you need more points to comment than to answer. Sorry :(


Using multiple hash-functions along the line

Short: There is not much security improvement for hashing again. But hash is better than plaintext (does not directly leak password).

The second hash is apparently intended to protect against retrieving passwords in case the database gets compromised? In this scenario, the protection is only as good as how hard it is to resolve input $_POST['hash'] to hash operation. This input is not sufficiently unpredictable, at least not when weak keys are used.

There are some suggestions you could try to make things stronger.

Password-based key derivation

Usual hashing is not recommended way to deal with passwords. This is because at least fraction of users always tend to have very weak passwords. Weak password is always weak, but there are better ways than usual hash to work with passwords. scrypt paper illustrates the efficiency of different PBKDF's (and some hashes) against brute-forcing passwords of varying entropy levels.

If you want to protect the password+username better, do not use use sha256, but password-based key derivation function (also known as slow hash or password hash - some of these actually use sha256 under the hood; search scrypt, bcrypt, PBKDF2 for details).
The combination of Password+Username is (often) vulnerable to brute force guessing as well as rainbow tables. (In case you expect that the SSL connection does not sufficiently protect the credentials.)

BTW, if you calculate the password hash on client side, it may be possible to remove need for server side ever to know the password. This way, the possibility of the website leaking the password is significantly diminished.

If the user uses the same or similar password on other sites, the result is not usable for these purposes.

Using same authentication info each time

I understood that the user authenticates with

  js > hash = sha256(Password+Username);

always. Right? This has possibility for replaying the credentials later. (Note: In many cases SSL prevents record&replay, but fact that CAs have been occasionally broken, makes it not always foolproof.)

To remove this replay possibility, you could do as follows:
If the server knows their password's derived version (either PBKDF result or above hash [i.e. it is stored on server when they are first authenticated]), instead of ever sending the value again, it could be used challenge-response protocol.

Some more complex challenge-response protocols, such as SRP are based on "zero-knowledge", and provide nice provable security concepts. Even fairly simple challenge-response protocols can preclude need to send the password or password-derived value directly, but just has client sending something that'll convince the server, but not allowing a replay.

Read more

There is a related question on crypto.SE: Is using slow password hashing on the client side easier attackable than on the server side? where Paŭlo Ebermann suggested client-based PBKDF and the best answer by Thomas Pornin also suggests to apply PAKE (SRP).


Brute force vs other methods of recovering passwords from shadow file

If you like speed, you can employ commercial tools supporting large-scale clustering, like:  http://www.elcomsoft.com/edpr.html (starts at $599)

Also, check out:
http://www.insidepro.com/eng/passwordspro.shtml
http://hashcat.net/
http://www.openwall.com/john/ (jtr, mentioned already in other posts)
http://www.l0phtcrack.com/

Here is a short blog entry from Nov. 2010 discussing the use of Amazon’s EC2 Cluster GPU instances to accelerate password cracking.
http://stacksmashing.net/2010/11/15/cracking-in-the-cloud-amazons-new-ec2-gpu-instances/

Good write-up from the “Crack Me If You Can” contest at DEFCON 2010:    http://contest.korelogic.com/team_john-users.html
 (description of contest: http://contest.korelogic.com/intro.html)

I think the best password dictionary site at this time is from SkullSecurity:  http://www.skullsecurity.org/wiki/index.php/Passwords

Another good set of password dictionaries: http://www.insidepro.com/eng/download.shtml

Read this PDF titled “Cracking Passwords Version 1.1”
This document is for people who want to learn to the how and why of password cracking. http://tools.question-defense.com/Cracking_Passwords_Guide.pdf

Good luck.


Without an userID attacking your system can be done a million times faster than with userID. That seems like reason enough to me.

With an userID an attacker can only attack one token at a time. Without userID he can with one try attack all 1 million at once.


First rule to remember is that you don't perform tasks as root unless they have to be performed as root.

This part reduces the risk of doing damage by a typo or other mistake. It also reduces the risk of damage if the tools you are using happen to have a security vulnerability.

Additionally accounts should only have the privileges they need and nothing more than that.

With those parts stated, let's look at the arguments for the two approaches to root access.

Arguments for logging in as non-root and using sudo

You get an audit trail in which it is easier to figure out who did what. You don't run every command as root, but only those which you prefix with sudo.

Arguments why it may not give you as much security as people say

The audit trail only works as long as people play by the rules. It is convenient if there are more than two people with sudo access or if you just can't remember everything you did yourself. Then you can look up who did something, and ask them why they did it.

But if anybody want to bypass the audit trail, they can. If you try to prevent somebody from bypassing the audit trail, those restrictions are likely to eventually prevent them from doing their job.

People may put sudo in front of every command by reflex, even when it wasn't needed. And in case of a security vulnerability, running without the sudo command won't give you lots of benefit since if an attacker compromise a running process, it doesn't matter if it was run with sudo or not, because it can just execve sudo to gain the same privileges.

Arguments why using sudo can be bad

The user password gives access to more privileges. The user may by typing the user password frequently. If an attacker gets this password, it can be used to run commands through sudo.

A compromised user account effectively gives root privileges. Remember the part about not running as root unless you had to, and giving accounts no more privileges than they need?

If you log in as non-root user for all tasks that don't require root privileges, you reduce exposure. You don't get that benefit if the account has sudo access. Those tasks that weren't run as root become a more valuable target for an attacker, if that same account has sudo access.

What else can you do?

If you want the best of both sides, you could give each administrator two logins on the server. One login for day-to-day tasks, that do not need root privileges. And a secondary login with sudo access for when they do need it. But then the only thing that is different between that second account and login directly as root is the audit trail. But it may be easier for people to forget that they are not supposed to use the account with sudo access all the time. Remembering to not log in as root all the time seems a bit easier for people to remember.

What about password brute forcing?

Some argue that it is easier to brute force a password for an attacker that only need to guess a password and not both user name and password. In reality this is a weak argument.

You can configure sshd to only permit logins using a key. There is no need to permit login using a password. If password logins are not permitted, then password brute forcing is no longer an issue. There does not even need to exist a password, that gives access to the root account. And nobody is going to guess the secret key for ssh authentication.

When /root/.ssh/authorized_keys contain a public key for each administrator, those public keys could be used as an audit trail showing who did what. And it is just as easy to revoke access by removing a key from authorized_keys as through any other means.


If P=NP, what is still cryptographically secure?

Any classical cryptography scheme is algorithmic in nature i.e. any classical cryptography scheme can be broken (in principle). The upcoming field of quantum information I think can one day be able to make communication secure. If you want to read more about quantum key distribution protocols try searching: BB84 protocol, B92 protocol and eckert protocol.


What security risks do unauthorized mobile hotspot (MiFi) devices on company proprerty pose?

A significant threat is around an attacker setting up a hot spot that purports to be a valid company wireless access point. If the SSID is right, and the organisation doesn't use mutual authentication, users may connect to the malicious hotspot, which means all traffic will travel through kit controlled by the attacker.

See this question and this one for some implications.


Is something like fail2ban necessary for a rate-limited key-only (no password) ssh login?

No, it is not vulnerable to bruteforcing, practically speaking. Depending on what you're doing on the server, an application firewall like fail2ban (or ModSecurity) could provide additional security for other internet-facing services running on the machine (but to answer your question, no, fail2ban would not provide any meaningful amount of additional security for key-based ssh).

Personally, I've never even logged any bruteforcing attempts for key-restricted ssh.


Software update process (dependencies) in organization

There is no answer possible. Many struggle with this and almost nowhere it actually works.
The point about component owners is perhaps the most important one. Every component must have a component owner. When people leave, someone else needs to pick that up (this is actually hard). In my experience, some form of hierarchy in the components (not necessarily in the organization!)help. For example: you may have a component-owner for all servers. He then delegates his Linux servers to a linux-component-owner and a windows-component-owner. When the Windows-component-owner leaves, it is clearly the responsibility of the servers-component-owner to appoint a new windows-component-owner. Likewise, if the server-components-owner leaves, the windows and linux owners will need to reelect a new server-owner. Do not rely completely on the fact that a leaver correctly transfers all his responsibilities within the organisation.
Any organization has some form of hierarchy. Ultimately, the top must be responsible for all IT.
Another challenge is how to make sure that your component owners actually update their components. And preferably without setting-up a huge administrative process. As a thought experiment: try to imagine such a process without a spreadsheet. Many just put-up with an administrative process though.
The remark "preferred Scrum based approach/agile" means that you are not looking to the structure, but only to its execution. You will need a structure that is independent of your scrum. Otherwise, you are down to forcing every team to put 2 story points (or whatever your scale is) for updating per component on their sprints.


I run a lab on a KVM virtualization setup.  Among other things, I use Damn Vulnerable Linux, old versions of Ubuntu, and various VMs and software from VulnHub.  I have an ethernet bridge acting as an internal switch and a virtual router between my test lab and my internet connection to isolate tests like ARP Spoofing, subnet-wide scans, etc.


You are somehow thinking that dead tree docs are less secure than digital copies. I may venture to say you are mistaken in this belief.

Digital data may be stolen in a myriad different ways. The scanner may be reporting to HP or other companies/agencies, while your computer may be already compromised. Your computer will have vestigial data on the hard drive. Use of encryption may warrant unwanted attention.

Last, but not least: you can lose a digital copy much easier than the original. All it takes is one inopportune kick to the hard drive or static discharge, or simply a forgotten password. To overcome this, you will be forced to make multiple backups, store the password somewhere etc. etc.

If you are really intent on digitizing the document, take a fresh memory card for your camera and make a few photos. Stash the card somewhere secure.