If I understand your question correctly, you are asking how to persistently compromise a whole domain with XSS, and not just a single page, to be able to execute malicious code in every page at any time.
Suppose you have one page, vulnerable-page.php, where you can inject JS code persistently, that is, every time a user loads the page the malicious code will be executed. If the victim visits non-vulnerable-page.php though, your code won't be loaded. There might be some tricks you can use anyway, for example you can make vulnerable-page.php look and behave like non-vulnerable-page.php, so the victim will think they are on non-vulnerable-page.php while in reality they are still on the vulnerable page. You could even expand this concept and devise a kind of front-end proxy, so that the victim will think they are browsing the website, while in reality they are always staying on the vulnerable page (the vulnerable page will load the content of the other pages with AJAX, and maybe also change the path in the address bar). You can use similar clever tricks to obtain the information you want, but your mileage may vary.
Now suppose you find a stored XSS vulnerability in the footer of a website, and that footer is included in every page: home page, articles, login page, admin panel, etc. In this case you will be able to inject your code everywhere all the time, and therefore execute any JS you want, wherever and whenever you want.
In several cases though, an attacker doesn't need to be able use XSS in every page to be able to compromise a website completely. For example, the attacker can make a logged-in admin visit a single compromised page on the website: that page might send an AJAX request to change the attacker's privileges (upgrading the account from "guest" to "admin"), and from that point on the attacker will just be able to do whatever they want from the admin panel (including installing malicious modules, changing files, etc.). This is just an example to show you that often a single vulnerable page can still lead to complete compromise.


How can you be tracked using screen resolution/monitor size in Tor?

All Tor browser users are asked to surf pages using the default window size. So if you follow this practice, you are just like other users; I mean the screen resolution won't be used as a factor to identify you.

From here, you can read an interesting comment that fits your question:

  Using an unusual screen resolution was sufficient to identify me
  uniquely to panopticlick. With my portrait mode screen resolution of
  1200 wide by 1920 high, the default window size of 1000x1765 was
  unique, no resizing or maximizing needed.

Visit browswerspy webpage that implements a demo where you can find out information about your screen including width, height, DPI, color depth, font smoothing.

Conclusion: do not distinguish yourself from others. Act as everybody else.


pdfid analyzing / disarming documents causing infection?

It generally depends on how it is unsafe. If it is unsafe because of a vulnerability in a pdf handling library used by pdfid then it may compromise that machine.

If it's unsafe because of a vulnerability in random reader, that does not affect pdfid or any of it's libraries, then no, it will not affect that machine.

As always the first step is to analyze the threat. What is the threat? What is the target of the threat? What mechanisms does the threat use to achieve this target?

If you identify that JavaScript embedded in the PDF is the mechanism, any tool that is able to strip the script, without executing it, will be perfectly safe. So will any viewer not executing it.

If the mechanism is a buffer overflow in Acrobat Reader, any reader and tool not based on Adobe code is likely to be unaffected.

Once you understand a threat, you can protect against it. This may be stripping JavaScript from PDFs, or blocking them outright if you find no effective way to protect, and the risk outweighs the benefits of allowing PDFs.


Security of a desktop application's source code

How easy is it to get the source code from a desktop application?

If it is open source software it is easy. If not it is harder.

  Are there any protections in place to stop someone from viewing an application's code?

This depends on the software. Usually you cannot get the full source back because in the process of compiling the original source is translated to machine code or byte code. But you can often decompile the code to get at least an idea how this software works and find bugs in it (i.e. reverse engineering). Some applications have added obfuscation and other methods to make reverse engineering harder.


What use would a privacy browser, such as Firefox Focus for iPhone, have for an internal web server?

One thing Firefox Focus uses this embedded web server for is to detect whether Safari Content Blocking rules were successfully enabled. It seems from this answer and the Focus source code that iOS 10 provides an API for determining whether a Safari Content Blocking extension is enabled, but that in iOS 9 there wasn't such an API. Instead, it was necessary to actually try making a request to detect whether that request was blocked; if blocked, you then assume the blocker is working. I'm guessing that a decision was made to spin up a local web server as the target for the blocker detection test so as not to rely on a remote service, which would have introduced reliability and privacy issues.


Does SSH support DSA with 2048 bit keys?

For the hash: Crossdupe https://crypto.stackexchange.com/questions/15051/why-does-openssh-use-only-sha1-for-signing-and-verifying-of-digital-signatures and https://crypto.stackexchange.com/questions/39983/which-hash-function-is-used-for-signatures-ssh-rsa-and-ssh-dss
but probably better here.

A recent answer there links to https://www.openssh.com/txt/release-7.2 (of 2016-02-28) which refers to now-expired https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-03 which despite the name only upgrades RSA to SHA2, with section 6 explaining that DSA was dropped, as does its still-draft replacement https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-02 .

You can easily confirm no other RFC has changed this in the IANA registry for SSH.

And OpenSSH since 7.0 has deprecated and disabled by default (all) DSA. There were numerous Qs here and related stacks late last year about this e.g.:
Why OpenSSH deprecated DSA keys
https://unix.stackexchange.com/questions/247612/ssh-keeps-skipping-my-pubkey
https://superuser.com/questions/962918/pubkeyacceptedkeytypes-and-ssh-dsa-key-type
So they aren't likely to implement improvements to DSA, and anyone else who pushes something incompatible with OpenSSH usually finds it unused.

"Sorry, Charlie."

FWIW although FIPS 186-3 up encourages you to use a hash matching the DSA subgroup size (i.e. N) it doesn't actually require it. OpenSSH ssh-keygen won't generate a DSA key bigger than 1024, but if you generate such a key by other means (such as OpenSSL 1.0.0 up as of 2010, or Java 8 up as of 2014) OpenSSH ssh and sshd will use it (in 7.0 up once you undo the default disabling). But they use it with SHA1 as per the RFC, which basically discards the security benefit the new 186-3 sizes are intended to provide. (Accept no substitutes. OpenSSL 0.9.8 could generate a DSA key with then-nonstandard N=2048 or 3072 -- but still L=160.)


How does Mylar ensure encrypted data remains secure even if the live app code is compromised

Mylar requires using Meteor. Because of the separation of data and format in the Meteor framework, it can actually sign the application template. In a normal web app the browser receives the concatenation of the data and the presentation as one element; in a dynamic web app you can not sign the page because you don't know what the output will be at run time.

If the attacker doesn't also have the ability to sign the files being served, an error will happen because the signatures are not valid. If the attacker has the ability to impersonate the legitimate user for signing purposes, that's almost as bad as having the root CA keys in the PKI world, game over.


They certainly could decipher anything you send because you are talking about synchronous encryption, where the same key is used to encrypt and decrypt the traffic. In order for this to work both sides have to agree on a key for exchange. Shared secret verification is not actually a requirement for a secure key exchange from a theoretical standpoint, you could exchange keys securely with anyone really. However, if you do not verify the other side then you could be setting up a VPN with anyone, even those you do not want to, and send all sorts of confidential information. This is why sender verification is an integral part of all secure transfer technologies.

You may be getting confused by mixing up PKI and VPN technology, mistakenly thinking that when verification is taken care of by PKI that only the true recipient can decrypt the traffic. It's not that simple because PKI decryption (asynchronous as opposed to synchronous encryption) is extremely computation intensive, so secure transfers almost always use PKI for sender verification but then set up synchronous encryption for the transfers themselves.

EDIT: poster says the source is a lecture

If both sides do not share the same key neither side would be able to decrypt the other's traffic, so key confirmation is important from an operability perspective if not from a pure security perspective. Also, if you are using a VPN to check for authentication (see IPSEC AH) then you must verify keys, or you can't be sure what is authentic traffic.  What the lecturer may mean is that it simply won't work without a key verification, rather than being a security process.


Certificate services will not start with "server is offline" error

When AD Certificate Services starts up, it insists on validating its own certificate (the subordinate CA certificate). This entails verifying that the CA certificate has not been revoked, by obtaining the CRL referenced from the CRL Distribution Points extension found in that certificate. If the CRL have been moved, and not up-to-date CRL can be found at these location, then the validation will fail, and the service will refuse to work.

At this point, you have the choice between four strategies to recover the situation:

