What does it actually mean when someone says their website is hacked?

This is a very broad question. The word "hacked" is not very descriptive; a technical person is more likely to describe specifically what happened. Usually "my site has been hacked" is used to mean "My website/webserver is doing something bad/unwanted/surprising."

Here are some ways this can happen:

The attacker gains access to the web server (the operating system or web server application itself). This can be by guessing or stealing the various credentials used by the server administrators (FTP, SSH, SQL, etc etc.)
The attacker manipulates the existing web page to make it do something unintended. This could be via methods like SQL Injection or Cross-site Scripting vulnerabilities. See a more detailed list at the Open Web Application Security Project (OWASP)
The web server is behaving normally, but the user(s) or administrators don't understand what it is doing, and think it has been "hacked". In 2006, CentOS was threatened with "an official complaint to the FBI" by a city manager who mistook an Apache Web Server configuration page for a successful hack.

Please clarify or ask further questions if there is anything you don't understand. It's a very broad topic!


Should I use more than 2048 bits in my SSH-2 RSA Key?

There seems to be a convention of using power of 2 keysizes, it's not strictly required but it seems to be the norm.

The best known way to attack RSA is to factor the modulus to get p and q, once p and q are known it's trivial to reconstruct the rest of the private key. How difficult that factorisation is depends on the size of the modulus.

512 has been factored by hobbyists.
768 bit has been factored by researchers in a public challange.
1024 can probablly be factored now by well-funded orgnisations but noone has publically admitted doing it.
2048 is generally thought to be secure for the time being.
4096 is what the more paranoid go for, especially for long lived keys.

Personally I use 4096 for all newly generated keys.


Has The IE8 XSS Filter XSS Flaw Been Fixed?

The XSS Filter is implemented in IE8 and above.  The issue was addressed in IE8 in MS10-002, prior to the release of IE9 & IE10.


If you aren't using HTTPS then this information could easily be picked up by anyone sitting between you and your server and reused.  If you are using SSL/HTTPS to encrypt the link, then you should be fine.


iCloud Security Concern: browser session authentication storage after 2-factor?

While cookies can be stolen and sometimes used to impersonate an active user, there are several mitigations that can be used such as browser fingerprinting or verifying the IP address of the requests.

By far the best way to keep your account secure is to Log Out when you're done with your session. On a properly implemented system this will invalidate your session on the server side, so even if the cookie is stolen it it no longer works.

2 factor authentication is a great way to protect yourself on a public computer. The only real concern is that an attacker could use your account before you log off, or what you're doing during that session could be snooped on if the computer was compromised.

Edit: One last thing. These cookies are marked in a manner as such that the browser will only send them over a secure (TLS/HTTPS) connection so they aren't intercepted by monitoring the network.


How to connect sensors such as Snort to AlienVault SIEM?

For OSSEC you can generate new keys for every agent that will be reporting to the OSSEC server installed in the OSSIM server (check Analysis | Detection | HIDS)

For Snort, the most easy and recommended way is install an OSSIM sensor profile, that comes with the Snort up and provides you the new rules using the command alienvault-update

But if you are not interested in that, because you have a Snort installation working, you can send the unified2 logs to the OSSIM server using rsyslog, and check in the snort.cfg that the directory var is pointing to the correct place.

This issues are explained in the User manual: http://communities.alienvault.com/community/technical-documentation


Could somebody explain connect loop DoS?

This vulnerability forces your proxy to go into an infinite loop, causing a DOS because of exhaustion of local resources like CPU, RAM or any other resource.

The reason that it would go into infinite loop is because basically all you're proxy is doing is forwarding requests to someone else. What happens when you tell your proxy to forward the request to itself? It would receive the request, forward it to himself, receive it again, forward it to himself again and so on.

Now at first this may not be a big problem with just 1 request looping, however if you send thousands of proxy connections like these it will build up as a problem really fast.

The same thing could be done in internet routing protocols if it had not been for the TTL (Time to live) flag in the IP packets. According to rfc2616 you're proxy should not forward requests if Max-Forwards field is set to 0.

To reproduce this you would create a HTTP packet looking something like this:

  CONNECT <proxy connection>:80 HTTP/1.1
  Host: <proxy connection>:80


Application used in health industry: HIPAA HITECH hosting "requirements"

You are not off base on your assessment. Putting PHI in the cloud means that that provider is now responsible for compliance. They now play an important part in the chain of custody of the PHI.

BAAs are required in as much as if you use a cloud provider and don't have an air-tight BAA, you're on the hook for the risk. Think of the chain this way:

Hospital (Covered Entity) <-> You serving the hospital (BA) <-> AWS

You likely have a BAA with the hospital where you took on all the technical risk of handling the hospital's PHI. But AWS is a critical part in the chain that is handling the PHI. If you don't have a BAA with AWS, you are not handing off the compliance risk to the party who is actually responsible. For example, if for some ungodly reason a major data center was broken into and hard drives are stolen, YOU are on the hook if you don't have a BAA.

However, note that all public clouds only cover a very small fraction of compliance in totality. The translation is "chain of custody" to "Shared Responsibility Model". Here is AWS's: https://aws.amazon.com/compliance/shared-responsibility-model/

So, for example with AWS, they only cover about 1/10th (physical safegaurds, firewall). Their BAA doesn't take on other controls like encryption or logging or disaster recovery.

If you want use the cloud, you should investigate a company like Datica, which I work for. Companies like that who sit on top of public clouds will maintain and take on the risk of the other 9/10ths so to speak. This resource you might find valuable to explain the concept.


How is iptables useful to prevent attacks against a LAN?

IPtables won't detect a successful Ettercap attack. Ettercap is used for ARP cache poisoning, CAM table flooding - it's a layer 2 attack tool to perform network sniffing via exploiting issues/vulnerabilities on switches. See this tutorial for some examples.

To be honest,  think the question is a little generic and maybe dated. Folks don't generally test firewalls per se but instead, how to bypass firewalls to get to the PII behind.

IPtables is a firewall so it generally has all the advantages and limitations of most firewalls. It comes in handy (to paraphrase you) when you need to lock down your host or hosts behind your iptables firewall to restrict access to/from only allowed ports/services and IP addresses. It can also be used to throttle or mangle traffic. Here's a couple of links on testing firewalls that should give you an idea -

Marcus Ranum
SANS


I've found out the answer I was looking for, although there is no way (that i know of) of displaying other codes because I don't present the database information in anyway. still it is possible to bypass the security verification by using a simple ' or ''='. My solution for this was adding complexity layers to the type of codes my program accepts, for example, I am using a GUID and I know it has 36 chars on length 3 hashes (-)... and a code that does not present this characteristics is not allowed to interact with the database at all.

Check this awesome answers for more on-topic information.


Is it safe to include an API key in a request's URL?

Summary: capability URLs are more secure than many people give them credit for, but not suitable for all applications, and require extra care to use.

These type of URLs are commonly known as capability / secret URLs.

It's meaningless to talk about security without specifying a threat model. Here are a couple that come to mind:

1: A passive attacker on the network (eavesdroping)
2: An active attacker on the network (can change packets at will, mitm, etc)
3: A shoulder-surfer
4: An attacker with physical access to your computer / elevated privileges
5: another user of your computer (regular privileges / remote access)
6: the user itself (as in protecting a API key)

Regarding network attacks (1 and 2), secret URLs are perfectly secure, provided you're using HTTPS (it's 2016, you shouldn't be using HTTP anymore!).

While the hostname of a server is sent in plaintext over the network, the actual URL is encrypted before being sent to the server - as it's part of the GET request, which only occurs after the TLS handshake.

Regarding shoulder-surfing (3), a secret URL with enough entropy is reasonably secure against a casual attack· As an example, I'll give a google docs URL:

  https://docs.google.com/document/d/5BPuCpxGkVOxkjTG0QrS-JoaImEE-kNAi0Ma9DP1gy

Good luck remembering that while passing by a co-worker's screen!

Obviously, if your attacker has a camera and can take a picture without being noticed, it's an entirely different matter - you shouldn't use a secret URL in that situation. You can mitigate the attack by doing a HTTP redirect away from the secret URL, so it's only on screen for a few seconds

Regarding an attacker with elevated privileges on your computer (4), a secret URL is not less secure than a long password or even a client-side TLS certificate - as all of those are actually completely insecure, and there's not much you can do about that.

An attacker with regular privileges (5), on the other hand, should not be able to learn the secret URL as well, as long as you follow good security practices for your OS. Your files (particularly browser history) should not be readable by other users.

For protecting API keys (6, which was the point of this question), a secret URL is also no-less-secure than another mechanism (such as an AJAX POST). Anyone that has an use for an API key will know how to use the browser debug mode to get the key.

It's not reasonable to send someone a secret and expect them not to look at it!

Some people have asked about the risks on the server side.