Put back the root CA, or more precisely the CRL issued by the root CA, where the subordinate CA expects them to be. By default, in an Active Directory context, CRL will be in a location which depends on the machine name (start the "Sites and Services" tool, activate the "show the services node", then find the "CDP" node). These are AD objects, which can be copied and moved (an AD object is "just" a collection of attributes) so you could script that process to do it automatically.
Push the CRL from the root CA into the local machine store of the subordinate CA, so that Certificate Services may see them even if it does not find them at the designated distribution point. This can be done with the GUI (mmc.exe console), or programmatically (CertAddCRLContextToStore())(I have done the latter, invoking the Win32 function from a piece of C# dynamically recompiled from a PowerShell script...).
Renew the subordinate CA certificate, reusing the same name and key, but with a new certificate with CRL Distribution Points pointing to the location where the root CA now publishes its CRL.
Scrap the subordinate CA and install a new one, reusing the same name and key. This is a variant of the previous strategy, but more thorough. To avoid losing control of all previously emitted certificates (these are still valid and you still want to be able to revoke them), you would have to push them back into the new CA using certutil (certutil -importCert to reimport a certificate, certutil -revoke to make the CA again aware of a past revocation). This is high and desperate surgery; don't do this until all other strategies have failed.

Generally speaking, ADCS has been designed so that it integrates quite deeply into Active Directory structures, and the complete ramifications are intricate and poorly documented. Things work "magically" by default, and you discover why when you do a seemingly unrelated change and they break.


Do bug bounties ensure that software is secure?

No, they don't ensure that software is secure. But they might lead to more secure software if the bounty means that the vendor is actually committed to better security.

  Does this mean that they take security more seriously than other providers?

Usually vendors who have bug bounty programs invest more resources into keeping the software secure. With single target bug bounties this can (but don't need to) be different. Such cracking contests might be more a marketing thing so that the software can be marketed as "unbreakable even by experts". In these case the bug bounty often does not cover typical real world attacks. See also The Fallacy of Cracking Contests
.

  How long can bounties like this last?

This is fully up to the vendor.

  I'd like to see some examples if there are any similar going on right now or have been in the past.

A search for bug bounty unbreakable cryptography gives you other such programs.


How can I inspect/audit an Android phone if it's vulnerable to CVE-2012-4221 (or any other?)

There are multiple facets to this question.

Phone vendors will typically push patches at their leisure. So part of the question becomes "who is your software vendor?" and "are you running a stock image?" This will determine if there is updated software available.
If in doubt, you can collect proof of concept testers on the internet to attack mobile phones with. This is spotty at best, because not every vulnerability lends itself well to packaging as a risk-free auto-pwn site. The Android Vulnerability Suite that WoJ linked will be helpful with this.
If you are looking at Android as a ecosystem, you'll need to tangle with app permissions and app updates. Apps can introduce vulnerabilities as well, and occasionally updates cannot be done (I've had this happen due to picture overload).
For hardware, it will be a little more esoteric. You'll have to pull in information from the internet about handsets and compile that into your guide. Luckily for your guide (and unluckily for your users), hardware exploits are harder to fix in production, so it should turn into a simple comparison once you find a reputable source.


What does the tilde (~) mean at the end of a file extension?

It's just part of the filename, just like letters, numbers, and other special characters can be part of the filename.

It's conventional to create "backups" of files before editing them by appending a tilde, so in case you mess something up, you have a previous version to restore. In Bash this can be easily done with cp index.php{,~} which expands to cp index.php index.php~.

It could be on the CTF because people often forget about those files and leave them unprotected. Especially a file like index.php might contain database credentials.

In bash, a tilde at the start of an argument also expands to a home folder: ~ turns into $HOME (e.g. /home/yourusername), or ~username turns into that user's home folder (e.g. ~root typically expands to /root). That is not the case here, though, because it's not at the beginning.


Having web client do requests with User's 3rd party API key?

Generally browser's local storage and cookies are considered safe, since if user's machine is compromised we can't do anything. However you can (somewhat) increase the security of data at rest with a layer of encryption.

To store the keys securely on user's machine you can request a password from user, which (after passing it through KDF, for example PBKDF2) would decrypt an encrypted container with API credentials (AES+MAC, something like SecretBox from libsodium) which is stored in localStorage.

Any other way I can think of requires you to store encryption key somewhere on the user's device, which only obfuscates the data.

  the only way to get the keys would be via an XSS attack

Also check if your site needs to be iframe-able and if not - deny it in server headers. Iframes should be safe, but they have been abused many times in weird and wonderful ways.


I think whatever configuration settings you have done are correct for OT devices. Regarding plugins, I think it would be best to search plugins on Nessus Website. For example, Check this nessus plugins search website: https://www.tenable.com/plugins/search?q=OT&sort=&page=1

The listed plugins (First 4 on the plugins page) are the generic ones. You need to put little bit of efforts to find some more according to your device or your scan requirements.


If domain admin account's NTLM hash is compromised, can it be used to access any machine in network

Yes, this is called the Pass the Hash attack.

Microsoft has not issued any solution to mitigate (except for some vague general security advice), until Windows 10 where the hash is stored in a special vault.

An example of exploit (via Metasploit) can be found at Offensive Security.


Nc with -k option will help.

nc -l -k -p 3030 -e /bin/bash
nc -l -k -p 3030 | /bin/bash

Forces nc to stay listening for another connection after its current connection is completed. It is an error to use this option without the -l option. When used together with the -u option, the server socket is not connected and it can receive UDP datagrams from multiple hosts.


If a web site shows me what my password was changed to, is it stored as plain text?

No, you cannot conclude that.

The password can be hashed on the server-side only, which implies that the password is sent in plain text to the server and stored in a variable. Then, nothing stops the Web application from displaying the sent password to the user, in the case where the very same script that has received the password is giving you the feedback about the password change.

On the other hand, if a whole other module gives you the password in plain text (perhaps a password recovery function), then you could conclude that it is not hashed.

Edit: To avoid any confusion, in this case "plain text" does not refer to SSL in any way, it simply suggests that the password is not sent pre-hashed to the server.


Dencrypt containers on the fly without mounting into filesystem?

If you want to ensure that users only have access to their files by providing a key (possibly stored in memory so they don't have to provide it over and over again), then why don't you just use a plain, unencrypted filesystem and encrypt each file individually?

Maybe because this leaks information about number of files, creation and modification dates, file sizes and possibly file names if you don't encrypt them. So you start writing some code around that solution and finally you end up with a solution which stores individual files in a container so that you have control over the file metadata.

And now you've reinvented LUKS, TrueCrypt,VeraCrypt, ...

The one difference between your system and these solutions is that your system supports individual keys for each user while LUKS & Co just use a single key. But you can get almost the same behaviour from LUKS by creating a single container per user. You still have the problem that if someone gets root access to the machine, he can read all the open containers.

However, he can also do that when each file is individually encrypted. You need an interface to your system which takes a user and a filename, decrypts the file on the fly using the users key, which sits in memory, and returns the decrypted file contents. What's to stop root from using this same interface, masquerading as the user?

Basically, LUKS below a standard filesystem provides the interface you'd have to design yourself otherwise. There are only two solutions I can see that would give you more security (but not what you envision):

Use a TPM to protect the user keys. This way they won't be stolen from memory, but a user who has root can still masquerade as another user and decrypt every file by ordering the TPM to decrypt its contents.
Put the encrypted data and an access API on a dedicated machine which only serves your application and is only accessible using the access API. This makes for a much smaller attack surface on your encrypted data. But it also can't protect you from a compromised root account on your app server or the storage server.

So, to sum up: I think you already get what you want out of the box with LUKS. There is no secure line of defense against compromised root.


As I mentioned in the comment, you can't trust javascript served by the server.  The idea of keeping the client side downloaded on their computers is interesting, although that doesn't really solve the issue.  The server can still include javascript as part of a response unless you are insanely careful.  In this case I really wouldn't go with javascript.  There's just too many ways it could go wrong.

My recommendation in this case would be to use a browser plugin, or some other client side application which could be compiled and signed since you're dealing with sensitive credentials.  Is there any reason you couldn't just go with a service like lastpass?  Why reinvent the wheel.

EDIT:

How to implement crypto-js PBKDF2 with salt https://stackoverflow.com/questions/22875419/cryptojs-how-to-generate-aes-passphrase

You also mentioned that you think the users will reuse their passwords in both your system login and their private keys.  After the user submits their keys/certs to the system, you may want to look into auditing their uploaded creds by using the password they supplied to unlock the cert/private keys.


S/MIME signing and verification - how do I find proper certificate?


Doesn't seem to be able to capture the packets I need

I'm not really clear about your setup.  At one point you seem to say that the laptop is serving as a wireless AP, and in another place it seems like there's a separate AP.

Run Telegram between the PC and the phone and run Wireshark on the PC.  In normal use, your wireless AP is not going to repeat traffic destined for other devices to the PC you're using to run Wireshark.

If you must have two phones, you could associate them with two different access points and put a hub (not a switch) in the middle.  Then connect the PC to the hub.

Edit: After I've read a little more about Telegram, it seems the clients do not talk to each other, they talk to Telegram's servers.  So, you will need something like this:

If you run Wireshark on the laptop in promiscuous mode, you should be able to see the packets from the phone headed to the Telegram servers.

Note that the connection in the middle must be a hub, not a switch.  You should be able to use two or more phones with this setup; I expect you'll see both talking to Telegram's server, and not to each other.

Alternatively, at least with Windows 7, you can turn the laptop itself into an access point.  A Google searh will find instructions; one such is here:http://www.firewall.cx/microsoft-knowledgebase/windows-xp-7-8/968-windows-7-access-point.html  With the laptop serving as an AP, and connected to the gateway network using a wired connection, is is possible that Wireshark in promiscuous mode might be able to see traffic passing from the wireless radio to the wired Ethernet.  If you can put your hands on an Ethernet hub, try the method shown in the diagram.  I am sure that'll work.


Which encryption algorithms will be used to replace RSA when quantum computers become common?

The eminent programmer and cryptographer Daniel J. Bernstein has a page dedicated to that.  The shortest version:

Hash trees, NTRU, McEliece, and multivariate-quadratic systems.

McEliece, for example, is immune to quantum speedups because it relies on "the hardness of decoding a general linear code (which is known to be NP-hard[4])." Since NP is not in BQP, NP-hard problems remain hard; even with practical quantum computers.


Can an employer see cellular network traffic routed through company-owned device?

Some carriers have (very expensive) plans that connect the IP part of the mobile connection to an L2TP or IPSec gateway, making your mobile appear as if it were on the company's network. If such plans are in use, then it's the same as if you were browsing directly from the company's Wi-Fi or Ethernet networks.

Using a VPN terminated on your mobile device will help in regards to network monitoring (your company will only see an outgoing VPN connection to a server you control), that is, if their network will actually allow you to VPN out to an untrusted (to the eyes of the company) server - after all, outgoing encrypted connections can be used for sensitive data exfiltration or malware traffic. If this even works, it'll most likely be forbidden by your IT acceptable use policy and definitely raise some red flags on the sysadmin's side.

Note that no matter which network monitoring solutions might be in place, you still can't be safe as the company-provided device shouldn't be trusted - it's most likely managed by an MDM solution and the sysadmins have root access to the device. See the nice picture your girlfriend sent you ? The sysadmins are already looking at it. The super secure HTTPS-enabled webmail you're used to accessing ? The sysadmins can look at them because their CA certificate is in the device's trust store and they can thus impersonate any site by issuing valid (to the eyes of that device) certs.

I suggest you at least make it clear with the IT department whether you're allowed to use company-provided mobile network access for personal usage and whether you can VPN out to your personal server (or a third-party VPN service). If you are allowed, you should initiate the VPN connection from a trusted (non-work) device like your computer, and only use the company-provided hardware as a hotspot. In any case, don't trust their hardware with personal files even if they allow you to do so - the fact that you're allowed to use them doesn't mean they aren't allowed to look at what you do.


Create honeypot for remote desktop applications

You don't need to set up a honeypot to accomplish either of these. I can tell you exactly what their intentions are once they've compromised a machine. Depending on who gets lucky enough to brute force your credentials first, you can bet they will do one or more of the following :

Send out spam / distribute malicious content from your server
Use it as a VPN server to connect to in order to perform other malicious tasks using your public IP address
Utilize it as a Command and Control server for Malware
Use the newly compromised host to perform various attacks on other computers on the internal network. Compromises become much easier once you've bypassed the firewall
Install a back door to ensure continuous access to the system.

Finding a list of weak passwords that are being used should be relatively trivial. There is a lot of risk in setting up a honeypot, and from what I gather about what you're hoping to accomplish, not a lot of gain. As the owner of the VPS you are ultimately responsible for the activities that occur on it, so if someone with malicious intents compromises your box because you set up a honeypot and didn't take the proper precautions to contain the damage, you will ultimately be responsible.

In addition, I would also think that setting up a VPS for the purposes of a honeypot would violate the TOS that you agreed to when procuring the VPS.


Designing and implementing a secure epayments system with RESTful API

You might think that your project differs from a decent Content Management System. But in fact it's not. You should reinforce what's paramount to every software project: Testing and high code quality. Security is not only subject to the API itself but to the software behind.

Using a programming language that forces a static type system is a good start. Then do excessive Unit and functional testing. Especially what happens if the client does not behave in the predicted manner. Then you can do some pentesting.

Those strategies apply to a high-security application as well as a little app like a CMS. I would also suggest a language like Java with a compiler. So if you introduce any code inconsistencies they will break the compiling process.

The server itself will likely to be secured like every bigger server. But that's not my best expertise.

You see? Nothing new and fancy here...


MS-SQL Monitoring/Auditing of PHI for HIPAA

SQL Server itself provides a number of compliance tools that you can take advantage of to secure and audit your database and data.   There's a Compliance page on the SQL Server site and Microsoft has written a Compliance whitepaper that will get you started.

Additionally, there are huge number of third-party auditing packages available for SQL Server.   A search for a set of terms like SQL Server auditing HIPAA compliance should net you plenty of options to choose from, such as Blackbird Auditor, and OmniAudit.   The products obviously have different feature sets, spo you'll need to determine which ones best meet your specific criteria.


How can I enforce strong password policy with non-technical user base?

Do you have the option of adding 2-Factor authentication to your site? Here's the first article that came up when I googled "using google authenticator on your site".

If this is a corporate network and your users are your employees, then you have the option of using physical tokens like smartcards plugged into their desktops, or grid cards.

From a social engineering / design perspective, can you find a way to use a carrot approach rather than a whip approach? By that I mean give perks to users who have strong passwords (in a way that's not visible to other users, otherwise it's equivalent to public shaming for weak passwords which is actually worse). Maybe a small discount on membership fees or purchases, or in-service perks like small vanity features, more storage, priority queuing, wtv. I know MMOs have used this to great effect to help encourage the adoption of 2-Factor keys and strong passwords.


I read of one... You find a very remote place, preferably not on a map anywhere. You put the Linux run time you want to protect in a vault like bunker with no physical access, running on its on dedicate power supply (of course this has to be a perpetual motion machine based power supply), in a facility that has no staff, no network connections and is absolutely guaranteed to be inaccessible. Of course you must remove any USB, or other ingress ports into the machine, and pour super glue into all seams in the boxing of the machine to ensure no one can crack the case and put jumper cables into any communications layer.

One way to protect run time memory... Of course a very restricted and severe way.


Gmail account hack prevention and recovery

The hack preventing side is pretty much covered by the dual factor authentication that was recently introduced and the use of the "Always use HTTPS" setting (on by default in gmail) for accessing google, to avoid ssl-stripping attacks.

Now, when you have a compromised account and want to claim it back, Google has a structured procedure to verify you are the real owner of the account, in case the normal password recovery options do not work:

You have to complete a fairly detailed form and send it to them, and they say that it is a good thing to do so from an IP address that you have previously used to access the account - they obviously store those.

Among the details that they need you to provide are:

If you used Gmail with this Google account. If yes, what was the most recent mail recovery address you used (in case it has been changed). Also, what are the e-mails of your 5 most often contacted people, what are the names of 4 labels you have created in the account, if you created the gmail account using an invitation or not etc.
If you used your Google account with other services, like orkut, blogger or any other, you provide details about them, like when you first started using them. The details need not be 100% correct - I guess a real person is going to assess the situation at some point after passing obvious checks.
Other details you have to provide include an estimate of when you started using any google services at all (associated with the account), when you last logged successfully and what is the last password you remember for this account (so they must be storing password hashes of previous passwords).

EDIT: Just found a google article with more info about the reclaiming situation. http://knol.google.com/k/how-to-recover-a-hacked-or-compromised-gmail-account

EDIT2: Just noticed you mention paid services. There is Google Apps for Businesses that offers some benefits for a moderate fee, including live phone support that could potentially help in situations like that, although not sure. On the other hand, there are indeed commercial services, dealing mostly with the authentication part, like DIGIPASS by Vasco. There are several services like that in google marketplace.


Best approach for making an app that connects to sensitive information

SSL prevents an attacker on the network from being able to see or manipulate the data in transit.  However,  this makes no guarantee that the user of the application hasn't modified the application.  Any value stored in memory on the device can be easily obtained using a debugger.

In short you can never trust the client,  and this isn't a problem that cryptography can solve, period.


Is EICAR a valid test for a mail virus scanner?

The point of EICAR is that A-V programs will respond to it as though it were a real virus, it's of limited use if they don't.

What you're seeing here likely warrants some further investigation as @schroeder suggests in comments.

I'd recommend first trying sending EICAR without putting it in an archive.  If it is found at that point it would appear that your scanner is not fully reviewing files inside archives, if it is not found at that point it appears that your scanner is either defective, or not triggering correctly on EICAR.


Handling unencrypted HTTP data for a PCI compliant system - in scope for PCI DSS v3 but not v2?

Part of both answers:

Disclaimer: I am not a QSA.  And I'm straying farther into opinion here than I prefer to, so apply salt in grain form.

New answer following edit of question:

There are two changes with DSS 3 that bear on what you seem to be flirting with

the addition of the new SAQ A-EP category.
the back alley tussle that has been iframes versus javascript
which keeps threatening to break out into some form of
official guidance.

Both of these items are concerned with the provenance of credit card transaction flow.  If I go to website X, and click "Check Out" from their shopping cart, I go somewhere to enter my credit card details.  Where is that somewhere?  How do I know it's where I'm meant to be?  How do I know it's not routing my traffic through Bulgaria first?

Your business appears to be a traffic middleman.  Voila, you're exactly what PCI is moving towards avoiding, or at least securing.  You want your clients to seamlessly send traffic your way and you'll provide value X.  But PCI doesn't want traffic seamlessly redirected unless there's sufficient security - to make sure, for example, no one can edit the process to use a different (malicious) checkout page.

You route traffic based on analysis.  Great!  That means an attacker can use you to reroute traffic.  In PCI terms, that means you're either in scope or not permitted.  And as a service provider who has stayed out of scope in the past, that means something's likely to change.

Now, the provenance issues are not laid out clearly.  I can't point to DSS 3 section 13.7 which says what you're doing is addressed.  But I can tell you that QSAs are going to start asking questions like "And this company does what?  They middle all your HTTP traffic, including the traffic that sends people to shopping cart and checkout?"  Then they'll want to see your service provider certification, because as per the definition of Service Provider:

  This also includes companies that provide services that control or
  could impact the security of cardholder data.

So, yeah, you could end up with problems as the shift to DSS 3 progresses.  I still don't feel confident I understand your business, so I can't say anything for sure, but it you're middling traffic, you're on the list and may lose customers if you're not a certified service provider.  (Prolexic isn't.  Akamai is.  Who can say?)

Original answer below:

I recently performed a line-by-line comparison of PCI DSS v2 versus v3, and I don't recall anything within the DSS itself that would impact the traversal of HTTPS traffic across a provider.  Section 4 deals with the encryption of "cardholder data across open, public networks" and would be the obvious place to look, and that's barely changed.

That being said, two caveats:

1) The DSS is not the only thing to pay attention to.  The wording on the SAQs, if they apply to the businesses in question, and various other guidance papers that elaborate on the meaning for QSAs are also important.

2) It's not completely clear to me that your service is simply a conduit of encrypted traffic.  You state that your clients "re-point their DNS to our application's IP address and our application will analyse the traffic and then route as appropriate."  The phrase "analyse the traffic" will lure any QSA in for a deeper look.  You shouldn't have much to work with for analysis, in the case of HTTPS; you would have to allow the SSL negotiation through to the true backend to nail up HTTPS before the channel was secure from you, and if that's all you're doing, your service isn't doing much.  In short, I don't feel we have enough details about your service to give you solid advice.


You have a lot of questions combined into one here, and I won't attempt to answer all of them.

Regarding serial number schemes, I am aware of an installation that originally said "we have two signing machines, let's add a prefix of 100000 to the numbers generated by the second machine.  Turns out that it didn't take as long as they planned to consume a hundred thousand serial numbers, and their scheme collapsed.  Serial numbers can be quite long.  I'd recommend using a hash of the public key as the serial number, or at least a significant fraction of it (it needs to be large enough to statistically assure yourself that you will avoid collisions, taking into account the birthday paradox.)  They only need to be unique, not sequential.

Root CAs are often set for 10 or 20 years of life; they are trotted out only to sign Subordinate CA signing certificates, and are kept physically locked in a safe the rest of the time.  SCAs are set to expire more frequently, as they're installed in on-line systems and are in constant use, exposing them to more risk.  But each signing certificate needs to expire after the lifetime of the longest certificate they issue.  If you try cutting them too close, you will run into problems when they all expire at the same time.  In a related caution, you want to make sure your subordinate CA certs don't all expire at the same time.