It's not reasonable to treat server-side risks by threat modelling; from a user perspective, you really have to treat the server as a trusted third party, as if your adversary has internal network access on the server side, there's really nothing you can do (very much like a privileged attacker on the client's computer, i.e. threat model 4 above).

Instead of modelling attacks, I'll outline common risks of unintentional secret exposure.

The most common concern with using secret URLs on the server side is that both HTTP server and reverse proxies keep logs, and the URL is very often included.

Another possibility is that the secret URLs could be generated in a predictable way - either because of a flawed implementation, a insecure PRNG, or giving insufficient entropy when seeding it.

There are also many caveats that have to be taken into consideration when designing a site that uses secret URLs. This page by W3C TAG covers many of them.

In practice, for sites with dynamic content, it's quite hard to get everything done securely - both Google and Dropbox botched it in the past, as mentioned on this answer

Finally, secret URLs have a couple of advantages over other authentication methods:

They are extremely easy to use (just click the link, as opposed to entering your email and password)
They don't require the server / service to securely store sensitive user credentials
They are easily shareable without risks, unlike sharing you password (which you reuse for 50 other sites).


Modern packers will handle this in the same way as the Windows PE loader: by implementing relocations.

The .reloc section in a PE file (documentation here) holds details about which addresses need to be “fixed up” if the image cannot be loaded at the preferred address. This is referenced in the standard PE header.

A packer can read this data and implement relocations. How the packer handles this will be implementation specific. Perhaps it will store the original relocations somewhere in the packed executable, or store them in a custom format.

It is also possible to strip relocations, leaving a PE file that is not ASLR aware, as if it were never compiled with /DYNAMICBASE. A packer could choose to do this instead of implementing relocations.

There is a question about UPX on StackOverflow and a common fix during analysis is to simply disable ASLR (reference 1 / reference 2).

You can read a lot more details in this ReverseEngineering.SE post about the layout in the PE section.


How to identify which root CA does the client certificate use?

Yes.  The Issuer field in the x509 certificate is used to specify the Subject of the next certificate up in the certificate path.  If you continue to recurse up the certificate chain, you'll eventually arrive at the Subject name of the root certificate.


What Information is Exposed When I Send A Message From My Mobile Device

this would totally depend on the specific application you are using to send the message.  A text message is going to expose different information than a message sent through a private app such as 'whatsApp', or 'Skype'.

Typically For messaging apps the end recipient will at least have your cellphone number, time the message was sent, content, and potentially location (depending on the app).  Emails contain the IP address which sent the message in their headers.  Since you are on mobile though, the IP assigned to your device might not be a great indicator in terms of geolocation.  I've seen mobile phones geolocate their IP to a neighboring state.

With the exception of emails, most messaging apps don't let you see the behind the scenes headers (even if you're sniffing the network).  Only the app/service provider might have access to that.


What is the recomended algorithm to create a key from a password?

Some of the popular options for this are PBKDF2, bcrypt, and scrypt. A related answer has plenty of good info. The gist is bcrypt is better than PBKDF2, but either would be fine and secure. scrypt looks promising, but is quite new, and in the world of cryptography, we often default to the tried and tested unless absolutely necessary. See the answer I linked to for attacks against which scrypt is better than bcrypt.


Drupal filters XSS with regexes. What could bypass it?

See Is Drupal's filter_xss enough for filtering HTML?, which has some discussion of the security of Drupal's filter_xss().  Make sure to read Mike Samuel's analysis, which identifies a number of shortcomings of filter_xss().  I don't know whether you would classify them as vulnerabilities, exactly, but they are design flaws/shortcomings that could make filter_xss() less effective than developers might expect.

The developer documentation for filter_xss() is atrociously bad.

There's a sum total of two sentences: "Filters HTML to prevent cross-site-scripting (XSS) vulnerabilities." and "Use check_markup or filter_xss for markup containing text.".  When the documentation doesn't explain how to use filter_xss() properly, you shouldn't be surprised if developers fail to use it correctly.  This could lead to vulnerabilities, e.g., of the sort that Rook identifies.

(Drupal also has a document entitled Handle text in a secure fashion, but it doesn't even mention filter_xss().)

I would also suggest that anyone who calls filter_xss() should make sure not to include !-- in the list of allowed tags.  The code for validating comments (which is enabled if you add !-- to the list of allowed tags) looks super-sketchy to me: it doesn't do anything to validate the contents of the comment, which intuitively feels like it can't possibly be safe.


Why doesn't the TLS protocol work without the SSLv3 ciphersuites?

I presume from your ssl.conf setting that you are using the mod_ssl module from Apache web server. This module relies on OpenSSL to provide the cryptography engine.

From the documentation on OpenSSL, it states:

  Protocol version: SSLv2, SSLv3, TLSv1.2. The TLSv1.0 ciphers are
  flagged with SSLv3. No new ciphers were added by TLSv1.1

You can confirm the above by running the following command:

$ openssl ciphers -v 'TLSv1' | sort
ADH-AES128-SHA          SSLv3 Kx=DH       Au=None Enc=AES(128)  Mac=SHA1
ADH-AES256-SHA          SSLv3 Kx=DH       Au=None Enc=AES(256)  Mac=SHA1
ADH-CAMELLIA128-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(128) Mac=SHA1
ADH-CAMELLIA256-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(256) Mac=SHA1
...

This means that if your configuration file excludes ciphersuite SSLv3, you are effectively removing support for TLSv1.0 too! That leaves you with ciphersuite TLSv1.2 only since support for SSLv2 has also been removed:

$ openssl ciphers -v 'ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:!MEDIUM:!LOW:!SSLv3' | sort
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
...

From the above, it is not hard to see why you should NOT remove SSLv3 from the ciphersuite. Disabling SSLv3 protocol is more than sufficient to protect your clients from POODLE vulnerability.

The error message you are experiencing is likely because you are using older browsers such as Firefox < 27.0 or Internet Explorer < 11.0 as these versions do not support TLSv1.2 by default.


What are the best practices for mitigating zero day attacks?

Holistic SDL.

By definition, you can't defend against a specific attack that you don't know about beforehand.
However, if you implemented a complete, Secure Development Lifecycle through all the phases, including appropriate Threat Modeling, and you mitigate the threats (not the attacks) - then you should be relatively okay.


Can someone detect the URL an android app uses?

HTTPS (i.e. SSL/TLS) encrypts all HTTP communication including the entire URL. HTTPS does not protect the domain name as this is sent to the DNS in the clear, but it does protect the rest of the URL. Other apps don't have access to your app's SSL/TLS encrypted traffic including URLs. So as long as the SSL/TLS connection is setup securely an attacker won't be able to obtain you URI from the traffic.

But from the last sentence you wrote ("I know how to obfuscate and hide the URL in the code, so it can't be seen by decompiling the app") I understand that you need to protect the URL against an attacker who has full access to the device (e.g. the owner of the device). In this case you can't rely on SSL/TLS connection being secured as it's possible for the atttacker to install his on CA certificate on his device. This completely nullifies the security of SSL/TLS, as the attacker can impersonate your server and perform a man-in-the-middle attack - just like Alexey V. Borodin's hack on Apple in-app purchases. Even if you use a hardcoded SSL certificate the attacker can root the device and modify the O/S to output all SSL/TLS communications in the clear. So HTTPS will not protect your URIs from an attacker running your app on his own device.


The historical password hashes are stored in the SAM along with your current one, so are certainly equally breakable.

I used to run password strength audits for large financials, and part of the output would be analysis of the number of individuals who reused passwords with just a change to the final digit (guess how large a percentage does it!) PWDump and John the Ripper zapped through them quite happily:-) In fact you could get some benefits from the password history that could help you break ones the brute forcer wouldn't get to easily.

To flush these historical hashes, you could try to set history to 0 in security settings and enforce a password change. That might do it, but I don't honestly know. In any case this totally defeats your password history policy if you're hoping to maintain one.


Using a symmetric password-based encryption scheme on the keys. Where you have to "enter your passphrase" before you are allowed to use the key. Since the passphrase is used to decrypt the actual key.

Most of the security concerns about the usage of passphrases are discussed here: Security of passphrase-protected private key


Do 2 Chip based cards effect each other's data if they are in the same wallet all the time?

No. To work the chips in the cards need power - which is provided by the reader (in the case of contactless payments this is done wirelessly).

I'd imagine if its a new card its most likely a manufacturing error. If these are physical transactions failing as opposed to contactless it is also worth checking the chip terminals are clean - i.e. there is not something either blocking the chips contact with a reader or shorting out two of the connection terminals.


What encryption method is used by the zip program in macOS?

It's using the original PKZIP 2.0 encryption (variously referred to as "traditional" or "legacy" encryption), described in section 6 of the .ZIP file format specification. It's based on using CRC32 to mix the password, a (hopefully) random seed, and the compressed file. It is not considered secure; at the very least, it has serious vulnerabilities to known-plaintext attacks (see this crypto.se answer for a summary).
Update: Michael Stay developed a better attack in order to recover some Bitcoin private keys for a client. Details in Michael's blog post and DEF CON talk, and coverage at Wired and Hacker News.
This is based on: looking at Apple's source code for ZIP. The README.CR says:

The encryption code is a direct transcription of the algorithm from
Roger Schlafly, described by Phil Katz in the file appnote.txt.  This
file is distributed with the PKZIP program (even in the version
without encryption capabilities).  Note that the encryption will
probably resist attacks by amateurs if the password is well chosen and
long enough (at  least 8 characters) but it will probably not resist
attacks by experts. Paul Kocher has made available information
concerning a known-plaintext attack for the PKWARE encryption scheme;
see http://www.cryptography.com/ for details.)  Short passwords
consisting of lowercase letters only can be recovered in a few hours
on any workstation.  But for casual cryptography designed to keep your
mother from reading your mail, it's OK.

Note that the file says was last updated in 2008, so when it talks about password recovery "in a few hours on any workstation", it's talking about decade-old hardware. I'm slightly confused about what version of Zip Apple is actually using. README.CR seems to indicate it's v2.31, but WHATSNEW lists new features in Zip v3.0 beta (and says AES is planned for v3.1). In any case, it's pretty old.
As further support, the file crypto.c (while a bit hard to follow) is clearly using CRC32 for the encrypt/decrypt processes, and the only mentions of AES are in several files that say it's planned for a later version.
Oh, and I also tried creating an encrypted file with it, and then looked at a hex dump. It doesn't contain 0x0017, which is the header ID for a "strong encryption header". It does have an extra 12 bytes of seed data (part of the "legacy" format) along with each file. So that matches the source code and README.
Summary: don't use it. I'd look for third-party Zip utilities that support more modern encryption, but I'm not familiar enough with any of them to make recommendations.


metasploit: how do I force build database cache

If you get a "[!] Module database cache not built yet, using slow search" error after updating. Once you disconnect the database connection, you can try to reconnect db.

 1. msf > db_status
 2. msf > db_disconnect
 3. msf > db_status
 4. msf > db_connect user:pass@127.0.0.1:5432/dbName
 5. msf > db_rebuild_cache
 6. msf > db_status
 7. msf > search xxx

You can try version command maybe help

msf > version


As rook said, you should report the fake account to the service provider.

Apart from that I would suggest that you read this little article about social networking site privacy. Then, consider protecting yourself against similar incidents in the futureby Improving your privacy on social media.

Since you've mentions images from your Instagram account were used, consider securing your Instagram account.


It depends. If you guess A correctly but get B incorrect, does the system tell you that A is correct? If yes, then it's A + B and the average number of guesses it takes is (A + B) / 2. If you don't see which one was wrong, the entropy is A * B and the average number of guesses is A * B / 2.

To show why, consider this example: A=4, B=2. If we try the options sequentially and know which is correct, it would go like this:

A=0, B=0 A ERR; B ERR
A=1, B=1 A ERR; B ERR
A=2, B=2 A ERR; B OK
A=3, B=2 A ERR; B OK
A=4, B=2 A OK; B OK
(5 attempts)

If we don't know which is correct, it would go like this:

A=0, B=0 ERR
A=1, B=0 ERR
A=2, B=0 ERR
A=3, B=0 ERR
A=4, B=0 ERR
A=5, B=0 ERR
A=6, B=0 ERR
A=7, B=0 ERR
A=8, B=0 ERR
A=9, B=0 ERR
A=0, B=1 ERR
A=1, B=1 ERR
A=2, B=1 ERR
A=3, B=1 ERR
A=4, B=1 ERR
A=5, B=1 ERR
A=6, B=1 ERR
A=7, B=1 ERR
A=8, B=1 ERR
A=9, B=1 ERR
A=0, B=2 ERR
A=1, B=2 ERR
A=2, B=2 ERR
A=3, B=2 ERR
A=4, B=2 OK
(24 attempts)


There is something funky about this script.

('https:' == document.location.protocol ? 'https://pi' : 'http://cdn') + 'pardot.com/pd.js'

This expression produces the urls pipardot.com and cdnpardot.com which appear to be registered to not pardot.com. The script is bad, and wherever you got the script from is also bad.

It may also have been good from the original source, but edited by another exploit on your web server.


Modify C code with buffer overflow vulnerability to skip code

As you have already identified you will need to return to address 0x400631. When you smash the stack with your argument you should control EIP. Ie:

./a.out AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

You should see EIP of 0x41414141. Now you need to determine where in your stack of A's the 4 bytes that becomes EIP are located. You can use tools like metasploit's pattern_create.rb/pattern_offset.rb or since it's such a small buffer you can do it manually:

./a.out AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQRRRRSSSSTTTT

And based on the address of EIP you can now determine if it's A (x41),B (x42),C (x43), etc. This will tell you how many bytes you need to place before \x31\x06\x40\x00. This is of course not a reliable exploit as the return address is hardcoded, but it will suffice for your learning example.


Is there more risk in changing administrator password locally vs from a centralized location?

I did come up with a couple potential additional attack vectors.

A lot of languages use a date / time stamp for setting up their random number generators. This results in getting the same 'random' password for all tasks executed in parallel. A potential fix is here.
On the interface / on the wire capture of account / password details. This can be mitigated with IPsec.

Depending on implementation either of these could allow either lateral or vertical privilege escalation.


This is quite a broad question but here is one way you could possibly do it,
you could use autopsy over the full sleuthkit as it is really just a wrapper for the sleuth kit but a heck of a lot easier to use.

Next index your target disk (assuming it is coming from a hard disk) and you can then regex query your index from the autopsy using things like .doc or whatever.


ECDSA implicit certificate using OpenSSL

Implicit certificates are a concept. Certicom's Web site contains a high-level description. A mathematical incarnation of that concept, called Elliptic Curve Qu-Vanstone (ECQV), has been proposed. the Wikipedia page includes a rudimentary description, and there is a 2013 standard from SEC that includes more details. That standard is still highly mathematical in contents and does not specify encoding details. As of 2011, it seems that there was no reference implementation at all. OpenSSL does not support ECQV.

What OpenSSL supports is generic operations on elliptic curves. From these functions, implementing the operations that constitute ECQV would be "easy" (not really easy). However, to do that properly and securely, you have to understand what is going on, i.e. you must grasp the maths in all their fine details. To implement ECQV, you should be able to, at least conceptually, make everything from scratch, starting with a basic programming language such as C -- in that sense, OpenSSL's code will save you "implementation" time, but not "understanding" time.

A big part of implicit certificates, like in any PKI system, is management procedures. Low-level implementation of the algorithms is the easy part. If you intend to use implicit certificates, you should dedicate some (most) of your time thinking about CA management.


There are a few things you can do to mitigate the risk:

Try to upload the files to a path outside your webroot

For example, if you host your site on /var/www/myserver/html, make your PHP upload script write files on /var/www/myserver/data.

This way, a Local File Include will not work, as the sent files are outside the server root.
Don't use Mime Type or file extension to determine the file type

It's easy to forge Mime Type and file extension. Instead, use PHP Fileinfo functions to identify the file.
Don't store the files with the original filename

Always rename the file to something unpredictable, like a hashed salt. Doing this makes harder to an attacker to predict and use the file he just uploaded.
Make sure your error messages are not leaking data

If your error message says File webshell.avi not found on /var/www/myserver/data, you are leaking precious information. On a production server, don't enable error reporting, or send them to you, not the client.
Use a script to read the files and send the data to client

Don't link direct to the files, but have a script read them instead. This way you can sanitize the data before sending, and the raw files will not be processed by your server.


Password entry: are "paste from password manager" and "eyeball to view passwords" mutually-exclusive features?

Password managers are not meant to hide your passwords from yourself
It's as simple as that. To whit: most password managers let you view your own password anytime you want anyway. I say "most" only because I haven't used them all. I've worked with a few sites where auto fill doesn't work for reasons outside the password managers control. Therefore viewing/copying your own passwords is a necessity.  IMO a password manager that doesn't let you view your own secrets is a broken password manager.
If you can use the password manager to view your own password, then an individual site that refuses to display a password at the user's request in an attempt to hide their password from themselves has grossly missed the bigger picture.
Some people use password managers, some don't
The ability to paste is very helpful when using password managers. The ability to view as you type is helpful for people who are typing their passwords (especially on phones). These are two different features for two different groups of people, both of whom can be expected to use a given site. Therefore to say you only need one of these features at a time is just silly...


API Key via Basic Auth: Send it as a username or as a password?

The answer to your question will be opinion based.

In my opinion, the password should confirm that the requester is really the owner of the user ID he sent in the request. If one would treat API as a password, what user ID would it confirm? That's why I treat API in such scenario (Basic Auth) as a user ID. And this user ID is so secret that knowing it already allows you to use it, without additional password.

No matter how you treat it, non approach is ideal. Normally as a developer you will need a user ID (or some information that points to user ID) for at least two purposes:
- For logging, e.g. to analyze which user produced what load, or which user uses particular API end points
- For accounting: If in your business model you sell particular number of API calls or some volume of resources, you have kind of counters or other indicators, that show how much of the purchased resources the user has used so far. For this you will need a user ID.

Logs and indicators ideally should not contain sensitive information. When you use API key, that would be not good. So you may need some technical ID in your database, so that you map API key to a technical ID and use this ID in logs, for accounting and similar purposes.


Anonymity of session hijackers using dsploit

You have to look at the packets and monitor the activity on the network. With wireshark or tcpdump, netcat, tcpflow. You can play around with a lot of tools.


Java code can invoke native code (e.g. code written in C or whatever, and compiled to a sequence of CPU opcodes) through a standard interface. Java can actually write a DLL file somewhere (as a bunch of bytes) and load that, so everything native code can do, so can Java.

Java also features a rich standard library which allows it to read and write files in arbitrary ways.

The hard parts for Java-based malware are:

A Java VM is needed. Java is not installed by default in many modern operating systems.
The Java VM tends to sandbox Java applets. To run native code or access arbitrary files, a Java applet must ask for permission, which entails digital signatures and certificates which may be tracked back to the perpetrator. Or a specific sandbox escape bug must be exploited; such bugs are discovered regularly, but they are also patched with commendable alacrity.
The existing Java VM implementations are fat. They are optimized for big applications which will use lots of RAM anyway, so any Java code has a large minimal memory footprint. Malware usually prefers inconspicuousness.
Java VM implementations come with extensive debugging tools which allow plugging into a running VM and inspecting what happens in it. This may help in cleansing a Java-based malware infestation.

These are reasons why Java will not look as the best language ever to malware writers. Also, even if Java is nominally portable, cross-platform malware is an elusive goal, because malware tends to do things at a quite low level -- that is, a level which is very OS-specific. Modifying the /etc/passwd file is a very naughty thing to do on a Unix-like system; but it would have no impact at all on Windows, which does not have an /etc/passwd file. Thus, there is little incentive for malware authors to use Java.