I'm unsure why you show "customer certificates" signing other "customer certificates".  A certificate that can be used for signing has a tremendous amount of authority, and you typically would not risk delegating that to a third party.  If you have that kind of relationship, it would be more common to offer a signing service to your clients who need certificates.

It's also time to think about CRLs and/or OCSP responders.  You also need to consider tracking your certificates.  You can issue them all day long, but I assure you most of your clients will forget to request new ones until the day the old ones expire.  If you keep a list of issued certificates in a database, along with the requester's email addresses, your security team will be able to send out warning notices a month before the certificates expire.

Finally, there are enterprise certificate management products in the marketplace that can manage all of these requirements for you.  While this is not a forum for making specific product recommendations, I suggest at least searching the market to see what's available.  They will likely provide answers to other questions you didn't know you should ask.


What's the purpose of a PGP transition statement?

(a) your old key should sign your new key

(b) write a transition statement, stating that you're moving from
    an old to a new key, and that you want your new key to be signed

(c) sign that transition statement

Isn't the act of signing another key that has the same UID/email
address, sufficient to prove that all trust placed in the old key
should be inherited by the new key?

No.  Signing the key only will only provide whatever trust metrics are determined by another user's trust policy once they import that key.

That is: (a) is sufficient, (b) is perhaps useful (though could be
replaced by other unauthenticated channels), and (c) is
unnecessary.

That won't achieve the aim once the information is received by other OpenPGP users and the effectiveness will vary entirely according to their own policies.  If you only sign your new key with your old key then the new key will only gain whatever trust values, usually at a somewhat reduced value flow on from that signing.  Those trust values, however, are not determined by you, they are determined by each user within their keyring.

An easy demonstration of this, of course, is to compare the trust value of your own secret key to anything else in the public keyring; yours should be "ultimate" and all the others will be less than that.  Chances are most of them will be "unknown" or otherwise not specified.

If you only sign your new key with the old one then there is essentially no difference between that and any other key you sign, such as following a key signing event.  The purpose of a transition statement is to explicitly confirm that the new key replaces the old key and that anyone who signed your old key should be able to use the statement to confirm the transition and sign the new key.  Which is not something they would do for any key you happened to sign that does not belong to you, regardless of UID conflicts (which may or may not always contain email addresses).

In order to provide the necessary assurance and relevant information to people to whom you are essentially sending a request to sign your new key, you really should provide all of the information.  I'd say "must" here, but I don't want to confuse people by using RFC-like terminology.

One thing that is normally recommended with transition statements which has not been included in your list above, however, is that (c) sign that transition statement ought to be dual-signing the transition statement.  That is, the transition statement document is signed by both the old key and the new key.

A few years ago I transitioned from my old key (0x371AC5BFA04AE313) to my current key (0x321E4E2373590E5D) and used this transition document) which you can see the whole process with.  If you import both my old and new keys and then verify the statement you'll see that the signature data contains two signatures rather than one, though with the same timestamp.  The transition statement contains all the necessary information to verify a key which would normally be verified in person or via some other trusted channel (i.e. usually at a key signing party or CryptoParty), the dual signature tells recipients that both keys remain under the same person's control and that they do not believe the old key has been compromised at the time the transition statement was made.

You'll also see that I nicked the majority of the wording of my transition document from DKG.  ;)


How we can PoC our product that needs training data for our machine learning algorithm of the the bank clients?

This is not just an issue with 3rd parties - banks have strict regulations about what PII they can use in development environments if controls are not up to the same strictness as production environment.
The usual route is anonymisation or pseudo-anonymisation. From https://gdpr.report/news/2017/11/07/data-masking-anonymisation-pseudonymisation/:

With anonymisation, the data is scrubbed for any information that may serve as an identifier of a data subject. Pseudonymisation does not remove all identifying information from the data but merely reduces the linkability of a dataset with the original identity of an individual (e.g., via an encryption scheme).
Both pseudonymisation and anonymization are encouraged in the GDPR and enable its constraints to be met. These techniques should, therefore, be generalised and recurring. Those in possession of personal data should implement one or other of these techniques to minimise risk, and automation can reduce the cost of compliance.

If those are not possible, have you looked at allowing your learning phase to be run within the bank's secure testing/development environment? Worth considering it.


Setting the HTTPOnly flag for PHPSESSID cookie

You have at least 3 ways to achieve that:

In the PHP configuration file (php.ini), look for session.cookie_httponly setting and set it to True.
If you don't have access to PHP configuration, you can try to overwrite this setting at runtime:

ini_set("session.cookie_httponly", 1);

If it doesn't work, you have to manually overwrite that cookie:

session_start();
$params = session_get_cookie_params();
setcookie("PHPSESSID", session_id(), 0, $params["path"], $params["domain"],
    false,  // this is the secure flag you need to set. Default is false.
    true  // this is the httpOnly flag you need to set
);

setcookie() definition:

bool setcookie ( string $name [, string $value = "" [, int $expire = 0 [, string $path = "" [, string $domain = "" [, bool $secure = false [, bool $httponly = false ]]]]]] )


Is there a widely used protocol which builds on AES/GCM, and defines serialization formats of A, IV, C and T together?

"Additional authenticated data" is whatever you wish it to be. GCM is an authenticated encryption mode in which the inputs are:

a key K suitable for AES (128, 192 or 256 bits);
a 96-bit IV;
some plaintext data P whose length is at most 239-256 bits (i.e. about 68.7 gigabytes);
some additional data A whose length is at most 264 bits (i.e. about 2.3 millions of terabytes).

From these inputs, AES/GCM produces:

a ciphertext C;
an authentication tag T.

For decryption, you need these as inputs:

the key K;
the IV;
the ciphertext C;
the authentication tag T;
and the additional authenticated data A (pay attention ! That's the tricky point).

Then AES/GCM decryption will produce either P (the plaintext), or complain loudly in case one of the parameters has been altered (i.e. the provided K, IV, C, T or A does not match that which was used or obtained during the encryption).

So what does that mean ? That means that an AE system, like AES/GCM, offers the following services:

It ensures confidentiality of P: adversaries who do not know K cannot guess anything about the contents of P, when they see only the other values (IV, A, C and T).
It ensures integrity of P and A: adversaries who do not know K cannot alter the IV, A, C and T values such that the decryption algorithm does not complain. So if the decryption works, then there is a good guarantee that the A and resultant P are identical to what they were when encrypting.

Nowhere in the standard is it specified how the various values should be concatenated, wrapped, or otherwise serialized for transmission. How C, IV, T and A are known to the receiver is completely out of scope, and is up to whatever protocol is using AES/GCM. The values needs not necessarily be transmitted. For instance, if you consider TLS 1.2 (and GCM-specific details): the IV is partially transmitted, and partially inferred (4 bytes from the handshake, 8 bytes with each record); the additional authentication data A is partially transmitted and partially inferred (concatenation of the record sequence number, protocol version and plaintext length); C and T are transmistted in the record body.

Any given protocol which uses GCM may or may not have need for the "additional authenticated data"; this is a feature of GCM: it can ensure integrity over more than the data which was also encrypted. Since both sender and receiver must know the same "additional authenticated data" for the decryption algorithm to succeed, that additional data may have to be transmitted, although it could also, in any protocol (as in the case of TLS), be inferred from context. In any case, that data cannot be recovered from the ciphertext C even with knowledge of the key, which is why it is called "additional".

Therefore, your first question makes no sense. AES/GCM output is not a sequence of bytes accumulating A, IV, C and T. AES/GCM produces two sequences of bits, C and T. Your question should be: is there a widely used protocol which builds on AES/GCM, and defines serialization formats for transmission of A, IV, C and T together ? And the answer to that question is: to my knowledge, no. There are some protocols, but nothing which qualifies as "widely used". In particular, in most cases, at least parts of A will be inferred from context, not transmitted, and the same could apply to parts or all of the IV. This makes it unlikely that a general purpose format emerges and is actually used everywhere.

The answer to your second question (length and contents of A) is: "whatever floats your boat". You don't encrypt and/or authenticate in abstracto, just for the sake of it. You encrypt and authenticate as part of an overall protocol used in a given context which dictates what should be encrypted and what should be authenticated (as is done in TLS).

As for your question about "whether random is sufficient" for the key, then the only possible comment is: I must respectfully ask, Sir, that you drop this keyboard and stop trying to do cryptography. Lest I should use violence.


Is it good to store passwords in a separate table/database and manage them in a separate process?

Hashing being too slow means you need to use a faster hash, not a second process. Try tweaking the parameters on Argon2 or move to bcrypt (which is still really secure). Adjust the parameters to get the hash to a reasonable time (~0.2-0.4 seconds) and keep everything in one process.

If you want, you can still keep the passwords in a second database to reduce data loss if your primary database's contents get stolen, but I am not sure this is needed. Conventional wisdom says that bcrypt is secure even with all data being stolen. Now that is no guarantee, but unless you have the NSA coming after you, or you're storing something valuable enough to motivate large portions of the Bitcoin network to stop miming and start cracking your passwords, I'd be very comfortable with a reasonably performing bcrypt.


What is a good method to report security breaches that are being used to actively spam?

Firstly, "poking around" with a compromised box without prior consent of the owner is not ethical.

The first thing you should do is contact the owner of the site, or the company/ISP who owns the webserver, and provide the URL, date and time of accessing the site, and a description of what you observed as being wrong.

Secondly, in terms of reporting incidents like this, as far as I know, there are no authoritative bodies to whom this should be reported.

If identity theft is involved, however, you can report it to: http://www.ftc.gov/bcp/edu/microsites/idtheft/

Hope that helps.


Have you tried to use other HTTP Method than GET or POST to access the page ?

Some misconfiguration in Apache could lead to accept request using method like PUT for example.

Try this :

curl -X PUT http://www.example.com/flag


The point of strong password hashing functions is to make password processing slow so that attackers find it harder to run a brute force attack on your password. Unfortunately it makes it slower for you too; this is the limit of the exercise. At best, you make the function n times slower for you and n times slower (with the same n) for the attacker; but the attacker can buy some "specialized hardware" (e.g. GPU or FPGA) that, depending on the used function, may allow him to suffer less than you from all the iterations.

So what you want to avoid is a function that increases the computational task more for you than for the attacker. You use a plain general-purpose CPU, probably some sort of x86-compatible PC. The attacker can buy PC, but he can also buy some GPU or some FPGA that may deliver more computing power (i.e. more password tries per second) for the same budget.

Thus, you should avoid SHA-256 and RIPEMD-160, both of which relying on 32-bit integer operations that are remarkably efficient on GPU. SHA-512 would be a better bargain: your PC CPU is rather good at 64-bit operations (either in 64-bit mode, or through SSE2 opcodes in 32-bit mode), while a typical GPU is not. Using SHA-512 will make the task 2 or 3 times harder for the GPU-wielding attacker (he will still gain from using GPU, but not as much as witth SHA-256).

Whirlpool is normally implemented with lookup tables and will probably be quite slow on a GPU (but bitslice implementations should be explored). However, one may expect Whirlpool to map quite well to FPGA (just like AES), so if you fear advanced attackers who don't shy away from using FPGA, then don't use Whirlpool here.

To sum up, PBKDF2/SHA-512 can be said to be your best choice (arguably, it would be better if you could use bcrypt). However, remember that such differences tend to be dwarfed by what you can achieve with a stronger password. Using a high-entropy password is the first line of defence, and more important than the hashing function choice.


Is using a website copier considered active reconnaissance in penetration testing?

Generally speaking anything which sends traffic directly to a company's site is considered active rather than passive.

Now most organisations will realise that traffic to a public facing site is fine and not an attack (as long as it's not excessive enough to cause a Denial of Service) but it is a legal grey area as, for example, a spider could hit content that the company considers non-public and that could cause a response from them.

I'd recommend that while you're practicing you stick to one of the many test applications that can be downloaded for example the OWASP Broken Web Applications Project


Interested in MS in IT/Information assurance. Will my mathematics background be of any use?

First of all, if you had an easy time with the Security+ certification, it sounds like you probably wouldn't have many issues with understanding the basics, and therefore I don't think you should worry too much about your background.

Now, that said, certain branches of mathematics do have direct practical applications in IT/IA:

Any background in statistical analysis is likely to be invaluable, especially for IA.  Risk assessments are a really big part of IT work, not just security related stuff, but even deciding when to replace old hardware, how much redundancy is needed in a given service configuration, and similar things.  It also helps with understanding performance data from software (actually understanding how the data was produced is big).
Basic set theory (more specifically the algebra of sets) is often very useful in reasoning about failure domains, both in hardware, and in software, which is helpful when doing risk assessments.
Information theory is, somewhat obviously, really helpful if you're doing low-level design of software.  It still has practical uses beyond that in designing security policies, but is not as widely used as you might think.

Many other branches of mathematics have much more specific applications, examples include:

Lambda calculus is rather critical if you're writing code in certain programming languages.
Much of high-level computer networking is really just graph theory with some extra stuff on top of it.  In fact, there's such a strong correlation that many networking specialists would have very little difficulty taking a course on graph theory as they already know a decent percentage of it.

Even without any of that though, the foundations in logical analysis and problem solving that studying mathematics gives you are useful even without any other background.


Should I use Windows' Cryptographic Service Provider to generate RSA keys?

First if you're considering creating your own cryptography from the ground up, I sugguest reading the following post since there are many things that need to be considered before just using a PKI/RSA:

  Lessons learned and misconceptions regarding encryption and cryptology

The benefit of using MSFT's crypto system is that the ciphers are covered by MSFT's warranty and have been analyzed by many people.  You may want to ask in Crypto.SE if the MSFT implementation is vulnerable GCD attack

MSFT's implementation also allows for a FIPS only mode that is controlled by GPO.  Using Bouncy Castle ignores this restriction and may cause issues for deployments if operating in a FIPS environment.

The good thing about Bouncy Castle is that it offers a higher-level implementation that covers key formats, PGP, and more.

One last thing to note; RijndaelManaged and AesManaged classes can both be used to generate RSA Keys, however they are not interchangeable.  They are two different implementations of the Rijndael algorithm.  For more information see this answer


What is the purpose of OAuth 2.0 redirect_uri checking?

By not validating the redirect_uri an OAuth provider can be used as an ideal phishing vector.    The redirect_uri is an address used by OAuth providers as a location to deliver the access_token by means of a browser redirect.  The popular OAuth provider Facebook has run into many vulnerabilities relating to OAuth redirection.

In this attack, the attacker presents the victim with a URL to an authentication portal that the victim trusts (like Facebook),  and by using this authentication portal the victim's secret access token is delivered to an HTTP server controlled by the attacker.

Authentication is about intention,  tricking a user into allowing access to an unintended resource is a vulnerability.


In short, they're both crypto key generation tools, but keytool has the additional feature of manipulating Java's preferred key storage file format, the KeyStore.

Java strongly prefers to work with keys and certificates that are stored in a KeyStore (also called a TrustStore when it's only got certificates in it).  It is possible, but not trivial, to get Java to work with straightforward PEM/CER/CRT/PKCS/etc files, so for all intents and purposes if you're coding crypto in Java you're going to use a KeyStore.

Keytool is a tool that comes with Java that works with KeyStores - it can create KeyStores and manipulate keys and certificates inside them.  It can also create keys and sign certificates.  So it is both a key generation and a KeyStore-file-administration tool.

OpenSSL works with standard formats (PEM/CER/CRT/PKCS/etc) but does not manipulate KeyStore files.  It is possible to generate a key and/or certificate with OpenSSL, and then import that key/cert into a KeyStore using keytool, but you can't put the key/cert into the KeyStore directly using OpenSSL.

(OpenSSL also has a wider array of functionality than keytool - performing symmetric encryption, acting as an SSL network client and server, handling more formats.  It just doesn't happen to speak KeyStore.)


Could an attacker spoof a whitelisted IP to access the network?

Nothing prevents an attacker from getting at least one IP packet through to a destination IP address behind a firewall if the hacker spoof's a whitelisted IP address for the packet's source IP address.
SO

The attacker won't get any packets back, because any response IP packets will be routed to the spoofed IP address (where they might flood the network connection for the host with the spoofed IP address); and

Depending upon what kind of packets the attacker is sending using the spoofed IP address and the frequency of these spoofed packets, the firewall might apply security policies that either block or throttle this spoofed packet stream.

e.g. A SYN Flood is a situation where DDoS protection would throttle IP traffic from the spoofed IP address. see Cloudflare SYN Flood
Regardless of what the firewall's security policies are, at least one UDP/IP packet or at least one TCP/IP SYN packet would get through using the spoofed whitelisted IP address.


What is the purpose of the rotating plate in front of the lock?

It's called anti-drill plate.

With the anti-drill rotating plate, the drill bit won't be able to go through the cylinder. It's supposed to be in hardened steel and act as an other layer of security.

When you drill a cylinder lock, you have to go with small drill bit first. You will then use bigger and bigger drill bit on the little hole you made. The plate will prevent you from doing so because the bigger drill bits will just make the plate rotate.

Here is how drilling attack works

Examples:

Euro Profile Cylinder Security Protector
Mila secure handle


Is there such a thing as a "non-business associate contract" for HIPAA related work

The main thing here is to see whether or not YOUR COMPANY have an obligation to be HIPAA compliant. In this case, it would be your customer (that requires the services) that has this obligation and not you as a contractor, since you are merely making a website for them.  They would be the ones that need to do the audits to make sure that they are HIPAA compliant, not you.

Another item to look at is to see the definition of a Business associate and of a Business associate agreement (BAA).  These generally are involved in creating, receiving, maintaining, or transmitting PHI on behalf of a covered entity. Since you are not transmitting PHI then HIPAA compliance does not concern you. If your client asks you to be HIPAA compliant when you are not handling PHI they do not know what they are talking about.

You should also not be looking for something that does not exist (a 'non Business associate agreement').


Preventing remote control "attacks" on televisions, projectors, and set-top boxes

Consumer IR is inherently insecure. And the reasoning for this is quite simple, why shouldn't it be?

Risk Assessment wise:

Can it be easily resolved?
What's the harm done?
What are the costs involved?

Some venues do in fact use flat panels that don't have IR on the front. There's no reason to have it, as there are physical controls. But let's propose that there are no IR control capabilities, then what stops someone from walking up and "changing the channel"? If the need arises, just tape over the IR port, and mount the display out of reach.

Does changing a channel really drastically impact people? Not really, so why would I invest in some high tech solution to prevent people from doing so? Tape and a monitor/tv arm solves the problem quite easily.

Most remote controls you receive for "top boxes", or "cable boxes" have the ability to self program, so the end user only needs 1 control for all their devices. It does this by systematically scanning and trying different codes until the TV or such device turns off. Lists of these codes are public, and can be programmed into a device. There is typically a grouping of codes per a brand (LG, Samsung, etc.).


How does a public key authenticator work? (as opposed to public key signatures)

Skimming the NaCl PDF I think they just generate such a shared secret.

In an interesting fashion:

  Section 5: Alice, using Alice’s secret key a and Bob’s public key B, computes a 32-byte secret k. Bob can compute the same secret using Bob’s secret key b and Alice’s public key A.

Using that shared key they then seed a pseudorandom generator. The first 32 bytes of which are used as the authenticator secret. And the rest of which are used for actual encryption.

DJB's definition

DJB's definition on Google groups:

  What is a public-key authenticator? It's a secret-key authenticator,
  with a key derived from g^xy, where g^x and g^y are the public keys of
  the sender and the receiver.

  If you were already planning to encrypt the message, using another key
  derived from g^xy, then you don't have to do any extra public-key work.
  A secret-key authenticator is easier to implement than a public-key
  signature, and it takes less CPU time to compute.

I guess if he had named it "public-key derived authenticator" instead then the idea might have been more obvious.


Does password "strength" matter anymore?

Ok, let's get things in the right order.

First, you may doing it wrong. This is about what you say about "a bit of a salt". You don't say if you use "we" as meaning "me at my job" or just "we" as in "we Information Security professionals, generally". If it is the former, then it seems that you are using a homemade hashing construction, probably one or two hash function invocations of a hash function with the salt value appended haphazardly somewhere in the mix. This does not bode well. Password hashing is a complex matter, with theory and existing active research and well-vetted candidates. Read this answer.

That being said, let's see your actual question, i.e. are "password strength rules" useful ? To this I must answer: in practice, no. See this previous question. Any constraint is likely to turn the user into an uncooperative user, who will employ defensive mechanisms in order to ease his own life, such as writing down passwords or generating passwords "with a hidden meaning". That's counterproductive: these user behaviours are triggered by the strict password rules and their overall effect is that security is lowered, not increased.

A minimum length can be enforced because a too-short password is unambiguously weak and users understand that. So you do not alienate your own users by enforcing a minimum password length. However, any other rule tends to backfire.

What makes a good password is randomness. Password rules are just ways to push users out of their comfort zone, on the hope that once they are required to put punctuation symbols and letters and digits, then they will, in some unspecified way, begin to "act randomly". This does not go that way in practice. Uncomfortable users are angrier, but not more random.

What can help is to give to the user a non-mandatory password generator which uses randomness. Computers are better at randomness than humans.

(See also this previous question; its answers may illustrate the relationships between randomness, security and usability.)


Arpwatch won't prevent MITM attacks but will just monitor ARP activity and concerning MITM, the ARP protocol isn't the only way to do a MITM (eg : ICMP redirect, DNS spoofing, port stealing, DHCP spoofing...).

But if your goal is to detect host to host ARP poisoning attempts of all your network, yes you have to place an instance on each host. But I think the most efficient way to avoid ARP spoofing attacks is to use static ARP entries.


Avast antivirus virus alarm while programming

Do not turn off your protection. In Avast, just like in most antivirus software, it's possible to add exceptions on a whitelist.

  Quick Summary

  Make sure the blocked file or webpage is not malicious by testing it at www.virustotal.com
  Add it as an exception by going to Settings » General » Exclusions
  Confirm by clicking OK

It should be safe to add the folder where you keep (just) your own software to the whitelist. However, it might be a good idea to manually test the final version before publishing to avoid false positives that may harm your reputation. You could also use the name and description of the dedection to investigate whether your software actually has malware like characteristics.


Where to find current information on cipher suite strength?

Many countries publish Security standards for cipher suited.
In US, you can rely on pci dss standard, fips 140-2, ANSI, EAL, etc.
In France we have the RGS which indicate the algorithms and key length which can be trusted and how many time we can rely on.
I guess every industrialized country has the same standard.
I personally choose to follow this website: https://syslink.pl/cipherlist/
It gathers best Security practices from many sources.


Should I change the private key when renewing a certificate?

I would say that their suggestion isn't a very solid one, unless you're using horrifically small key sizes - in which case you have a different problem altogether.

A 2048-bit key, by most estimates, will keep you safe until at least the year 2020, if not longer than that. If you're running with 1024-bit keys or less, you're below the standard, and I recommend updating to 2048-bit immediately. If you're currently using 1536-bit keys, you should be safe for a year or two.

Of course, this is all academically speaking. The likelihood of someone being able (or inclined) to crack your 1024-bit SSL key within a year is extremely low.

As mentioned in the question you linked, there are benefits and drawbacks.

Benefits

Gives an attacker less time to crack the key. Somewhat of a moot point if you're using reasonable key sizes anyway.
Halts any evil-doers that may have compromised your private key. Unlikely, but unknown.
Gives you a chance to increase your key size to be ahead of the curve.

Drawbacks

Doesn't really give you any concrete protection against key cracking unless you're using terribly small keys.
SSL checking / anti-MitM plugins for browsers might alert the user that the key has changed. This is, in my opinion, a weak drawback - most users won't be using this.
Might cause temporary warnings in relation to more strict HSTS policies and implementations.
It requires work. You could be doing something else.

So on both sides there are some weak reasons, and some corner-cases you might need to consider. I'd lean slightly towards the "don't do it unless you need to" angle, as long as you're using 2048-bit keys or higher.

The most important thing is to ask them why they think it's necessary - it  may be that you have an infrastructure-related reason for updating the keys which we don't know about. If they can't come up with a solid argument ("why not?" isn't really valid) then they should probaly re-evaluate their advice.


Cascading hashes to increase computational difficulty

I'm very confused by your question, because on the one hand you mention bcrypt, a password verification algorithm:

  This question is perhaps not entirely practical, but is inspired by the idea of bcrypt, but without needing to actually implement bcrypt when you have SHA handy.

...but then it switches gears to password generation:

  To put it in context, I tend to use a method of string manipulation and hashing to generate passwords for websites.

But these are unrelated problems, so a solution for one isn't necessarily applicable to the other.

But in any case, as far as I can tell from your explanation, you are proposing a system for generating derived passwords deterministically from these inputs:

A secret master password;
A public identifier for the derived password (e.g., FacebookUserMrFluff);
Some additional public parameters (the word list and the substitutions).

One problem here then is that, because the scheme is completely deterministic, an attacker who is able to get a hash+salt pair for one of the derived passwords (or a plaintext password from a site like any of these) can then mount a brute force attack to recover  your master password.  And if they succeed, they can then compute all of your derived passwords—past, present and future.

Maybe iterating the hash function many times raises the cost of the brute force attack against your scheme.  But why allow such an attack at all?
Compare to this commonplace bit of user-side password management advice:

Use randomly generated passwords of good length;
Store them in an encrypted password manager.

In this case, since the passwords are randomly generated, they're all independent—an attacker who cracks one of them cannot leverage that to figure out any one other password.  An attacker would need to steal your password database to launch a brute force attack against your other passwords—whereas in your scheme they just need a single derived password.

Other than that, if you "have SHA handy" there is already a standard iterated password hashing solution for that: PBDKF2.  So even if you insisted in using this questionable method for generating deterministically derived passwords, there is no need to resort to your odd algorithm.


You're right: missing TLS is a far greater problem than just modifying the login form's action.  Have a look at the full paragraph from the link you provided:

  The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session

As @user2313067 points out, OWASP is addressing a common misconception "that by setting https in the action of the form on an http page, you have no guarantee that the client will receive it unmodified, and it might point to a page the attacker controls. Putting https on subsequent pages but not on the login form only protects you against passive attacks"

Specifically to answer your questions:

Yes, the password is exposed if you fail to use TLS.
Internet traffic is not guaranteed to take any particular route across the Internet - one packet can go one way and the next packet can go through totally different networks. Changing the form action avoids the risk that the victim's password will go over a different network and the attacker won't be able to intercept it. Of course, this is really not necessary to understand why missing crypto is important or the basics of how network traffic interception works; it adds complexity to the particular discussion in question without need. It could be better discussed on a different page. But then OWASP is free, volunteer driven, and doesn't seem to rigorously enforce any real organization to what content goes on what page.
Yes. If network traffic is not encrypted with strong crypto then it can be modified in flight. There are two main ways to do this. First, the attacker proxies the connection between you and the server. You are now talking to the attacker. The attacker can send you anything they want. Second, the attacker sees the response from the server as it travels in the clear over the network and replaces it with their own response. Your computer cannot tell the difference between the valid response and the malicious response so it just trusts the first response it receives. The attacker pays tricks to make sure its response is received first and you get the (part of the) page returned by the attacker not by the server.


The important thing to remember is that, in essence, scammers are operating on their home turf. They get to dictate the payment method, and as a result a (good) scammer will make sure and use a "payment method" that meets the following two criteria:

The transaction cannot be reversed
The payment can easily be converted to cash or used directly

Note that the above criteria are why Western Union is so common in scams: once you send the money you can't ask Western Union for a refund a week later, and on the other end the scammer can receive cash directly. Gift certificates have the same advantages:

You generally can't cancel the purchase of a gift certificate
A scammer can use a gift certificate to buy stolen goods for sale, can sell the gift certificate directly, or even just use it to purchase things they needed anyway (h/t MechMK1)

It's possible that some kinds of gift certificates may be cancelable. It is safe to assume that the scammer knows about the exceptions and avoids them. After all this is how they make money, and in a properly executed scam the victim is going to follow orders. Therefore the scammer will choose whatever is most convenient for them.

It's also important to keep in mind that a scammer may be working more than one "angle" at the same time. For instance a scammer who gains access to a bank account doesn't just send the money to themselves. Instead they may transfer the money to another victim who sends the money to the scammer via Western Union/gift certificates. This way when the bank rolls back the bank transfer (because bank transfers are reversible), someone else is left holding the bag. Similarly a gift certificate may be sold/used quickly or exchanged for cash with another victim and as a result the scammer doesn't care if it is cancelled.

Still, if I were a betting man I would just assume that the scammer has requested payment via non-refundable methods.


Credit card storage, hashes, truncation, encrypted data

On a credit card, you will typically find:

the number, typically 16 digits;
the expiration date (month and year, usually within the next two years);
the card holder name;
the security code (3 or 4 digits).

The trouble with publishing hashes of such information is vulnerability to exhaustive search: the attacker tries all possible combinations, until one matches the hash value. There are two ways to defeat such attacks: by keeping a large number of combinations, and by making the hashing process itself slow.

Slowing the hash requires using a salt (to prevent parallel attacks and precomputations), and making many nested iterations (as much as possible, provided that the overhead is tolerable for your system). There is an art to that; a careless handmade construction may be quite weaker. This part is very similar to what is done for passwords, so let's cut it down to the usual recommendation: use bcrypt. A good GPU can evaluate a 32-bit hash function like SHA-1 about one billion times per second; but by configuring the "cost factor" of bcrypt you can bring such a figure down to, say, 100 times per second, without overloading your own system too much.

Now let's see about the number of combinations. The card holder name can often be guessed, because in a merchant site database you will also record the user name and possibly a delivery address. The expiration date is within the next two years (or so), hence 24 possibilities. The card number usually begins with a 4-digit identifier for the bank, and ends with a checksum digit which is deterministically computed from the 15 others. Assuming the attacker will try, say, about ten distinct banks, you end up with about 1011 (aka "a hundred billions") possible card numbers. However, if the "truncated card number" contains, say, 8 digits (the first and last four digits), that number is reduced to 108 (one hundred millions).

If you use bcrypt and attack can go only at a rate of 100 tries per second, then the attacker will need an average of half a million seconds to find the card number (that's about 6 days). This may be viewed as "sufficient" because the resale value of a stolen credit card number is not high (I think it is around 10$ at most). For increased resilience, do not hash the lone number, add the expiration date (x24 on attack cost) and the security code (x1000).

So, to sum up:

use bcrypt with a high iteration count (and don't fumble on the salt);
put the expiration date and the security code in the hash input;

and you can resist the weakening induced by the storage of truncated card data.


SSH brute force entry in aws ec2 instance

If SSH password authentication is disabled, an attacker should not be able to log in over SSH without possessing the correct private key.

Besides SSH, if there are any vulnerabilities in any other exposed services (e.g. your Flask app), those could potentially be exploited to gain access to your server.


Should I customize my Root CA's thumbprint/fingerprint? (SHA1 or MD5)

This is comparable to ssh's VisualHostKey option for displaying graphical representations of certificate fingerprints.

  Would this increase security for non-trusted root certificates that need manual verification?

There is a risk of creating a false sense of security. If your browser / ssh client / etc pops up saying "Danger danger, untrusted certificate!" but then your only confirmation is to check the first few bytes, rather than the whole fingerprint, you are making your attacker's job a lot easier. All they have to do is generate a self signed cert that starts with those bits.

On the other hand, if the attacker doesn't notice your scheme then you can easily see that it is not your cert.

For a client that displays the fingerprint this is very similar to the situation with VisualHostKeys, but it's easier for an attacker to generate a compliant fake cert.

So: against an attacker who notices this it is going to hurt you more than them; against an attacker who doesn't notice, it's helpful for you.

  What about [certificates that chain back to a trusted root]?

If your client connects with no further user intervention when the cert is validated (e.g. a web browser), I'd say it's not useful. The only way you could tell if you were being MITM'ed would be if you went to look at the certificate info after you'd connected. At this point the attacker already has your secure session cookie, but the odds are you won't carry out this check.

Furthermore, an attacker who has gone to the lengths to get a validly signed cert for your address is highly likely to have looked at the original cert in detail, noticed the scheme and copied it.


Which areas of my computor are at risk if I set up MySQL on port 3306 unencrypted?

Opening a port means that other devices can communicate with your computer on that port, assuming there's a program listening on that port.  It's extremely likely MySQL will be the only thing that ever listens on port 3306 on your computer.

Generally speaking, you are correct that it will only allow an attacker to (potentially) access your MySQL data.  However, if the user they've gotten access to has sufficient permissions, they can directly run arbitrary shell commands on your computer.  Additionally, there are periodically vulnerabilities found in MySQL that could allow an attacker to run shell commands even without this permission.

However, backing up a bit, if you're running Wordpress and MySQL on the same computer, you don't need to open up the port at all.

In short:

Restrict access to the port to only the one computer running Wordpress.
Give your MySQL user accounts the minimum required permissions.
Keep MySQL up to date.


What are the risks of providing my fingerprint to a theme park?

I'm afraid I do not have a good answer, but I do have some thoughts to consider that might help others to find a good answer.

You leave your fingerprint behind everywhere already. However if someone wants to get your fingerprint, they currently have to spend the time and energy to get physically close to you and find a spot where they can lift a good fingerprint off of something. This means it's more expensive to do it for a random person, and it means it cannot really be done on a massive scale.

Phones and other devices these days also have the helpful feature of reading your fingerprint. This increases the odds that someone can get access to a database of them somewhere, and decreases the relative risk of leaving a fingerprint at the theme park.

We seem to be moving towards a society where it's normal to use your fingerprint as identifier. "It's a username and not a password," people say, and in some way they are right. However it's slightly more than a username since it's not trivial (doable without any tools) to lift and reuse a fingerprint, like a username would be. This is why it's so popular as a fairly trusted identification method, like on your phone and as second factor of authentication.

This trend also means that, as fingerprint storage gets more common, they can be trusted less and less. The public perception should trend towards "everyone has a copy of my fingerprint already, who says it's still safe to use as authentication method?" This causes the fact that anyone has a copy to be less of an issue, since it will not be solely relied on.

Some existing answers mention that the fingerprint is probably stored as a code, not as a very accurate picture or representation of your fingerprint, and that different devices would encode it in different ways ("abc" vs. "123"). I think this is partially true: a derived code is usually used in authentication, making it more difficult to recover the original fingerprint. However I would expect it to be a deterministic and at least partially reversible process, where if you know the kind of fingerprint reader, you can reverse the derived code back into something resembling the fingerprint. Further, I'd expect the fingerprint reader industry to converge on the most effective way to read and encode one's fingerprint, removing the need to reverse engineer every fingerprint reader's method individually.

Summarizing:

A database, like a theme park would have, is valuable if you mean to hack an individual at a lower cost and/or if you mean to do so at a greater scale.
Your fingerprint is digitally read in more and more places. As these systems and databases become more frequent, they should become less trusted.
Even though they probably don't store your original fingerprint (easily duplicated), the encoded version can probably be reverse engineered back into something resembling the original. Once done, this can be used for every fingerprint made with that device, or at the very least for everyone ever in the theme park.


Is thread's auto-login from email implementation secure/good user experience?

In my perspective it's probably approximately the same level of security as allowing you to reset your password with only using an email address. Essentially, if you can request a password reset to be sent to you in an email, and one click later you set a new one, it's the same thing.

Now, forwarding such an email contains the same security risks in both scenarios, but honestly, when was the last time you forwarded a password reset email to your friend? In the same way, why would you forward a login email to someone else but yourself?

Also, despite being in the browser's history the link should usually only single-use (i.e. can't use an email from decades ago to reset your password, you have to create a new request). Similarly, when clicking an auto-logon link, the server gives you a cookie and deletes the url token from its side, effectively disabling you from using it twice from two different computers.

Of course, I haven't tested this at all, so it should be taken with salt, but hopefully this is all reasonable enough.


No, RSA by itself definitely does not ensure integrity. (i.e. it's malleable.)

If the ciphertext c = me (mod n) is modified to c1 = c * t (multiplication), where t = xe, then the decryption of c1 will be

c1d = (c t)d = (me xe)d = ((mx)e)d = mx  (mod n)

so the original message got multiplied with a number controlled by the attacker.

A robust system will use something like OAEP padding with RSA to protect against that. Also see here.


WinPcap does not have this ability, but its successor Npcap can capture raw 802.11 frames. When installing, select "Support raw 802.11 traffic (and monitor mode) for wireless adapters." There are more directions in the Npcap User's Guide, but they may not apply to Scapy.

When the network adapter is put into NetMon (monitor) mode, captured packets will have a Radiotap pseudo-header with any available information such as channel, timestamp, signal strength, etc. Not all wireless adapters support this mode; a preliminary list of adapters and their level of support is available on SecWiki.org.


If nothing is listening on a port, no connection can be made to it, firewall or not. The same applies for desktop computers and servers. In theory, you're still safe without a firewall if nothing is listening and the TCP stack in the OS isn't vulnerable.

We have the habit to use firewalls on desktops/servers because they are available and every layer of security helps, but mobile OS developers thought that was unnecessary and are confident in their TCP stack implementation (I suppose a firewall would induce additional CPU load which will decrease battery life).

There is actually a long debate on Serverfault about whether you should use firewalls on servers, you should check it out and make your own choice whether you want to install a firewall on your mobile device.

Also note that most mobile networks out there use carrier-grade NAT which means, at least on IPv4, that your device isn't directly reachable from the Internet and this provides some sort of basic protection (you're still exposes to attacks coming from that same mobile network). Of course this point no longer applies with IPv6.


I'm having a little trouble following you, but here are my initial thoughts: Storing on Flash media has a slightly higher risk due to memory/erase issues. That said, it sounds like you want to secure a container on the usb device rather than use something like an IronKey or Data Traveler. I assume the objection would be with leaving the drive unlocked once mounted since this increases the ability for the key to be compromised?

At the software level, there are two option I would recommend.

Truecrypt: Use Truecryt in traveler mode and store your private keys in a encrypted container you can mount and unmount as you please. You still run the risk of having the stored key exposed unsecured for a given period of time.
Use KeePass or similar. KeePass is a password database, but if you are using the 2.0 branch or a community versions which support attachments, you can use it to store each of your private keys with one database which you take with you on your usb drive. You can then access and cut and paste your keys as necessary. The advantage here is that keepass will timeout and lock up if you configure it to do so. The disadvantage is that you are no longer dealing with a file that is just "sitting there" ready to use. You either need to extract it or cut and paste when its needed.

If you are asking something different let us know and I will adjust my response accordingly.

Update
Based on your comments, I'm not sure if you could get a single devices - maybe you can combine a phone/sms based OTP solution with some sort of physical token / smart card.

Update 2
This post seems similar, I checked through the comments and they are talking about a lot of different options for secure token/card hardware, figured I would just link instead of re-posting so you can determine which options are most useful for you.


How can I determine the Java version running on a remote server?

Are you validating the results or the server? You seem to be confusing the two.

Preventing info disclosure through error messages is a good thing. You verified that is fixed. It doesn't seem to be your job to validate that the Java version is updated (since it appears to be a black-box test), for that, you leave that to the server operator to report on. Make a note that it's no longer obvious what the version is, and encourage the report audience to validate the server to confirm.


Does it make it easier to crack the inner volume if the outer volume has an easy password? (VeraCrypt volume)

In fact, you don't have an inner and an outer volume. You have a standard and a hidden volume. Both are completely independent of each other regarding their encryption (see https://veracrypt.codeplex.com/wikipage?title=Hidden%20Volume).


Like David Houde already said, OpenVPN usually uses a single CA to sign both client and server certificates. In case you have problems understanding how signing/verificating certificates works, you should read Using digital certificates in digital signatures first.

If the client receives a server certificate, he simply checks whether this certificate was signed by the CA he was provided with. If the check succeeds, the server is accepted.

Usually the server certificate also contains a parameter for extended key usage named "TLS Web Server Authentication". This parameter may be checked for by adding the following statement to your OpenVPN config:

remote-cert-eku "TLS Web Server Authentication"

This is used to ensure the server certificate provided to the client is actually what it claims to be. Otherwise another client could possibly identify himself as a server, since the same CA does sign both types.


I propose this solution to answer to my question:

WebCrypto ECDSA keys are really useful, but if we use it as explained in my question (wrapped encrypted with AES-GCM), it's possible for an JS Coder to go on the victim's browser and try thousand of passwords in the JS console to known if it's the good password or not, without any connection to the server. So, it's surely better to not permit to try the password without server interaction. It's why my solution is to only keep the device ECDSA keys, with not extractable private key, not encrypted and global to all users on this device.

SRP is widely-tested and widely-deployed, however in case of DB leak, even if it's difficult to retrieve the user password from brute-force, it's possible because the attacker have the SRP salt and the verifier. So, the best is to not use the user password but a random OTP, and renew it at each successful connection.

Firstly, if the device doesn't have a stored private key:

Generate new WebCrypto ECDSA keys
Send this device public key to the server
The server return a deviceUUID and a sort of JWT for next requests

When user sign up or autorize a new device:

Generate an OTP of 512 random bits
Generate a salt of 128 random bits for the derived OTP
Derive the OTP with Argon2 512 bits, salt=derivedOTPSalt
Generate a salt of 128 random bits for the SRP
Create the SRP verifier for this derivedOTP key
If user have a U2F device, register it for this device
Send to the server the deviceUUID, SRP salt/verifier of the derivedOTP key and the U2F PublicKey. The request is signed with the ECDSA device private key.
If the user registration is accepted by the server, then, request a password from the user for this device
Generate a salt of 128 random bits for the password derivation
Derive the user password with Argon2 512 bits, salt=derivedPasswordSalt
Create a masked key: OTP ^ derivedPassword (XOR)
We save in a user dedied DB IndexedDB/sha256(login) : maskedKey, derivedOTPSalt, derivedPasswordSalt, u2f=(true/false)

Then, when user want to sign in:

Send login and deviceUUID to the server and request SRP/U2F challenges (request signed by the ECDSA private key, like all requests to the server)
If the signature of the device is ok, the server return: challengeUUID, SRP Salt/B challenge and a random text challenge to sign with U2F device (even if we known that the user does not have one)
If the user have a U2F device, sign the challenge or generate random bits (to fool any MITM)
Request the user password for this device and derive it (Argon2, salt=derivedPasswordSalt)
Get the result of stored maskedKey ^ derivedPasswordAttempt (XOR)
From this result (in theory, we get the original OTP), then we derive it with Argon2 / salt=derivedOTPSalt, and create from this the A/M1 SRP challenge answer
We also prepare the next OTP following the sign up method
Send to the server: challengeUUID, U2F challenge, SRP A/M1 challenge and the next SRP verifier & salt for the next OTP.

The server can confirm it's the good OTP, the good ECDSA device signature, and if user have a U2F device the good U2F signature. If all is ok, the server replace the old OTP verifier/salt with the next one, and return an new authorization JWT.

With this solution, even if the DB have been leaked, it's impossible to retrieve the real user password, it's only possible to retrieve the derived OTP, and it's not enough for the attacker to spoof the user identity because he also need the private key of the device (and an possible U2F device).

For a MITM, he can't read user password or OTP, but can read each OTP verifier/salt. Otherwise, it's not enough because he also need the private device key and may be the user U2F device. We also use HTTPS with HSTS+HPKP to prevent MITM attacks.

For an attacker with victim's device access, he can use the private key of the device, and can read salts and the masked key, but this shouldn't help to guess the password, even with brute-force attack on client side, because he need to check if the OTP is ok with a server request.

This solution also reset each time a new OTP after each sucessful authentification. In case of DB leak, we can send a PUSH notification to all users to just ask them to connect to the service, for reseting their OTP.

So, this solution use respected protocols (SRP, ECDSA device keys, U2F verification, OTP, Argon2/PBKDF2) and are mixed to increase the security.

If some peer could review this design to point any point of failure, this could be really appreciated :)


Make a binary copy of your usb stick. In linux you can do this with the dd command. This indeed may take a long time, but in your case there is no good alternative unless you make a separate truecrypt volume somewhere and manually copy files from time to time to there.