(All of this would apply almost unchanged to a question about writing malware in C#/.NET + SilverLight.)


See this answer.

The main point is that we make a sharp distinction between obscurity and secrecy; if we must narrow the difference down to a single property, then that must be measurability. Is secret that which is not known to outsiders, and we know how much it is unknown to these outsiders. For instance, a 128-bit symmetric key is a sequence of 128 bits, such that all 2128 possible sequences would stand an equal probability of being used, so the attacker trying to guess such a key needs to try out, on average, at least 2127 of them before hitting the right one. That's quantitative. We can do math, add figures, and compute attack cost.

The same would apply to a RSA private key. The maths are more complex because the most effective known methods rely on integer factorization and the involved algorithms are not as easy to quantify as brute force on a symmetric key (there are a lot of details on RAM usage and parallelism or lack thereof). But that's still secrecy.

By contrast, an obscure algorithm is "secret" only as long as the attacker does not work out the algorithm details, and that depends on a lot of factors: accessibility to hardware implementing the algorithm, skills at reverse-engineering, and smartness. We do not have a useful way to measure how smart someone can be. So a secret algorithm cannot be "secret". We have another term for that, and that's "obscure".

We want to do security through secrecy because security is risk management: we accept the overhead of using a security system because we can measure how much it costs us to use it, and how much it reduces the risk of successful attacks, and we can then balance the costs to take an informed decision. This may work only because we can put numbers on risks of successful attacks, and this can be done only with secrecy, not with obscurity.


If a system is updated, does that mean metasploit framework cannot penetrate the system?

Metasploit exploits different classes of vulnerabilities such as buffer overflows (stack, heap etc), default credentials, human weaknesses (such as clicking or downloading a binary executable etc), or interacting with a privileged interface that is not properly protected through authentication. Not every class of vulnerabilities can be mitigated through updates.

However, keep this in mind that updates do provide a real defense against a lot of remotely exploitable vulnerabilities and must be applied as soon as released by the vendor (especially in case of personal systems).


There are just too many unknowns to provide a clear answer to this question. The answer also depends a lot on your threat model - who exactly are you trying to protect yourself against? Family members and roommates? Strangers at Starbucks? Your Internet provider? Google? Government agencies? The important considerations will change heavily depending on what you consider to be your primary threat.

  Generally speaking - If android devices are vulnerable in terms of
  privacy and security

It sounds like this is just an assumption you're making but I think it also requires more elaboration. Is there a specific Android device you are referring to? An old and unpatched Android device from an unreputable manufacturer will likely have as many security holes as swiss cheese, indeed. But a fully up-to-date device that is actively supported by a reputable company (e.g. Google's Pixel line) is arguably more secure than the majority of other devices you'd use on a regular basis - including Windows and Linux computers. Android devices do have significant privacy drawbacks in terms of the amount of data they share with Google, but it is unclear whether Google is part of your threat model or not.

  Does Mifi devices, all these jetpacks any better than a smartphone for
  security and privacy?

Keep in mind that Mifi devices run software too - very likely based on some form of Linux. That software may be old, unpatched, or poorly written just like any other software. So whether a Mifi device would be more secure again comes back to the specific device you are using and your threat model.


Why is there no spectre local root exploit in circulation?

As mentioned by J.A.K - the exploit (Spectre) is a way of gaining read-only access to the memory. The reason there is no exploit for privilege escalation is that that isn't what is happening in Spectre. Both Spectre and Meltdown by nature are simply just information leaks.


Ways to impress children about web privacy violations and concerns

Here is an interesting article about a teacher showing the dangers of posting images on social networking sites. May be worth doing your own experiment.

You could also use BeEF to demonstrate some client side attacks. This would be interesting to put the hook in malicious ad JavaScript. Hope this helps, good luck!

Additionally, there is a pretty cool website What Every Browser Knows About You.


iptables rule to ban and redirect malicious traffic

The Majestic project is a distributed web crawler, which explains why you get such a lot of different source IP addresses. It is not malicious, that is it does not attack your site and it does not even uses lots of resources (800 requests a day is not much).

Like most proper bots Majestic even includes a URL in the user-agent string and if you visit this URL you will find topics like "How can I block MJ12bot?". This topic explains how you can block this bot in a sane way and I recommend you follow the advice there. Note that this bot is not something special, it follows the same rules as most of the the others innocent crawlers like the bots from google, yahoo, bing etc.

Apart from that, your idea to block based on the source IP of the request is not only useless in this case but actually harmful because it will exclude innocent users from your web site. These requests for this distributed crawler are done from the computers of volunteers like home users. You could see this if you would reverse lookup some of the IP addresses, e.g. 91.179.245.81 resolves too 81.245-179-91.adsl-dyn.isp.belgacom.be.. Thus if you would block the whole /24 network for this IP address you would exclude lots of users from this ISP.


Does knowing the file type of an encrypted file make it easier to decrypt?

For practical purposes, no.

Against good crypto, using modern ciphers and making no major mistakes such as a padding oracle or ECB mode or other weakness, it doesn't really help. It can theoretically act as a test for whether you brute-forced the key correctly - does the decrypted file contain the right magic number and data format? Good, you got the right key - but actually brute-forcing the key should be impossible for any modern widely-used cipher (even the weakest form of AES, with 128-bit keys, would take centuries for even a nation-state to brute-force, even assuming Moore's Law continues on course; using only modern hardware it would take many orders of magnitude longer).

Of course, people do make mistakes in crypto, and some ciphers that were once thought strong are now known to be vulnerable.

If you know that the file was encrypted in a particular way, and you know of a weakness in that method, then you can attempt to exploit that weakness. This might be made easier by knowing the file type, as some files are generated by software which nominally supports encryption but implements it very weakly, and knowing that the file is of that type will suggest you might be able to try such attacks (though it won't help you if the file was encrypted using some other tool that implements the crypto correctly).

The ECB (Electronic Code Book) block cipher mode of operation mentioned above encrypts every block (typically 16 bytes for modern ciphers; historically often only 8 bytes) using the same algorithm (for a given key), no matter where it is in the message. This means that if you break the message (or any number of messages, if they were all known to be encrypted using the same key) up into blocks and find two identical blocks, you'll know they're the same plain text. If you find such duplicates and know at least some of the plain text of one of them, because you know at least part of the data of the file (due to knowing its format, or for other reasons), you now know the plaintext for the same part of the other block. This can also be useful when you know the data format in general even if you don't know any specific bytes in it, especially if it's low-entropy data such as a simple image file; see the link above for a striking example of taking a bitmap image, encrypting it using ECB, and the ciphertext (if rendered as a bitmap) still largely revealing the content of the image.

There are other attacks that are less likely to be relevant here, but might be relevant in other situations. For example, if you can get the same data encrypted many times using the RC4 (sometimes called ARC4 or ARCFOUR) stream cipher, you can exploit biases in the "key stream" (the bits generated by the pseudorandom function that a stream cipher is) to slowly decrypt the data; this is why RC4 is no longer trusted for use in SSL/TLS (although for a given blob of data encrypted only once, this attack isn't viable). Padding oracle attacks allow you to decrypt a message (typically one encrypted using a block cipher such as AES in the CBC mode of operation) in linear time, provided there's an "oracle" that knows the decryption key and will, on command, decrypt any message and tell you if the padding (padding is necessary for block ciphers) is correct. Such an oracle is usually not available for a file at rest, but a padding oracle is the reason the that CBC mode can no longer be used in SSL, and led to the deprecation of the entire SSL protocol (TLS includes protections against padding oracle attacks).

Knowing the structure and some basic data about the file can also enable bit-flipping attacks (where you don't decrypt the data, but do change it in a predictable way that could further your causes against whoever legitimately uses the file). This is getting pretty far afield of your question, but it's sometimes relevant when you're attacking an encrypted file of which you have minimal but non-zero knowledge.


Is it safe to use localstorage to store session variables and user password?

No, this is not safe and I would certainly not recommend it. However, several methods exist that fulfill your requirements (and more).

I suggest having a look at OAuth 2.0. OAuth secured services require a valid access token in the Authorization header of HTTP requests. Such a token must first be obtained from an identity provider, usually a 3rd server.

This eliminates the need to store the user's credentials in the client application, the browser in your case. Also, tokens have a limited validity: After a set amount of time, a new access token must be presented. OAuth has a mechanism to do that, without having to request the user's credentials again: When an access token is requested, a refresh token is included in the response. The refresh token has a longer validity and can be used to obtain a new access token.


Why doesn't the number of bytes required by GnuPG generating the key decrease?

The reason for this is indeed not obvious from the GnuPG user interface.

RSA key generation requires to random prime numbers. GnuPG generates a primary key and an encryption subkey by default. Both of them are usually RSA keys, so they require two primes each, totaling four. This is also visible in the following message being printed twice, once for each RSA key:

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

After this, the two random numbers (which act as starting points for searching primes) are retrieved:

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 243 more bytes)
......+++++

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 250 more bytes)
..+++++

The number of bytes can differ each time you generate keys because there might be additional entropy generated after enough random bytes have been available.


False acceptance rate in biometric authentication system

False acceptance results from the need to deliver a user friendly system and is tied to  false rejection as well as the technical limitations of systems.

In short it is an accuracy issue.

A digital representation of a finger print (or any other biometric for that matter) is effectively a digital subset of the information about a finger print. The amount of information stored about each biometric record will be system dependent, but will be finite and therefore there is the potential for duplication. As with most digital representations some information will be lost and for an authnentication system there is a trade of in terms of storage space and processing speed which will limit the amount of information that can be used for the digital representation of each finger print.

As with any user system useability is key, with a biometric system users would soon stop using a systems if they had to submit their fingerprint repeatedly before it is accepted (false rejection), therefore the system has to have a tolerance threshold which allows for inaccuracies during the submission process by valid users i.e. a low false rejection rate, but decreasing false rejections will increase the possibility of a false acceptance because it is more likely that a different fingerprint will 'become' acceptable.

For your 1% FAR example, there is an expectation that out of 100 fingerprints it should be expected that 1 will result in a false match. Whether this means the person with the false match will always be able to create a false match is going to be dependent on how the system works (both hardware and software).


BTW, I consider this to be more of question of IT security or Linux operating system than cryptography.

A problem with Linux's /dev/urandom is that it is not possible to test if it has been properly seeded. The random number generator may return values which are based on insufficient entropy.

Thus, many turn to /dev/random instead. However, there are significant differences between /dev/random implementations on different POSIX compliant (or clone) systems. On FreeBSD, /dev/random is works the same than /dev/urandom on Linux.
Mac OS X is similar to FreeBSD in many things and also here: /dev/random is just like /dev/urandom.

The goal of Linux /dev/random is to basically return full entropy (one output bit contains one bit of entropy). The approach to this goal is to estimate amount of entropy collected and use that estimate and collected entropy material to produce output. Without Linux support hw-based entropy sources available, the basic entropy collection mechanisms will gather entropy quite slowly.

There are a few ways to accelerate entropy collection, including:

Use HW entropy sources (e.g. /dev/hwrng), these require e.g. "rngd" program
Type characters with keyboards
Move mouse (under X Windows)

If the /dev/random is empty after long uptime of the machine it means that some applications have been using the randomness devices. In Linux, /dev/random considers that the same amount of entropy is lost from entropy pool than was total amount of bits requested. (I.e. even if linux has full 4096 bits in entropy pool, it still wont take very many requests of say 128 or 256 bits to deplete the pool). Occasionally pool is depleted because some application misuses /dev/random. Some applications may attempt to read large amounts of data, like 2048 bits from it.

Long story short, you should read appropriate man page (man 4 random), and decide if /dev/random or /dev/urandom is actually what you need. If the mac's /dev/random would be ok for you, chances are you would be happy with /dev/urandom. The reason random number generation appeared from /dev/random much faster on Mac is that on Mac /dev/random means something different than /dev/random on Linux. Last, but not least, I would want to say: I like the fact that Linux offers two different semantics, operating systems where /dev/urandom and /dev/random are the same offer much less choice.

I would say this is not colossal mistake, the design is just bit odd from perspective of many. Once you are familiar with the design and restrictions and know how to use the devices, the design feels fairly good.

(BTW, other systems like NetBSD still have little bit different semantics for /dev/random and /dev/urandom.)


The usual recommendations about accessing private data from a public computer are:

Don't do it.
Don't do it; instead, use a smartphone or tablet.
If your really must do it, there is no other choice, it would be life-threatening not to read your email, then the following mitigations can be used:

Use two-factor authentication (e.g. with Gmail), the second factor using your phone (presumed safe).
Use One-Time Passwords.
Change your password from a "safe" computer as soon as possible after the access.

The first two mitigations suppose that you can enable these extra authentication methods on your Webmail, and that you have some extra device with you (a phone to send or receive a password by SMS, a generator for one-time passwords, a printed list of your next 20 one-time passwords...). The third mitigation depends on how soon you may access a safe computer, but, of course, if you can use a safe computer within the next five minutes, then why don't read your emails from that safe computer ?

In any case, whatever you do, you are betting that possible attackers won't hijack your connections automatically; instead, that the attackers passively gather passwords and won't do anything else immediately, leaving you with some minutes or hours to "plug holes". There are some attackers who act that way; but there also are other attackers who recognize connections to various Webmail systems and automatically hijack them. So, really, don't do it.


can MiTM read server certificate in TLS1.2?

can anyone who read all data packets (except client PC) do read/verification the certificate that server sends to client?

At least up to TLS 1.2 both server and the optional client certificate is transferred in clear text. The encryption starts in these TLS versions only in the last message of the TLS handshake (Finished). Transfer of the certificates is done before that and also the validation is done as part of the handshake.
See also How can I extract the certificate from this pcap file?

With TLS 1.3 the situation is different though: encryption starts much earlier in the handshake and both server and optional client certificate are sent encrypted already. Thus it is not possible to get to the certificate just by passively sniffing/capturing the data.


How secure is my system for a password reset?

Generally, it is ill-advised to implementing your own session handling. If you can, you would be better off by using a well known and well tested implementation.

These are the issues I see in your procedure.

User requests password reset

How will you handle misuse of this function - will you send one email per reset attempt, or will you implement a restriction to prevent misuse?

A custom token is generated (has a timer to be deleted after 10 minutes)

How will you generate the token? There are many attacks on "random" numbers.

What will happen if the timer fails - will the reset password token be valid forever? How about storing the date it was generated, and then only allow tokens that are "fresh"?

An email is sent with a http(s) POST request to post the token id

I think an ordinary link is a better choice here. POST will require mail clients to either accept html forms, or javascript - which most dont.

My application checks if the token id exists. If true, the user is redirected a webpage where they can reset their password

Where will the redirected webpage be located? It should be unpredictable as well, or require the valid reset password token in order to avoid bypass vulnerabilities.

User clicks submit and their new password is posted using http(s) POST
My server can then safely process and set the new password

Sounds reasonable

--

Now, you should also invalidate the password reset token. No need to let it float around if it has been used.

And needless to say, HTTPS is a good idea.


Why is the proportion of TLS usage higher at weekends?

I would need more elements to be sure, like the protocol used. What is clear when looking at the raw data is that the variation is mainly visible on inbound mail. That alone let me suspect that mails send through the webmail use TLS, while mails sent through SMTP relays do not. Which is somewhat coherent with SMTP protocol: it may go through a number of uncontrolled relays, so encrypting the transmission looks useless and many SMTP relay do not implement it. Instead they relay on the sender to encrypt the message content if privacy is needed.

That could explain why on work days, more mails are sent from work through corporate SMTP relays (no TLS), while less are on week end.

Below is my opinion:

Anyway, pretending that using TLS to and from GMail increases mail privacy is more marketing than information. What is the threat here? It is not far from securely closing a sheephold after letting the wolf in... The only way to increase privacy is to exchange encrypted content. But Google does not want to advise a method that would prevent itself to use the mail contents


What is this phishing technique called using subdomains

IDN homograph attack is not correct. Although the idea of this type of attack is exploiting the fact that many different characters look alike, it still allows for subdomains.

  In the Domain Name System (DNS) hierarchy, a subdomain is a domain that is a part of a main domain. Subdomain.

Despite this, do not be confused. We are treating the whole address as resolving to an IP address in this scenario. E.g. localhost -> 127.0.0.1, equally login.microsoft.com.example.com -> 127.0.0.1.

What you are describing login.microsoft.com.example.com is deceptive phishing. Some web browsers will highlight the subdomain leaving the domain grey. E.g. login.microsoft.com.example.com


Does OAuth2 state parameter need to be cryptographically secure?

It's all dependent on what you're doing with that state information after authorization and what could happen if an attacker modified it.

If you're using it to reassociate a session then you need to make sure an attacker can't just randomly guess the session ID. Or conversely ask yourself what happens when an attacker randomly guesses it?

If you're storing a bit of data like final-sales-price=$142.32 then you need to make it tamper evident through (say) signing so an attacker can't modify.


There's a lot of possible ways to enhance the security of your site. But it depends on the architecture of your website, if it is a dedicated server or not.

Use anti-DDOS services- If you want free you can use Cloudflare. It will help you to block attacker requests, like botnet. Here's the link https://www.cloudflare.com/
Use Wordpress plugins to enhanced security - I used Wordfence, which includes an endpoint firewall and malware scanner that was built from the ground up to protect WordPress.
https://www.wordfence.com/
Increase Internet Bandwidth and Server Capacity - The main reason your website can crash or go offline after a DDoS attack is if it doesn’t have the capacity to handle the volume of traffic sent by the attacker.


Modeling a per-process file based encryption for linux

I think what your looking for is isolation, such as Docker for sandboxing.
LD_PRELOAD may work for the crt, but it won't work with direct syscalls, so it may not work for many applications and defeats the whole purpose of your preload.
Keep in mind that modern browsers implement pretty tough sandboxes.
You may want to look into SELinux, which is designed to solve these kinds of problems by giving every file/process/packet a context


Authenticating users on offline devices such as ipad

I'm sure you didn't intend it to be so; but this is currently a politically-charged question, as well as a technical one.  Some appsec experts believe that crypto implemented in javascript is inherently flawed; and they make some good arguments, only a few of which are inapplicable due to the javascript being accessed only on an intranet, and only on one kind of device.

Authenticating a user on a device with no network connectivity means storing a password hash on the device. There's a lot of clever things you can do with crypto, but you can't get around that. The best you can do is to use a strong password-based key derivation function, understand that this may still leave you quite vulnerable, and use compensating controls:  Physical security and policies to make it difficult/risky to extract the hashes from HTML5 local storage and take them home for offline cracking.

This leaves the question of which password hashes you store locally. It sounds a little like you're only interested in non-repudiable actions:

  we need show that user X performed the action on the ipad.

If the only reason you're using authentication is for non-repudiation, and a single repudiable action constitutes a complete break of the system, there's not much point to having two separate passwords for each user.  If you have additional security goals beyond that, it may be worthwhile to keep two separate passwords; especially if user compliance isn't an issue--and your UI solution for that does sound effective.


Generating one-time tokens from API-key?

First and foremost never use MD5 for anything related to security.  It's a very broken algorithm.  You should use anything from the SHA2 family,  SHA256 is a great choice. One way of accomplishing this type of authentication is with an HMAC The API key could serve as the secret key K in the algorithm. The server with the secret API key would have to accept the post and provide the authentication token. The resulting message would have to have an ID and the message authentication code for that POST request. The ID could be the primary key for the API user, and the authentication code would be generated by the server that is using this API.

In this case Public Key Cryptography is overkill and a symmetric cipher ("encryption") isn't helpful at all.


What is the most likely cause of the infection ...

When searching for reimageplus infection I get as the first hit Malware Tips: Remove Reimageplus.com pop-up ads (Virus Removal Guide). There the typical infection vector is described in the second sentence already.

  The adware responsible for the Reimageplus.com ads is bundled with other free software that you download off of the Internet. Unfortunately, some free downloads do not adequately disclose that other software will also be installed and you may find that you have installed adware without your knowledge.

And as another early hit from the same search MyAntiSpyware: Remove reimageplus.com pop-up ads (Instructions) explains:

  How does a computer get infected with reimageplus.com
  ... This adware is bundled within the installation packages from Softonic, Cnet, Soft32, Brothersoft or other similar web sites...

  I thought that this would never happen because the user does not have admin privileges. ... how can we prevent it in the future?

Installation of  software for a local user instead of a system wide installation does not need administrator privileges. You might need to educate your users about the dangers of downloading and running software they just found on the internet or got forwarded by mail. Depending on the security solutions you employ you might also prohibit software downloads.


Heroku postgres: potential brute force attack

Almost certainly not. It's quite common to see automated attacks from web scanners - IPv4 is a pretty small address space and quite easy to enumerate (IPv6, at least, makes them work a bit to find targets!)

It's a low-cost, low-success, but potentially high-reward tactic if they stumble on a server with interesting data and a terrible (or default) password. Just make sure you have non-trivial passwords and you'll be fine.


Can a brute force attack be certainly prevented on a unix/linux shell?

Let's start with making sure we have a clear understanding of what 'brute forcing' is. A brute-force attack is when an adversary attempts to guess every single combination of characters, starting at one length, and increasing the length by one until the password is cracked. e.g. 1, 2, ... a, b, ... 11, 12, ... 1a, 1b, ... aa, ab, ... etc. Depending on the charset used, it can take a relatively short time to guess all possible key spaces (mixalpha), or relatively a much, much longer time to guess all possible key spaces (mixalpha-numeric-all-space). The important thing to take away here is that the adversary is simply guessing (and getting wrong) a very large number of passwords. Now..

"For the sake of this example, lets say we're talking about a linux/unix shell because this seems to be less covered."
If the adversary has local access and the harddrive is not encrypted, the password hashes can be recovered without logging in. If the harddrive is encrypted, then your main defense from password guessing attacks is configuring failed-attempt lockouts and increase the delay time after a password fails validation. From here I will be referring to an adversary that has already broken into your system, stolen your password hashes and salts from /etc/shadow, and is attempting to crack them.

"Is there a way to be certain your password can't be broken by brute force?"
No.

If the adversary is able to recover your password hashes/salts, they can begin bruteforcing the hashes on their own hardware, and you will have absolutely zero control over this.

If you are instead referring to an adversary who does not yet have access to your computer, but is trying to bruteforce your SSH login, then yes, using a firewall/IPS will prevent virtually all bruteforce attempts. Simply logging the failed logins is not enough, but using a tool that bans offending IPs (like Fail2Ban) will make attempts at guessing a quality password infeasible.

"Logging failed attempts seems like a good counter measure as well, but of course this doesn't necessarily do anything, especially if the attacker routes through a tor node and does not care if the administrator is aware they are trying to break the password."

Ok, back to remote attacks, presumably against SSH?

"...especially if the attacker routes through a tor node..."

Tor publicly lists all of their exit nodes. Ban them all.

"...and does not care if the administrator is aware they are trying to break the password."

As long as your firewall/IDS is configured properly, it doesn't matter how many different proxy servers the adversary has available to them, it would take an insurmountable amount of time and proxies to bruteforce any quality password.

"Yes, it is possible to slow down an attack in various ways, but if an attacker is perfectly okay with waiting a few years, this will not be sufficient."

Most flavors of linux hash their passwords with SHA-256. If your adversary is capable of one trillion guesses/second (as quoted by Edward Snowden a few years ago.), and you had a twelve character mixedalpha-numeric password, it would take 104 thousand years to bruteforce the little over 3 sextillion (3,279,156,381,453,603,300,000) possible password combinations. Unless you are using a password with dictionary words or common patterns of numbers and/or letters, you do not have to worry about wordlist/rules-based attacks, which in reality is the far more common and successful way of cracking passwords. This doesn't even begin to take into account the additional time spent on every connection if this was a bruteforce against a non-firewalled SSH server.

"Logical puzzles are a popular tactic, however I was considering this and it seems a human could solve and store all the answers to the puzzle database (given enough time). The data could be changed periodically but this can in turn be dealt with by a human and possibly AI scripts as well."

I don't exactly know what you mean here, but if a human can solve a puzzle, a computer can be taught to solve it in immensely less time.


How to deal with administration tools such as ipscanners and PSTools?

If you're worried about malicious actors using standard user internal utilities (psexec, pskill) after gaining access to a system, you're worrying about a scenario where no matter what actions are taken in preparation for the intrusion, the attacker will be able to circumvent it, as they already have access to the machine. Making it more difficult to use some of the "power-user" oriented tools on the system will only make it more frustrating for your legitimate users to do their jobs, and won't do anything to prevent the attacker other then mildly inconveniencing them.

However, if you're concerned about tools and utilities that require root/admin level access being used by the attacker after intrusion, you should look into securing your user system (e.g. only giving sudo/admin level access to users signing in with PGP (or if Windows, only from local logins), or only allowing local access to root (only applicable to Linux), etc) instead of trying to limit the tools available in your userspace.


You either had

a guessable password
a password found in a previous data breach
you fell for a phishing attack

The attacker likely didn't spoof anything ... they probably control your Hotmail account. If Hotmail has a screen that shows you recent logins you may be able to see where the attacker is logging in from but that won't help much.

Instead you need to

change your password
change your backup / secondary email address
enable 2FA/MFA to prevent this from happening again


Is there a CVE or CVSS for enumeration of ports?

CVE is meant for specific security-related bugs in software.
"Some single random company has a bad IT department" is not something to write there.

All mentioned problems boil down to a bad IT department, namely wrong FW configuration (not the same as a FW software bug), and no updates on their DB ("no updates made by the admin" is again not a software bug).


How to securely host downloadable source code

As it was said in the answer to your other question (that you linked yourself), "Check sums (and cryptographically secure hashes) only ensures integrity", but naturally only to the extend you can trust them. If somebody compromises the server your program and the check sums/hashes are stored on they can modify both, and the integrity is then limited to "this program hasn't been modified since this hash was generated". But you do have some protection against problems on the network (working as a man-in-the-middle it's a little harder to modify the program and the hash so they still match).

If you want to do a little better you make sure the hashes are available elsewhere, you can create a repository for your program on github (I don't know their terms, and thus not whether this would be violating them, making this bad advice) putting them in a file there.

Even better you could cryptographically sign the program, publish the signature and tell people to verify that what they are about to install is signed by you.


Does disabling WiFi and mobile data make my phone impossible to hack online?

By disabling WiFi and mobile data, you shut down some attack paths. That means that your system is more secure, and probably immune to most "script kiddies" attacks.

However, the telephony part will still be active. It is certainly harder to exploit, but a smartphone is far from a 1960s telephone, and even the telephony part has interaction with the phone's OS. That means that is is still possible that a combination of calls and SMS triggers an unexpected condition leading to a possible exploit. I know none of those, because even the Stagefright bug cited by @SteffenUllrich in his answer uses a crafted MMS. And a MMS can only be delivered when mobile data (or possibly WiFi) is active, and will never be if only telephony is allowed.

If you can be sure that god himself was among the engineers that designed your phone system, you are absolutely safe. In any other case, bugs are always possible...

Of course, if you use other functions of your phone like displaying photos, viewing videos, or playing music, you open new doors for attacks with every new application.


Can a Slow Post HTTP attack be done from a single client?

Yes it can, in fact basically that type of attack tries to consume the internal memory that is handling the buffering of the post operation. In general the backends have parameters for handle this type of situations.


is there a safe way to login to my gmail account from a public pc?

Enable two factor authentication.  Consider the remembered password compromised to any user of the public computer.

EDIT: My answer dealt with how to prevent your password from being keylogged.  With two-factor authentication your password is now the combination of a randomly generated one-time use code (obtained via cell phone or pre-obtained list) as well as the remembered password; hence a keylogger doesn't give an attacker the ability to log in as you for a future attack.

However, I definitely agree with TomLeek and Nic that in a real-time attack (not a keylogger looked at after the fact) that captures your random session token (that indicates to gmail you are signed in before you do any action), an attacker can fully use your gmail account (send emails as you; search through emails sent to you; delete your emails; etc).  Granted, once you logout your session token will become invalidated and will kick them out of your account.  Granted a clever attacker could write a browser plugin to collect your session tokens, send it to them, and then redirect the logout page to not actually invalidate your token.  Though you could always login to gmail again, view the link for "Last account activity [Details]" and sign everyone else out.


Checking potentially infected photos for stegonography

Start by copying every image file on their infected device to a media card. Then on your recovery machine launch a VM running an OS that is immune to Windows malware (Linux), install ImageMagick, mount the media card, then use a script that calls ImageMacick to transform each image to PNG format. This will neutralize malware that leverages flaws in JPEG handling, while preserving the pictures. Consider stripping away all existing thumbnails contained in the original files and regenerating them from the source image.


Blackberry + RIM Bluetooth-based Smart Card Reader

Wow.  Cool Reader!!  I wish I could say I'd tried it, it's very enticing.

From a solid understanding of SmartCards, though, I don't think you are going to get away without entering the password.  The password is protecting the keys on the Smart Card, not the usage of the device.  These keys need to be protected from use on your device, or any other device - so the lock on your device isn't going to help with the security of the Smart Card.  Given how this is written, I expect the password to be a string of characters (upper, lower, number and non-alpha numeric) that can be set at the time of card issuance.

There would be the question of whether you could get an API for your phone to the reader, so that the phone could store the Smart Card password locally - but this becomes a security nightmare quite quickly, as secure storage on a smart phone will be difficult and the ease with which a smart phone can be lost makes storing a password there quite problematic.


Outbound proxy/reverse-shell as a way to bypass firewall

It sounds like you have shell access so you should be able to setup an SSH tunnel and use the tunnel as a proxy in Firefox. Then you'd essentially be connecting to the server from itself.


I think you need to get better with your javascript  first.

To answer your question, the below GET request is what you need to send

http://example.com/test.html?p=%3Cscript%3Ealert(123)%3C%2Fscript%3E

Explanation

In the code

location.href.substr(location.href.indexOf('?')+1).split("&")

Here,you are taking the substring of the GET patameters in URL.

And then you are copying each of the GET parameter in to queryDict object as queryDict.key=value.

 forEach( function(item) {
  queryDict[item.split("=")[0]] = item.split("=")[1]

This assigns queryDict.p  the value of %3Cscript%3Ealert(123)%3C%2Fscript%3E which is equalent to encodeURIComponent('<script>alert(123)</script>').

And finally

b = document.write('<b>' + decodeURIComponent(queryDict.p) + '</b>');

decodes the value of queryDict.p and injects it into DOM as a Javascript


Is it okay to publish a TLSA records for non-DNSSEC CNAME'ed services?

The configuration:

example.com. IN MX 0 smtp.example.com. ; AD=1
smtp.example.com. IN CNAME smtp.example.org. ; AD=1
smtp.example.org. IN A 192.0.2.1 ; AD=0
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1

Will yield DANE-secured TLS with at least some DANE implementations, e.g. Postfix.  However, this may not work in all cases, for two reasons:

CNAMEs violate the RFC requirement that the exchange field of the MX record be already canonical and not a CNAME (see https://tools.ietf.org/html/rfc5321#section-5.1), therefore, though I don't know of any MTAs that disallow CNAMEs here, they'd be compliant with the standard if they did.  However, in my survey of (today) 4,244,642 DNSSEC-signed domains that have MX records, I find 1,432,478 distinct MX hosts of which 21,262 are CNAMEs (serving 34,886 domains), and apparently not having problems. So in practice CNAMEs in MX records appear to work.
More importantly, https://tools.ietf.org/html/rfc7672#section-2.2.2 explains that TLSA lookups should be skipped when the MX host name lies in an unsigned zone, as evidenced by the security status of its A/AAAA records. When no CNAMEs are involved this is simple, and implementations are unlikely to mishandle this case.  When the MX hostname is a CNAME into an insecure zone, I expect that some implementations (e.g. I believe Exim) will not determine the security status of the initial CNAME, and so (unlike Postfix) will not attempt TLSA lookups in that case.

Figuring out whether the CNAME RR pointing at insecure A records is secure requires a separate CNAME query for the same name, which suppresses recursion in the resolver and returns the security status of the CNAME itself. Exim, and likely some other MTAs may not do that. While RFC7672 says they SHOULD do it, it is rather subtle logic, and likely to be skipped in implementations.

Bottom line, if you really want DANE to work, avoid CNAMEs into insecure domains, and if necessary, publish A/AAAA records in the secure domain that duplicate the A/AAAA records of the underlying host:

example.com. IN MX 0 smtp.example.com. ; AD=1
; smtp.example.com. IN CNAME smtp.example.org. ; AD=0
smtp.example.com. IN A 192.0.2.1 ; AD=1 (cloned from smtp.example.org)
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1


How to create a secure login system with cookies?

In PHP, creating a session is easy. You first declare it using session_start(). It handles creating a session cookie for you, and pretty much all of the hard stuff. When the user navigates throughout your site, you can read from and write to the session variables using the $_SESSION global object, which can affect which content you want to display to the user, and even how it is displayed.

What happens, is the server generates a secure random token on its side and then sends the value as a cookie to the client which the client automatically communicates back to the server on each request. The server takes this value and uses it to determine which object in memory to reference as the $_SESSION object.

However you want to handle the initial login is up to you -- I'm not going to get into that here. But once the user does log in, you want to indicate that in the $_SESSION global. In order to make it secure you will want to destroy any existing session and create a new one on authentication. The way I usually do it is I set $_SESSION['user'] on login (after destroying the previous session and creating a new one). That way it has another use, checking whether a user is logged in: if(isset($_SESSION['user'])).

This is basic functionality, but hopefully it points you in the right direction. Databases aren't necessary for sessions unless you're trying to implement logon/session policies or you're running your website in a cluster. That would be due for a more complicated discussion which I don't think would be appropriate to get into here.

Edit/Update:

It turns out I will in fact get into the specifics of a secure login system; If you want your login system to be up to standards in terms of security, you will need to properly hash (and salt) your password. It turns out there is a PHP method for that as-well.

Hashing basically turns whatever the input is into garbage that can't be turned back into the original input. Password hashing is used to prevent people from gaining access to the original password in the case of a server/database compromise where passwords can be potentially leaked. The most important thing to know when hashing is that the slowest algorithms work the best for passwords.

Salting is almost equally as important as the algorithm used to secure the passwords. The salt is a CSPRNG which simply gets added to the password before hashing. CSPRNG stands for Cryptographically Secure Pseudo Random Number Generator, and it's really just a fancy way of saying that it's a super random and unpredictable set of bytes. These bytes are randomly generated on a per-password basis to protect end-users against rainbow attacks, in which a single produced hash can be checked against large quantities of passwords. By requiring a single hash per attempt per password, it greatly reduces the chances of mass a password leak resulting from a mass hash leak.

A manual system would work as-follows:

When the user account is created, a row is inserted into the database 'users' with the username specified, and the hashed password. The hashed password is first salted (random data added to the password), then hashed using a slow password hashing algorithm. The salt is additionally added to the password hash before being inserted into the database. Optionally you may store something to identify the hashing algorithm used with it as-well. If you feel uncomfortable combining these values, you can also store them as separate database values.

When the login process is initiated, the database is queried in the 'users' table for the row with the key 'username' matching the username requested. That row is pulled which includes the password hash. First, the salt is taken away from the hash. Then the salt is added to the password given during authentication and that whole thing is hashed using the same hashing algorithm used originally. Then, if the end result matches the hash that is stored, the user can be successfully authenticated.

I hope I'm not confusing you too much with my explanations. Ashley Madison apparently missed the memo entirely so if you don't understand, don't feel bad. You're not a multi-million-dollar website. The most issues come from when people take it upon themselves to accomplish things beyond their skill-set. In that regard I certainly recommend that you use the built-in, or at least open-sourced and publicly recommended password hashing functions whenever possible. They take all of the guesswork out of the equation.


MAC address of router changes when i connect to VPN

When you spin up a VPN tunnel, the VPN tunnel becomes your new primary route.  If the router address remained as your physical router MAC, then you would not be routing traffic through the VPN, and you would not be protected.  The virtual router your VPN sets up is using the synthetic MAC address 00:00:00:00:00:02.  The change you're seeing is the correct and expected behavior when activating a VPN.
And you are correct, MAC spoofing requires an attacking device on the same LAN.  What you are seeing is not MAC spoofing, regardless.


If I understand you correctly, the login packet will be exactly the same for the same user within the validity time of bl_hash. So a passive attacker can record and replay it. To prevent this kind of attack, bl_hash should be used only once (see nonce).

Decrypting the login packet with the hash of the user password, implies that the hash is not salted. A salt is a random string that is unique for each password and is concatenated before the hash is calculated. It prevents an attacker, who got access to the account database, to attack all passwords in parallel with a dictionary attack. Instead of a simple hash, you should use one of the password hashing algorithms such as sha512crypt, bcrypt or scrypt to store the password.

The client does not authenticate the server. Therefore a man in the middle attack is possible.

I strongly recommend to use SSL. It is a very well tested protocol with libraries for all common programming languages. And it is not vulnerable to any of these problems.


Assessing risks Physical security of devices

The answer is found in Karate Kid II:

  Remember, best block, no be there.

You cannot break a device that you don't have, and you cannot steal something of which you don't know the location. You cannot decrypt a no-sucks encryption without knowing the  key. You cannot coerce someone telling you the key if the person doesn't know the key. You cannot restore a split secret if you don't have all the parts (or a certain number, at least).

So the first obvious defense is to make the location of the devices/disks unknown and the disks physically inaccessible. Make sure it is unfeasible to get all parts.

Rent a couple of bank safes, do not tell anyone where. Put one disk with one shared-secret part in each. Depending on your paranoia level, you might even have two or three trusted people independently rent safes (and possibly more than you need), and give one or several of them a share of the secret (without knowing where they've rented the safes yourself, or in which one they'll place the disk).

Use a random encryption key long enough so you cannot remember it, and have another trusted person keep it. Or, have two people store half of the key each. Could give one half to your attorney in a sealed envelope like in a 1970s spy movie. Or put it in yet a different safe, hide it on a cemetary, whatever. Protected storage on a smartphone would be an option. Both Apple and Samsung offer protected storage and will wipe memory after so and so many failures if you tell the phone to do that. Give your lawyer that phone.

Adversaries might break the safe in your home or your office. But few, very few, adversaries can break into a bank safe, let alone break into several of them either at the same time or without being noticed. As soon as one bank safe is broken into, you will be informed. So they must be really, really, really, powerful to pull that off.
If the possibility of your adversary breaking into 3 or 4 banks simultaneously and figuring out the encryption key is a realistic concern, please stop reading now, buy some rope, and hang yourself. Or, just give them your secret.

An adversary who doesn't have all split-secret devices cannot use the data even if he has some of them (well, it depends on the scheme you use, could need N-1 or N-2, or N/2). An adversary who doesn't know the encryption key has nothing but rubbish in his hands, even if he has all the parts. So... make sure that cannot happen.

The easiest, most obvious split-secret scheme that you can use without special tools is RAID-0 (or RAID-5 if you want to trade the small risk of the adversary finding N-1 disks against the risk of losing one by accident) in combination with any kind of does-not-totally-suck file-based encryption. Anything that does any kind of block chaining and uses a no-joke algorithm. Which is pretty much what every standard archive tool like 7z or such does. If you have reason to believe your adversary can conceivably break the encryption that 7z uses, then see above, buy rope and hang yourself. Nobody can help you.

As an alternative if RAID sounds too scary to you (never heard of?), you could add some random data to an (encrypted) archive (doesn't matter what, just to guarantee a minimum archive size to start with), then add all your secret data, and finally select the "split archive to..." option to generate several small sub-archives. All but the first part (which contains only random noise) are worthless without all of the preceding parts. Put one on each disk, done. You can even add some redundancy by hand if you like, in case one disk is lost. Only need to create more segments and be sure each is on at least two disks.
Or, create an encrypted archive, split in two, add the parts in reverse order to another encrypted archive which you then split in N parts (don't need random noise then, cannot decode any part, including the first, without the other parts).

If an adversary doesn't have all the disks, then whatever he has... it's completely worthless. There's no way he will decrypt the archive, or part of it, even if he knows the decryption key.

If the paranoia level is at its top, you could complement the whole thing by further adding filesystem-level encryption. But that's actually kinda silly.


Can the salt for PBKDF2 be a hash of the user-entered password?

A salt is not a secret, it is meant to make the Hash/PBKDF2 result unique to each used instance. As far as a know, the very definition of salt requires it to be random for each computed hash. If it was password derived, two users with the same password could end up with the same verifier -> Bad.


The problem with client sided Obfuscation/Protection is that the attacker will always win.
Your code runs on his PC so he can intercept and manipulate everything in the end.
In the specific case of .NET it might make sense to apply basic obfuscation to remove function names for example but free tools are perfectly fine for that.

To answer your question a bit more specific:
Most commercial obfuscators do the same things that free ones do as well.
I'd go for Confuser/ConfuserEx, both are open source and provide better protection than most commercial stuff.


Possible DOS Attack? And solutions for it?

220 ping requests hardly qualify as DoS. A SYN flood is a kind of DoS, and if your router is reporting a SYN flood then chances are that there is someone playing at pestering you with low-scale DoS. The ping requests are not part of that attack, but may be used by the attackers to monitor whether the attack works or not (i.e. whether they could crash your router or not).

Usual mitigation against such attacks is simply to wait for the attacker to get bored or to reach the age of 13, whichever comes first. You may want to alert your ISP, though (don't tell them "I am being attacked" but rather "I get disconnected and my router shows this strange error message"; disconnections are part of the scope of their job and if some formal complain must be made with law enforcement agencies then having the ISP handle part of it would be a good idea).


Register confirmation email with plain password

If they have restricted the max password length to 8 characters, it demonstrates that they are not correctly or safely hashing it into their database. So all of the data you have entered can be considered compromised.

It would be helpful to share the site so that others can avoid it.

If you use that password for anything else, change it everywhere else straight away.

If the site in question has any information about you, I recommend changing that information straight away to something random.

Afterwards, write to them and ask for all of your information to be removed from their systems immediately. Explain to them politely why you are doing this.

What danger can come from this?

All of the information you've entered must be considered compromised since they have clearly demonstrated a complete lack of understanding or care about the data.
Can this affect my email in anyway?

As Mirko says, if you've used the same password then you need to change it immediately. Otherwise, the main "danger" is from spam from compromised customer databases.
If my email is linked to social websites, will that be dangerous?

It isn't really dangerous but it may expose you to more spam. Spam can, of course, be dangerous in itself. You might also be exposed to cyber bullying or stalking depending on how vulnerable you might be to such things.


Yes.

An Operating System on an External Drive can have the same access to your system as your installed system. The reverse, your installed infecting your external system may also be possible.


How to send secure messages from a microcontroller circuit?

With an Arduino, you are limited in many ways. One of the ways you are limited is in your entropy (the random bits) which you need for ANY encryption system.

You could add entropy randomness using the analogue pins of your Arduino, van Heusden has a example here.

He has also quite some interesting articles about entropy and how it affects security.

A 'Security IC' always has parts of this solution for its own use and could solve the problem for you.


Are revealed personal emails a security risk?

There are some downsides to having your email spread to strangers:

The more spread your email is, the more likely you are to get spam, phishing emails, emails containing malware, etc. If anyone of those 10 people get infected by a virus, your email address will be in their contact list. (Recieving such emails does not automatically mean that you will get infected, though.)
It can be used to research more information about you. One could Google it and see what comes up. Or try it on different sites vulnerable to user enumeration to see if you are registered there.

But these really aren't any biggies. And to be honest, your email is probably spread far and wide already in all sorts of places beyond your control. I wouldn't worry about a couple of handfuls of future collegues getting it as well. The behaviour of your employer is both reasonable and expected, and not something I would make a fuss about.

If you still feel the need to limit the spread of your email I suggest you use multiple accounts for different purposes. E.g. you could have one email that you use for sensitive business (e.g. account recovery), and another that you hand out to people you would not trust keeping it confidential.


Metasploit MsfVenom - Payload binds shell, but unable to spawn it with netcat

After a while of messing with the attack, I noticed how the exploit would crash the program and the alerted error message contained a module called hungapp, and offset of 00000000. Some more research were done, hungapp looks like a microsoft security feature that blocks TCP connections. The last microsoft security update for the victim's pc was published in 5/15/2017, that most likely patched up against this type of Seh attack.


Authenticating users to Web Apps without sending password — can anyone suggest improvements?

The authentication is done over an unsecured http connection using AJAX.

I stop you right here. If the Javascript code running on the client side went over unsecured HTTP, then that code could have been altered in transit by any half-competent Man-in-the-Middle attacker. It can then do a lot of evil things, like, for instance, sending a copy of the user's password to some attacker-controlled server.

Client-side cryptography in Javascript works only if the said Javascript came over a secure link, i.e. HTTPS. And if you have that link, then why would you bother any further ?

Apart from that, what you describe has nothing "SRPish" whatsoever. SRP is a Password Authenticated Key Exchange protocol, which means that it grants immunity against offline dictionary attack, something which cannot be achieved with symmetric cryptography tools like hash functions and bcrypt. At best, bcrypt will grant resistance against offline dictionary attacks, meaning that an eavesdropper, spying on a connection, may learn enough to "test passwords at home" but will suffer for each test.

SRP does "better" through some extra mathematics. See the RFC. There are modular exponentiations in there.

SRP-with-TLS makes sense only because it works at the SSL level directly, is done by the browser, and uses an implementation which is already on the client side. When the browser does not implement SRP at the SSL level, then you are back to the "usual" setup with normal SSL (with a server certificate), and sending the user password "as is" through the SSL.


Understanding boolean based SQL injection

Is my understanding of the above correct ?

Yes, your understanding is correct.

  If yes, then in the query, $Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1, what is the need of the bold part above? I mean, can't we confirm the result (as confirmed in the analysis above) without the bold pat of the query ? Why is bold part of the query really needed ?

For exploiting a SQL injection successfully it is necessary that the resulting SQL is valid. The trailing AND '1'='1 is to fit the injected code into the existing statement. Since we escaped from a string literal with 1' at the begin we need to introduce a new string literal at the end. However, one could also use AND ASCII(SUBSTRING(username,1,1))='97 as MySQL can compare string with integer values.

  Since in this technique also we are basically trying to see the error page and distinguish it from the success page, should it not be considered as an Error Based SQLi rather than calling it Boolean Based ?

Error-based SQL injection would be the case when the server would respond with the actual technical error message like:

  #1064 - You have an error in your SQL syntax.  Check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1

Here you can see which portion of the resulting SQL did fail and you may reason how to fix it up with the injection.

In boolean-based SQL injection all you see is just a different behavior on different inputs. This different behavior may include the response of an error message, but unless it’s one with technical details that tell what went wrong it doesn’t help you more than any other boolean behavior.