What if the voting machine is the adversary (Distributed Knowledge/Trust) I read some e-voting questions here, but most deal with simple things like securing the connection from external attackers. But they usually put implicit trust on the central voting authority to be honest.

So assume you have 1000 Voters, and a single person (the Tallier) who tallies (i.e. counts) the votes. Each Voter knows what his own vote is (incomplete information), but only the Tallier knows how everyone voted (the complete picture). The Tallier wants to lie about the results, however.

Because the Voters don't trust the Tallier to be honest, they require him to provide them with some sort of a log. Each Voter then examines that log.

Can we make the system in such a way that it is impossible for the Tallier to provide a fraudulent log without a large percentage of Voters becoming aware that something is wrong?

I imagine something similar to SHA1 checksums, where a server cannot provide a file such that the SHA1 checksum will. Only in this case each voter has incomplete information (he only knows about his own vote).

Also, voters would need to detect if the Taller has invented non-existent voters.

Is there any research on the subject?

For paper ballots you have the tallier being audited or watched constantly by 3 people from your 1000 voters (scrutineers).

It could be something similar with e-voting, I don't know what exactly would work. Maybe you have one way data entry for the vote to go into secure government buildings, with giant display screens where any voter can see a list of anonymous vote receipts to gain confidence that their vote was counted, and a ceremony for ensuring the counting machines inside are working correctly and isn't tampered with during the vote.


Secure big, old ecommerce website from XSS? I'm working for an ecommerce website written in C#.net (no CMS used, quite a lot of code) where security hasn't been a priority for a long time. My mission right now is to find and fix any XSS breaches. There is a lot of non-filtered data written directly in the rendered HTML.

What is my best strategy to cure the code without having to read every single page?

I propose the following four step program, where you first pick the low hanging fruit to give you some minimum of protection while you work on the bigger problems.
1. Activate client side filtering
1.1 Set the X-XSS-Protection header
Setting the following HTTP response header will turn on the browsers built in XSS protection:
X-XSS-Protection: 1; mode=block

This is by no means waterproof, and it only helps against reflected XSS, but it's something. Some old versions of IE (surprise, surprise) have a buggy filter that actually might make things worse, so you might want to filter out some user agents.
1.2 Set a content security policy
If you do not use inline JavaScript in your app, a CSP can help a lot. Setting script-src 'self' will (a) limit script tags to only include scripts from your own domain, and (b) disable inline scripts. So even if an attacker could inject <img onerror="alert('XSS')"> the browser will not execute the script. You will have to tailor the value you use for the header to your own use, but the linked MDN resource should help you with that.
But again, this is not waterproof. It does nothing to help users with a browser that doesn't implement CSP (see here). And if your source is littered with inline scripts you will have to choose between cleaning that up or abstaining from using CSP.
2. Activate server side filtering
John Wu has a good suggestion in comments:

Also, since this is .NET, a very quick and easy change can turn on ASP.NET Request Validation which can catch a variety of XSS attacks (but not 100% of them).

If you are working in another language, you might instead consider using a web application firewall (as suggested by xehpuk). How easy a WAF is to configure for you depends on what application you are protecting. If you are doing things that makes filtering inherently hard (e.g. pass HTML in GET or POST parameters) it might not be worth the effort to configure one.
But again, while a WAF might help, it is still not waterproof.
3. Scan and fix
Use an automated XSS scanner to find existing vulnerabilities and fix these. As a complement you can run your own manual tests. This will help you focus your precious time on fixing easy to find vulnerabilities, giving you the most bang for the buck in the early phase.
But for the third time, this is not waterproof. No matter how much you scan and test, you will miss something. So, unfortunately, there is a point #4 to this list...
4. Clean up your source code
Yes, you will "have to read every single page". Go through the source and rewrite all code that outputs data using some kind of framework or template library that handles XSS issues in a sane way. (You should probably pick a framework and start using it for the fixes you do under #3 already.)
This will take a lot of time, and it will be a pain in the a**, but it needs to be done. Look at it from the bright side - you have the opportunity to do some additional refactoring while you are at it. In the end you will not only have solved your security problem - you will have a better code base as well.


Is it possible to perform a XSS attack in the title/subtitle of a webpage? I have a XSS payload that successfully ran the javascript when I pasted the URL in browser and hit enter. This is the URL:

localhost/path/to/file.jsp?aMessage=%3Cscript%3Ealert(%27XSSed%27)%3C/script%3E

Where aMessage gets displayed in a table like so:

         <%= myObject.getString("aMessage") %>

The markup looks like so:

localhost/path/to/file.jsp?aMessage=

The result: an alert dialog pops up and says 'XSSed'. I then tried to perform a XSS attack using the title/subtitle of the web page, but it didn't work. This was the new URL:

localhost/path/to/file.jsp?aTitle=%3Cscript%3Ealert(%27XSSed%27)%3C/script%3E&aSubTitle=%3Cscript%3Ealert(%27XSSed%27)%3C/script%3E

where aTitle gets assigned to title and aSubTitle gets assigned to subTitle in the jsp like so:

<popup
    title = '<%= myObject.getString("aTitle") %>'
    subTitle = '<%= myObject.getString("aSubTitle") %>'>
</popup>

Where popup is a custom tag in an xml file.

So I have a couple questions:

1) Is it possible to perform a XSS attack using the title/subtitle of a webpage? I am wondering if it is necessary to escape the characters in these fields as well, or if it is fine to accept whatever text. (I know it's generally not a good idea it's just for the sake of curiousity).

2) If it IS possible, why doesn't this work?

Yes, it is possible.  It all depends on where the content is reflected in the markup, and if the content is escaped properly for the given context.
Your xss doesn't work in the title fields because it's not formatted correctly for the given context.  The markup for "aMessage" is in an element context.  Your XSS Payload is formatted for that context.  "aTitle" and "aSubtitle" are in an attribute context.  Your payload is not formatted for that context.

You have a couple of different options to get it to work:

See if you can get to an element context.  Try entering aSubTitle with a value like

  "> < /popup> < script> alert('xss'); < /script> < popup>

The resulting markup should look something like

  "< popup title="What ever you entered for title" subTitle="">< /popup> < script> alert('xss'); < /script> < popup> < /popup>

If the output is being encoded for an attribute context, try exploiting a javascript event to execute your payload.  For example:

  " onmouseover="alert('xss');"
  could potential cause your payload to execute when the user mouses over your content.


Just found out my internet was routing through a proxy, how screwed am I? I checked my internet setting today and it seem that everything has being going through some proxy server for the last few weeks.  How screwed am I?

Could they get my internet login password?  All my files on Dropbox?  I buy things online too, is my credit card compromised?

EDIT:

The IP of the proxy is 85.214.85.193, but on my other computer which was also proxied the IP was something different (I forgot to write it down).

This all depends on the proxy itself. A proxy intercepts, and redirects. Everything going towards the Internet was intercepted, but it doesn't mean that all was readable. When you log into certain sites (banks, to buy something) most use SSL which means that, unless the proxy was intercepting with a trusted certificate, most data would be encrypted. If in the event the proxy intercepted SSL, and was capable of forging a certificate, or making you believe a certificate was trusted, then you're data is readable. You would have gotten a certificate error via your browser: "Warning this site uses an untrusted certificate..."

Can you elaborate more on the proxy server. E.g. the IP (if possible). Some ISPs use proxies (rare) to cache and provide content quicker.

ADDED

The IP space belongs to Strato in Germany http://bgp.he.net/net/85.214.0.0/15#_whois and is listed in a lot of "free proxy" like sites. The bigger question for you is, how did your machine manage to get proxied in the first place. This is likely caused by some form of malware that made its way onto your machine if you did not configure that proxy. As noted, SSL could have been stripped so that is something to take into consideration.

Personally, I would try and determine how my machine got compromised, I would clean it up, preferably re-install from a clean source, then go and change all my passwords AFTER the fact I cleaned up. (Makes no sense to type much via way of credentials when you don't know what's on your machine)


unexpected thumbprint when connecting via remote desktop - what now? I have an Amazon EC2 instance in a VPC.

I have not logged into it for some time, so I used the Amazon EC2 CLI with ec2-get-console-output to check what the thumbprint should be when I connect. To my surprise, the thumbprint on the certificate, in the remote desktop warning screen, was wrong.

I have connected to it via RDP in the past, and I am pretty sure the certificate thumbprint was as expected. I checked other instances and they matched their CLI output.

I am wondering if this could be something to do with the instance being in a VPC? It could also be a man-in-the-middle attack, I guess. The server is sufficiently important to draw unwelcome attention.

Currently I am afraid to log in, so what is the next step? Thank you.

This was due to a reboot being required, after something has happened to cause the OS certificate to change, in order for the new certificate thumbprint to show up in the output of the Amazon CLI ec2-get-console-output command.


Is there a general name for this sort of cryptographic protocol? Is there a general name for this sort of cryptographic protocol?

If so what sort of assymetric/symmetric encryption functions tend to be used for this protocol?

What you are describing can be referred to as a hybrid cryptosystem where asymmetric ciphers like RSA is used to exchange encryption keys that will then be used with symmetric ciphers like AES.

The main problem with the method you describe is that the client is requesting the public key from the server which can be replaced by an attacker that is sitting between them performing a MITM attack. This can be overcomed with something like the x509 CA system, which brings you to a system known as PKI. This is the backbone of SSL/TLS.


What encryption algorithm outputs 22 characters string? I have a bunch of encoded strings and I am trying to figure the encryption algorithm behind it. I would appreciate if you could help me find which encryption algorithm it is, or if you could point me in a direction. Here's what I know so far:

The output is always 22 characters long.
The output only contains [a-zA-Z0-9_-].
There's a high chance that the encryption occurred within PHP (not 100% sure).

Here are some examples of the encrypted strings:

t_PLJfnXRPS0HzZ_gKdaQg
V-FBHyLcTn6GVCtKvBOFrg
8T148uQ_TCWtOfMar03Y_Q
1Z20Bh3LQG2bMRlS9CvOjQ
bpxt8O4PShW7pqWotIrxKw
oJpqsNvpRPeCHhcObyhhww
VY3LJhnKS9iF9bSzN9qAWA
DK3Z5kjiRTeBpfDLrdfGyA
GUetaVQkRmWWVJluyezR9w

Thank you in advance for your help.
Cheers.

The encoding seems to be a form of URL-base64 encoding without padding. That's pretty commonly used. The character set allows it to be used in URI parameters like ?enc=....and such contexts.

The result after decoding is then 16 bytes (every 3 bytes becomes 4 characters, so we get 20 from the first 15 bytes and 2 characters more to encode the last byte; you'll note that the final character has fewer options than the other ones, because it really encodes 2 trailing bits (so we'd expect 4 different ones, including A for 00 etc.). Read up on base64 encoding if you want the nitty gritty.

This suggests that a hash of some sort is used. It could be MD4, MD5, MD2 and truncated variants of longer hashes etc. Or if it's sure to be reversible it could be a single block of say AES encrypted data.
Without access to more info it's speculation.


Preventing a socially-engineered transaction Can you explain what this blog means when it says:

  Something to think about when it comes to transaction signatures – demonstrating the need to keep the entire process off the PC (in this case) and on another channel entirely.

What does keep the entire process off the PC and another channel mean in this context? How would doing so help prevent that kind of attack?

For what I understood, keep the process off the PC means that the computing part of it must be done in a specific device, not in the browser that is running in the PC, since it's "easy" to use some keylog or affect the computer behavior.

And another channel means that you shouldn't trust just the browser communication, since the described attack simply puts an iframe over the real page and tricks user to insert attackers information in the device, instead of the real one. So, since what the user see in the page (in the moment that the required information to finish the transaction is inserted) is a fake one, banks / industry / security / users shouldn't use the internet - browser channel as a trusted one.


Can I rely on these GitHub repository files? I recently found the GitHub repository https://github.com/userEn1gm4/HLuna, but after I cloned it I noted that the comparison between the file compiled (using g++) from source, HLuna.cxx, and the binary included in the repository (HLuna) is different: differ: byte 25, line 1. Is the provided binary file secure?

I've already analyzed that in VirusTotal without any issues, but I don't have the expertise to decompile and read the output, and I've previously executed the binary provided without thinking about the risks.

Compilation is not a directly verifiable deterministic process across compiler versions, library versions, operating systems, or a number of other different variables. The only way to verify is to perform a diff at the assembly level. There are lots of tools that can do this but you still need to put the manual work in.


How WhatsApp identifies a specific user How does WhatsApp identify a specific user in order to forward the messages to him?

Here is what I did:

I backed up my iOS App from my old device
Restored the backup to the new device
Opened WhatsApp on new device

And it works without any need for SMS verification for new device.

So that's telling me WhatsApp does one of two things:

WhatsApp embeds your phone number during verification process into the app itself
WhatsApp embeds the verification code you get via SMS into the app itself and uses that as identifier to that phone number

The first method is stupid if it's true, because any smart guy can reverse engineering and modify WhatsApp code and embed any phone number he want to hack.

The second method seems smart since no one knows the SMS code except you, but this isn't secure either, because government or anyone who has a connection, for example, would have no problem getting all incoming SMS message for any phone and from there they can reverse engineer WhatsApp app and embed that as well.

According to Wikipedia

  Upon installation, it creates a user account using one's phone number as the username

  ...

  A 2012 update now generates a random password on the server side.

  ...

  WhatsApp follows a ‘store and forward’ mechanism for exchanging messages between two users. When a user sends a message, it first travels to the WhatsApp server where it is stored. Then the server repeatedly requests the receiver acknowledge receipt of the message.

The key is to notice that in all of this the App doesn't actually use telephony services, so it can't use your phone number in the traditional manner. Also note that when you install the app you're effectively just creating an account where your username happens to be your phone number. Think about it like if when you signed up for stack exchange they just assigned you a random number rather than letting you pick a name.

As to why you didn't have to reverify your account via SMS, if the iOS backup also backed up the app's data and configuration then the app would have everything it needs to connect as your account.

In terms of security - since account-password is the way just about every verified service works this method would be just as secure as your app's configuration files. One could argue it's more secure than other services since the user doesn't know their username/password and thus cant give them away (if you believe in security by obscurity that is).


Can I know that my bluetooth speaker has been hacked? I have a JBL Go bluetooth speaker paired with a Dell laptop running Ubuntu 17.10.

I suspect malicious intermittent activity on that speaker, but I am not sure and I am looking for proof or evidence it has been or not hacked.

For example, some months ago, I let it on by mistaking while I was away, and on my return, it was playing some sort of alarm sound. I thought it was misbehaving. But I don't know for sure. Now, it is making strange noise, not related to the tune it is playing.

I am looking at the log of bluetoothd on the laptop, and all I can see is the ready status of an already paired device.

Can I get more information, like dissassociation, repairing, reassociation, whatever ... ?

Will a MITM bluetooth attack ever leave traces in my log ?

Is there a setup that I can put in place to check for the possible hack ? How ?

P.S. I will run bluetoothd with debug info turned on, if it helps, but ...

P.P.S Those speakers come with a built-in microphone.

You can try to determine if someone else is logging into your laptop to play music. Using the command

sudo less /var/log/auth.log

and/or simply

last

will show you users who have logged on. Auth.log is privileged so you need to be root/use sudo to view it. From there you can determine if you were home and logged in at that time to see if someone has taken control of your Dell laptop. A note from the comments: if you think your computer may be seriously compromised, running sudo could give the attacker your password (if they don't already have it).

You can monitor the Bluetooth pairing history on your laptop as well using

cat /var/log/syslog | grep blue

That command opens the syslog file and searches for the word "blue" to see logs containing "bluetooth". That should show you pairing history. This is assuming a hacker may have broken into your laptop to play these sounds.

As for logs on the speaker itself, I doubt it would keep any and I doubt you'd be able to access them if it did. It's important to note that Bluetooth can only be active from one host at a time, so if someone is hijacking your Bluetooth connection, it would necessarily invalidate your pairing. If your connection has been hacked, you would need to reconnect your laptop to the speaker.

Some important questions for you (you don't necessarily need to answer them here, just something to think about):

How far away is your nearest neighbor? Bluetooth only has a range of 30 meters (100 feet) line of sight; less if it has to travel through a wall. In an apartment/flat you might run into this problem, less likely if you live in a detached house.
Have you ever had to reconnect your Bluetooth speaker to your laptop when it hasn't been unpaired? This doesn't necessarily mean it's been hacked, Bluetooth is notoriously unreliable, but it's one thing to consider.
Do you have to push a button on your Bluetooth speaker to get it to pair with your laptop? If you do, it's very unlikely it's been hacked unless the hacker has physical access to your speaker. Possible, sure... but very unlikely.

IMO, the more likely answer is that Bluetooth is unreliable and speakers can easily pick up interference. But you should run through the above questions just to be sure.


find if 0-day flash bug was exploited (on a particular machine) There have been several critical 0-day exploits in the past days/weeks in Flash alone. Nobody knows how long the 0-days have been exploited, and  it is reasonable to expect that there are 0-days being exploited at this moment, but we don't know.

The practice of patching/updating flash plugin after 0-day has been discovered seems inadequate to me.

How could one check, if particular machine has been exploited?
The 0-day in flash allows arbitrary code execution.
AFAICT, The executed code could be anything

Is there any way to find out, that an exploit was used and that some code was executed?

Well inadequacy is relative, in that you don’t know what they’re doing, but if you’re willing to do the research then you can find out i guess?

Sandbox the browser using something like Sandboxie, which will then tell you what its trying to access, you could also install Wireshark on a machine and point all traffic going out from that machine to the machine with Wireshark on it, so to see what packets are being sent and received.

Besides that, a console that will allow you to see what calls Flash makes to your local system.

Personally, I don’t use Flash anymore and opt in for HTML5, but then again there are not enough sites using it fully as of yet.


How can you check the installed Certificate Authority in windows 7/8? And know which are not default ones installed by Microsoft?

To view your certificate stores, run certmgr.msc as described there. The "root" store contains the root CA, i.e. the CA which are trusted a priori. certmgr.msc shows you an aggregate view of all root CA which apply to the current user; internally, there are several relevant stores (the "local machine" stores apply to all users, the "current user" stores are specific to the current user; and there also are "enterprise" stores which are similar to "local machine" but meant to be filled automatically from the AD server of the current domain).

See this page for a list of all CA that Microsoft puts in Windows by default; any discrepancy would be a local variation. The list is occasionally updated, and this is propagated to your computer through the normal Windows update mechanisms.


How secure is this method to remember security questions? So I found an interesting method of remembering those pesky security questions. Basically, the guy takes a hash of the question (IE what is your mother's maiden name?) and then appends his own password (I assume it is unique for each hash).
He claims this is a great way to always know the answer to your security questions without actually being truthful (some of those questions could be / used to be rather revealing) or knowing ahead of time which order they will be asked.

For Example:

Q: What is your mother's maiden name?
A: dc6bae2bdc569b1ef118bf6a497c65a0e70fadaa653bfadabffe5519708fb538password

where 'password' is actually a random and secure one (presumably stored in a password vault and specific to each question hash).

Instead of:

Q: What is your mother's maiden name?
A: mommy

Is this method really secure or just a waste of time?
My question to him (and you guys) was why bother with the hash? Why not just keep a secure list of questions/passwords?

I generally dislike security questions in general; they usually ask for information that is more or less public. Mother's maiden name? Ancestry.com will tell you that. Your high school? Facebook, LinkedIn, any of a number of social media sites that use the info to suggest potential friends will not only have it, they'll advertise it if you aren't careful with your profile settings.

In this case, your source agrees, and instead of providing the actual answer, is simply making this scheme an alternate password. If the passwords he is using are random, strong and unique, that should be all that's necessary. If he's using a common password, the question hash is security through obscurity; once the fact a hash is used, and the method to generate it, are known to an attacker, it's broken.

Either way, it's not a total waste of time, but the simple fact that the way you do something is a secret outside the digital world cannot be relied upon for security within it. In this guy's case, it's not a secret that he uses this method, so he can no longer count on it to protect him and is a waste of time in his own case. The practice of using an alternate password as the answer to a security question (unrelated to the actual real-world answer to the question) is relatively secure on its own, as long as both the user and the website take the same care to protect the confidentiality of the security answers as the password itself.


Difference between STRIDE and Mitre ATTACK When looking at threat models I came across STRIDE (from Microsoft) and then came across Mitre ATT&CK, they seem to be different - one is a threat model and the other is a threat intelligence methodology.

What's fuzzy to me is exactly what are the difference between these two categories. In other words, why can't someone threat model with Mitre ATT&CK?

What is the fundamentals that I'm missing?

MITRE ATT&CK describes the different stages of an attack, derived from the Cyber Kill Chain model, and then points out the main tasks of each stage. Finally, it describes a list of common TTP used for each task.

It is useful to establish indicators to catch an attacker at any of these stages, as it mostly describes an arsenal of techniques and the general flow of an attack.

What it doesn't capture so well is which vulnerabilities the attacker is going to exploit and the general attack categories. This is what STRIDE and other threat modeling techniques do, typically with a more system-centric approach.

From "Threat modeling: designing for security" by A. Shostack:

  When you threat model, you usually use two types of models. There's a model of what you're building, and there's a model of the threats (what can go wrong).

Although STRIDE doesn't really model the system, it does provide some broad categories of attack, which are not tied to a specific stage nor to a specific version (like the detailed TTP described by ATT&CK).

Moreover, but this is more of a personal consideration of mine, generic threat modeling methodologies like STRIDE can be easily adapted to consider not only IT security, but information security as a whole.

Both ATT&CK and STRIDE are useful, but for slightly different purposes.


Additional security of keyfile on top of a master password for KeePass I use KeePass + Dropbox to manage and synchronize my passwords across my devices. This system works really great and I trust KeePass' security model.

However my biggest remaining concern is the master password as I am worried about not being able to protect my PC against keyloggers. To alleviate this fear I want to introduce a second factor of authentication.

KeePass only really allows for using a keyfile as a second authentication factor, and while storing a keyfile on a USB thumb drive does seem like a secure solution it also is too restrictive for me. If I was to use a keyfile, I would probably store it on Dropbox but does this really add any additional security at all? My thinking is that if my master password is compromised then in order for the attacker to succeed he will also need my KeePass database. If he has access to that then he will most likely also have access to the keyfile so I've gained no additional security.

Any comments or suggestions for a better setup which doesn't add too much overhead?

I think your security model has a couple of potential flaws here - I'll list the potential issues I can see, and you can let me know if they are valid worries in your particular circumstances:

If you have a real worry about not being able to secure your computer against keyloggers, the implication is that an attacker could install anything - which to my mind means game over: they can extract all the data from your KeePass whether you log on with a token or not by grabbing that data the next time you use KeePass.

In addition storing on Dropbox means they could potentially carry out this attack from other locations by sharing your Dropbox as per this vulnerability.

Your only real protection against a threat actor which you think can compromise your machine is to not use that machine (unless you can configure it in such a way that they can't compromise it, of course) and do something like use KeePass on a mobile device (where your risk becomes one of losing your device or having it stolen).


How good/bad is this implementation to secure password? I've just started new project and decide to try something new, so I'am not using anymore EnityFramework and Identity framework. I Decide to try MongoDB, so i wanted to design from scratch storing Users in database.
In database I'am going to store password and salt. My salt generator looks like this:
internal class SaltGenerator : ISaltGenerator
{
    private const int SaltLength = 32;

    public string GenerateSalt()
    {
        var saltBytes = new byte[SaltLength];
        using (var cryptoService = new RNGCryptoServiceProvider())
        {
            cryptoService.GetNonZeroBytes(saltBytes);
        }

        return Convert.ToBase64String(saltBytes);
    }
}

and Password hash generator:
internal class PasswordHashGenerator : IPasswordHashGenerator
{
    public string HashPassword(string password, string salt)
    {
        if (string.IsNullOrEmpty(password))
            throw new ArgumentNullException(nameof(password));

        if (string.IsNullOrEmpty(salt))
            throw new ArgumentNullException(nameof(salt));

        using(SHA256 sha256 = SHA256.Create())
        {
            var computedPassword = $"{password}{salt}";
            var passwordBytes = sha256.ComputeHash(Encoding.UTF8.GetBytes(computedPassword));

            return Convert.ToBase64String(passwordBytes);
        }
    }
}

And to test that everything is fine, very simple unit tests:
[Fact]
    public void Should_GenerateSalt()
    {
        // Arrange
        ISaltGenerator _saltGenerator = new SaltGenerator();

        // Act
        var salt = _saltGenerator.GenerateSalt();

        // Assert
        Assert.False(string.IsNullOrEmpty(salt));
    }

[Theory]
    [InlineData("testPassword", "testHash")]
    [InlineData("nextTestPasword", "nextTestHashHash")]
    [InlineData("testPasswooooord", "testHaaaaaash")]
    [InlineData("c98b7acd-19af-45a0-b133-96a43c8d2204", "eafe4fbb-4480-462d-9d3e-6d20a2128e8a")]
    public void Should_GeneratePasswordHash(string password, string salt)
    {
        // Act
        var hashedPassword = _passwordHashGenerator.HashPassword(password, salt);

        // Assert
        Assert.False(string.IsNullOrEmpty(hashedPassword));
        var nextHashedPassword = _passwordHashGenerator.HashPassword(password, salt);

        Assert.Equal(hashedPassword, nextHashedPassword);
    }

My question: How good/bad this code is? What should I change to be sure, that password is protected enough? On the internet i also found somenthing like this:
How to Use Argon2 for Password Hashing in C#
Is this implementation much better?

Password hashing, like most cryptographic operations, is something you should never try creating from scratch, and should avoid even implementing from somebody else's design unless there's some reason you can't use a well-tested library.
The obvious flaw in your scheme is that SHA256 is a fast hash, which means it's possible to attempt to brute-force it at a rate of literally billions of candidates per second on a single decent GPU. It also takes almost no RAM - it's designed to be viable for low-power embedded processors - which means it can be parallelized extremely efficiently not only in GPUs but also in things like FPGAs and ASICs, which are even more efficient. The use of a salt means that an attacker can't pre-compute the password hash candidates (they can't create a rainbow table), but they can take the hash out of the database and stick it into a cracking tool to try the billion most likely passwords for each user in under a second each, using commodity hardware or relatively cheap time on cloud infrastructure.
The solution is to use a purpose-made password hashing algorithm. All of these, in addition to using a salt, have a tunable cost, also called a work factor, which controls how computationally expensive it is to hash a password (and hence to check a password candidate). Generally, you want to set this cost as high as possible without overloading your login server. For reasonably sensitive sites, recommendations of 100+ms per password are common. If it's a local system (such as for logging into a local app), you can go much more than that. Good password hashing algorithms also use significant (and, for the best ones, tunable) amounts of RAM, which make parallel attacks much more difficult.
As of April 2021, algorithms worth considering are all going to have implementations for common platforms. In decreasing order of security features, they are:

The argon2 algorithm family, most typically the argon2id variant. Supports tuning CPU and RAM costs. Winner of a recent (concluding in 2016, IIRC) big contest to develop the best password hashing algorithm, it is the newest but is built with knowledge gained from past attempts and extensively reviewed and well-tested.
The scrypt algorithm, which is the first one of note to have a tunable memory cost (in addition to tunable CPU cost). It's been around longer than argon2, if you want to avoid the cutting edge, but honestly I don't see much reason to use it now that argon2 exists.
The bcrypt algorithm, which is somewhat showing its age but is very widely used, with library implementations for everything. Its memory cost is fixed, and shows its age somewhat today, though it's still generally inefficient to parallelize too heavily. Atypical in that it has a max password length, though in practice you won't run into it.
The PBKDF2 algorithm family, ideally using one of the stronger hash functions (a member of the SHA2 or SHA3 families). It is the oldest on this list (and technically created for deriving keys from passwords, rather than hashing them for verification, though it's extremely widely used for the latter purpose too), and lacks any memory hardness at all. Aside from interoperability with legacy code, the only place I would recommend it is if you have a legal requirement (such a FIPS) to only use specific constructions. For all other purposes it is inferior to the above options.

Other considerations:

There's nothing wrong with using a big salt, but 32 bytes - 256 bits - is possibly overkill and can be reduced if you want to save some DB space. Library implementations of the recommended functions typically use 64-192 bits as their defaults, although some go higher.
There's not really any reason to avoid zero bytes in your salt, though - especially with such a large salt - it doesn't hurt anything either.
In general, libraries will offer to automatically generate the salt for you, and it's fine to do so.
You'll want to adjust your cost(s) over time, keeping up with upgrades to your hardware.
One nice thing about most libraries is that they store the salt and costs in the output (the password verifier - including the hash digest - that is kept in the DB) and provide a simple verify function that takes a password and a verifier, extracts the salt and costs from the verifier, and uses them to re-hash the password and check for a match. This both simplifies your logic, and means you can adjust things like costs and salt size over time without explicitly worrying about backward compatibility (though you may still want to re-hash with the new inputs and store the new output for each password that verifies, after you change the inputs).


Wifi encryption vs SSL encryption I am a bit confused about two types of data encryption when I am connected to a wifi.

The first encryption is used as a part of the wifi connection. The technologies used are wep, wpa, wpa2.
The second encryption, SSL, has nothing to do with wifi.

To my understanding, both encryptions are optional. So my questions are:

What is the difference between these two data encryptions?
Do I need to have both?
Why can't I just use SSL encryption for securing the wifi connection?

This is where an understanding of the OSI model is useful: the different types of encryptions happen at different layers of communication.

WiFi encryption protects all communication from your device from the local network (i.e. your coffee shop's network), but not anything past the local network (i.e. the rest of the Internet). WiFi encryption is 'optional', but set up by the WiFi network (not optional as a user).

SSL encryption protects the individual connections you make with the individual destinations (i.e. connections to websites). This also protects specific communication from your device from the local network, but it also protects it all the way to the destination (some exceptions apply).

Here's the problem: you do not always have control over what connections are being sent out by your device. Without the local network protections (i.e. WiFi encryption) you expose all of that to anyone listening.

So, the best idea is to use both the network encryption (Wifi) and SSL encryption wherever possible. You do not have as many options as you think, and you do not have as much control over what is sent out by your device than you think.


Are botnet nodes made to stop working during office hours? Some network guys at my work seem to think that a client that we monitor may be part of a botnet, but the spike in traffic that we see at night always stops at the latest around 8am in time for office workers coming in.

Before bothering the customer I'd like to know if botnet nodes are known at all to stop working as part of a botnet during office hours. Is this kind of thing known to happen at all?

Botnets and malware, especially sophisticated ones, are made to be as stealthy as a malware could be. The fact that the piece of malware you're talking about "stops working" during office hours makes me suspect a data exfiltration bot more than a general-purpose zombie.

The first example of malware that comes to me is Lazarus/Bluenoroff, it specialised in financial cyber attacks, and where attackers operated out of office hours according to the victim's schedule and timezone to avoid detection.


Tor and regular browser side by side. Does that make sense? Can I use a Tor browser session and a regular Firefox session side by side without corrupting the security of the Tor session?

E.g. when I download a new Eclipse version or when I'm searching for code snippets I think the NSA won't find out more than if I'm a mediocre programmer or not. But for more sensitive searches like insurances, I don't want my surfing as unsecured. So it would be nice if I could keep both programs open and switch when needed.

Yes you can run them side by side and not corrupt the security. This is because your Tor browser will send everything through a Tor proxy (including DNS requests) and your normal browser won't. Do mind that:

If the NSA really would like to know what you are doing then they will find a way, bug your house, target your computer with malware, ... .


Open SFTP on the main server - the safe way? We need to open an SFTP to allow some of our clients to upload files to our server. As I see it right now, there are two options:

Open SFTP on our main server with restrictions (directory, user, size, etc).
Create a micro server that will only respond to SFTP and upload the files to an S3 that our main server can read from.

Option 1 is faster and easier to maintain. Question is, how can I make sure it's safe?

The security measurements I want to take are the following:

Run the SFTP with a restricted user.
Limit SFTP to a single folder.
The folder from 2 will be on a secondary volume and not our main volume, just to make sure it doesn't get full.

I found these instructions: https://passingcuriosity.com/2014/openssh-restrict-to-sftp-chroot/ which seem to cover pretty much what I plan. Only difference is the dir I'm locking the user inside would be on a different volume.

Now here's the question: do you think the plan above is safe enough? Are there any security hazards I'm missing here or maybe you think opening an SFTP on the main server is completely insane and should be avoided at all cost?

I think each service should be separated. IDK if you have the possibility of creating different virtual machines or setup different servers for each service which is more secure. As simple as if you are hacked, only that machine is hacked. To mix services in the same machine usually is not good idea. Of course it depends of the environment, the target and the structure.

Anyway, if is something you know is not the best but is going to be done, try to secure it:

Change the standard port. <- this practice is not a very good protection... you know if scanned the service is going to be shown anyway, but maybe you can avoid some bot's scanning.
Restrict (whitelisting) the ips. Try to allow only certain ip addresses. <- this can't be done always, it depends if your clients are going to be always the same or if you have itinerant clients.
If your hardware or firewall supports it, use port knocking. <- this is nice for this kind of situations.

Summary of what port knocking is:

Is a method of communication between two computers/devices. At first sight, when the client ask to the server for a service, the port is shown as closed, but if you ask for certain ports (a combination of them in a specific order), then the port is opened. This process of knocking is what gives port knocking its name.

Good luck!


nmap -sP scan question I'm trying to find the IP of my other computer on the network for penetration testing, but when I do -sP 192.168.1.1/24 I get all hosts are up (up to 255), and it doesn't identify any particular IP that is connected to my network...why is this happening? How do I combat this?

A brief from Nmap website:

  -sn (No port scan)
  This option tells Nmap not to do a port scan after host discovery, and only print out the available hosts that responded to the host discovery probes. This is often known as a “ping scan”, but you can also request that traceroute and NSE host scripts be run. This is by default one step more intrusive than the list scan, and can often be used for the same purposes. It allows light reconnaissance of a target network without attracting much attention. Knowing how many hosts are up is more valuable to attackers than the list provided by list scan of every single IP and host name.

So, the full command will be: nmap -sn 192.168.1.0/24 and if you're sure about some target, you can use -Pn (No ping scan).

For more info, check Nmap host discovery page.


Password management/synchronization? Is there a good enough service I could run on my own home (Linux) server that I could use for storing/accessing/synchronizing passwords so they could be available for me from multiple computers/places?

I'm thinking of something like Xmarks BYOS or Firefox weave but that would not be only for browser passwords, but passwords in general? A place where I could put my SSH, FTP, OS, etc. passwords? Maybe something like KeePassX but synchronizable?

And that in the same time, all these passwords are on my own server instead of being somewhere in the cloud? Standalone service, webapp service, doesn't matter...

Suggestions?

KeePass Password Safe is an open source solution you may want to check out. It is mainly designed for Windows but it can be ran from a Linux box, details here.


How secure is aSSL (javascript)? Does it effectively mimic SSL? Some of you may be familiar with the aSSL project, which uses AJAX/PHP to mimic the SSL protocol. It uses RSA 512 or 1024 for the keys, and AES for the actual data. It looks impressive to me in concept, but am curious to see if you guys see any obvious intercepts that could/would reveal the keys being passed. As we all know, the JS to PHP encryption technique is typically useless as the key is passed in the open to the client side. This appears to be a more advanced approach.

Here are the steps:
1. The browser calls the server to start the process.

The server returns its RSA modulus and the public exponent.
The browser generates a random exchange 128-bit key, encrypts it using the server public key and passes the encrypted exchange key to the server.
The server receives this encrypted 128-bit exchange key, decrypts it with its private key and, if the result is ok, returns the session duration time.
The browser receives the session duration time and sets a timeout to maintain alive the connection.

The URL to the project is here:
http://assl.sullof.com/assl/

If this has any potential, I have some ideas on how to further improve on the handshake and secure further the client side.

How does it protect from man in the middle attacks? From what I gather, it doesn't at all (can't think of a way it could actually). That makes it perfectly useless.

SSL/TLS kinda works because because you trust the software telling you the connection is secure (in the usual case your browser). When you download the code telling you that the connection can be trusted from an attacker, all bets are obviously off.

I may be wrong as the documentation is quite thin, but it doesn't look good at all (to be polite).


Computer-level logging by financial institutions I am looking for the best approach to recognizing a specific computer and saving that computer as a "safe" login machine. My intuition points me to using cookies, but what value do I store in there to make sure it's safe? What data do I cross-reference to make sure that cookie wasn't stolen off of another computer?

Some examples of what I am trying to accomplish are the websites of major banking institutions, such as Chase, Bank of America, etc. They seem to remember if a computer is accessing the site for the first time.

I may have stated this problem strangely, but I don't know of any other way to describe it--maybe someone can chime in with the correct security terminology for this technique. Although I'm relatively new to security, I am willing to learn!

Thanks

I'm not certain specifically what methods the banks you listed use for this, but I would do a combination of many things, mostly server side and stored in a database.

Disclaimer: Not any one of these things are by any means fool proof.

User agent
First and second octet of IP Address (may not be feasible with dynamic IP, this is still processing in my head)
Average days of week/time of day user logs in
Browser cookie containing a random token

These things create a signature of the typical environment a user logs in from. When that changes, we prompt for an additional authentication item.

When a user logs in and one or more of those fields stored in the database doesn't match, I would prompt for the secret phrase, or whatever field you use.

I'm sure there are other ways, and other fields you can store to compare against, these are just a quick few that came to mind.


Are malicious drive-by-downloads detectable based on file type/mime type? Drive-by-downloads are automatic downloads without user interaction.

We provide a free service for uploading large files and notifying users by email (this one, something like ge.tt or WeTransfer).

By default when a user clicks a link in the email he gets, the opened URL automatically downloads the file (via the http-equiv="refresh" meta tag).

To minify the risk for the user while still keeping the usability up, I planned the following:

  Based on the file extension of the uploaded files, either do an automatic download or provide a manual download link only.

Currently, I can think of file extensions like:

exe, com, bat, cmd, msi, vbs, js, jscript

to be filter as "unsafe for automatic download", while file extensions like:

bmp, gif, jpg

are considered to be safe.

My question:

Do I get any benefits (even if only minimal) when omitting automatic downloads for certain file types?

Or is this merely some kind of naive "security theater"?

(I also have automatic virus scanning and removal on the servers)

To summarize:

People can upload any content to our servers and let our servers notify other users by email with a download link to the previously uploaded file.

I want to ensure that our service is not being misused to spread drive-by-download malware.

The download URL in the email is a potential drive-by-download source, since it is public available and thus could be distributed by malicious persons to spread malware.

Drive-By Download, or a Basic Trojan Horse?

  Do I get any benefits (even if only minimal) when omitting automatic downloads for certain file types?

If you mean you're trying to detect and prevent a drive-by-download when it happens to you, then you get minimal benefit if your attacker doesn't know another method, but it's essentially a security theatre.

However, what you're describing is not a drive-by-download.

There are lots of different ways to initiate a drive-by download. Take for example the ability to write any type of file with an extension to the user's local storage, and then rename it to an actual executable, then execute it.

Currently, you can, for example, use the HTML5 cache to write an executable with any extension to the user's computer, then rename and execute the file with Flash. Pretty ebil, huh?

What exactly is a Drive-By Download?

I've updated this post based on Uwe Keim's new comments:

  "Sorry, probably I described this in my initial question too confusing. We provide a service where users can upload files and let our system send emails to other users with a download link that goes to our website. Basically to "send" files that are too large for email attachments."

This isn't really a drive-by-download issue, although it could potentially lead to it.

A drive-by-download is when you force a user to download and execute a program automatically without their input. They are unaware of the file's existence, there is no download dialog, and it happens behind the scenes. While yes, you can serve them a malicious file whose existence they're aware of - which they execute on their own - that is not a drive-by download. That's a run-of-the-mill basic trojan horse.

How Could Someone Cause A Drive-By Download On My Users?

I am adding this block just in case, since I want you to understand how a drive-by-download could work; I do not feel you understand what it is. You may ignore this section if you have viable XSS/SQL injection protection already.

This could be done with an XSS/SQL injection vulnerability. Make sure you check, not sanitize, your input. One way is to make sure you have a regex of the file name which allows all of the common file names (A-Z, a-z, 0-9, period, apostrophe, brackets, etc. This isn't really sanitizing your input: it's simply disallowing bad inputs.

Apostrophes should be allowed in file names as well. Use prepared statements and not string concatenation in any form. You'll want it to be ascii only. When outputting your file for download, you'll want to replace any special characters.

Assuming you are using ORM, or serialized data, you'll be fine when outputting non-breaking characters. It is highly recommended, though, that you sanitize the output to replace all potential page-breaking tags with their respective html entities because - dons tinfoil hat - you'll want extra protection just in case the attacker somehow got around your regex check due to a funny exploit.

You do NOT want these tags getting injected on your pages: <% %>, <?php ?> <script>, </script>, or anything with < or >

null/length check + Regex input check + prepared statements/parameterized queries + output sanitation = Neatness.

Are malicious drive-by-downloads detectable based on file type/mime type?

Anyone could give a file any extension or mime-time they want, and reassemble it later with an exploit, so no, it's not detectable with this method unless the malware author made a serious mistake.

Furthermore, you also need to worry that your anti-virus won't detect it right away. Most anti-viral programs can be defeated through obfuscation, sadly. If relied on alone, it's essentially a false sense of security these days, in many areas.

And the method you're describing is not a drive-by-download; it's just a trojan horse.

Serving Executables That Download Automatically

Most websites do not try to get you to automatically download a file. Malware websites do. Most websites legitimate will implement something that says something like, "If your download doesn't begin in X seconds, click here."

This is a better idea for usability reasons mainly, but it will not offer any extra security at all, although it may prevent people from leaving your website for various reasons.

I think you could get away with presenting a download page that tells the user exactly what they're downloading, rather than an automated link. That could be a very convenient thing to track down some , and if the user

Conclusion

It's a bit of both. A little security, and some security theatre.

It will not provide much benefit unless someone exploits your download system and injects a fake download into it, but they could do that whether you implement this change or not, though.

However, presenting a download page could be very convenient, as it could potentially prevent the user from downloading the wrong file.


Does anyone know how Avast File Reputation works? Whenever I'm programming in C++, after I run a new executable, Avast suspends it informing me that "not much is known" about the file and asking if I'd like to continue execution or terminate the process. It's done this to a few files I've downloaded from the web too. Sadly, I just got a virus. So how is it while it's so paranoid a virus can sneak through?

I could see it if Avast reported "not much is known about this file" but to categorize a virus as safe certainly is a large slip up.

File reputation simply put is how much is known about the file in hand. If you have a file (executable) that you have created, the file will not be known on the internet. Well known files are the ones that have been around on the internet for a while and have been tested negative for malicious code. For example, Google Chrome executable would be a well known file as many users would have used it and many AV agents reported it to the reputation server to be clean. when you run an executable file, your AV agent will test it against virus signature. If the file did not match any signature, the agent (the ones that support reputation testing) will query the server about the information on the file. If many userss have used it and it was not reported as malicious, you get a response that the file is safe. Some times the response is that the file has no reputation as it is new and you should be careful if you dont know the origin of the file. I believe this is how you got the virus.


Can I get a windows virus on macbook via usb transfer? Suppose I had a file (a pdf file) on an infected windows 10 PC, I use a usb drive to transfer this file from windows 10 to a Macbook.

Can this Macbook then be infected? Or become a carrier that infect any other usb drives connected to it?

Depending on the circumstances, nature & capabilities of the virus/malware.

The very fact that a USB drive is writable and does contain memory space makes it susceptible to being infected.

However, infecting a new host with a different OS (in your case, MACOS) is also another set of risks. Certain viruses/malware are created to cater to certain machines and OS hence if they are configured in a way so that they could run on cross-platforms then yes they can infect your new host.

It is also good practice to turn off auto-run/auto-play when USB devices are connected to a machine. This prevents programs from running automatically upon insertion.

Now let's move on to the file(PDF). In the above paragraphs, I have discuss the idea of plugging in the USB drive to extract the said file and the risks of that, but how about the file statuses? Is it infected?

The answer is that any file can be infected & armed by other viruses/malware, to determine whether a file is malicious is not solely based on its file extension.

All that being said above, it boils down to the very nature of the virus, there will be risks & vulnerability involved, for sure. Just 'virus' itself is very vague.


Production frontend server receiving several unknown requests My production server logs (and notably, not local server or the live public facing test server) is receiving several requests at /show.aspx and /ogShow.aspx, with various query strings attached to it (e.g., /ogShow.aspx?name=ogFoot&line=0&from=oGateeu). It happens quite frequently throughout the day.

Any guesses on where it could be from? I have no routes that look anything like that. Do I have any reason to be concerned about an attack?

As @multithr3at3d alluded too in his comment, it is very common to be "scanned" by random nodes on the Internet.

There are a lot of attackers who will just try all sorts of combinations to see what services you are running or to try to take advantage of known exploits. Sometimes the attackers do recon and target their attacks, but other times they just try anything they want - maybe they try a lot of different websites when a new exploit is found.

While this activity can at first be scary, its relatively common. There is also more benign activity like search engine spider. Another possibility is that there is some automated script with legitimate purposes, but was accidentally configured to point to your server, though its more likely you are just being scanned.

If the scanning activity is coming from one specific IP or a list of specific IPs you can just block them at the network firewall level or in your web server config. There are also WAF technologies and vendors you can put in front of your site, but that usually only makes sense financially and time wise if you are a large commercial website.


If Signal database leaks, can somebody bruteforce access into my contact's chat history? Recently Signal started forcing users to create a pin. I'm curious about the feature - doesn't it make Signal less secure if their database gets compromised? In other words, suppose that I'm chatting with someone from my family and they set their pin to 1234. If Signal's database leaks, is it possible to brute-force passwords of my relatives and - as a result - see logs of their conversations with me?

There is a Signal blog post titled "Improving Registration Lock with Secure Value Recovery" that partially addresses this question:

By transitioning Registration Lock PINs to Secure Value Recovery, we can restrict offline brute force access for those PINs.

To understand how Secure Vault Recovery works under the hood, another post titled "Technology Preview for secure value recovery" must be read. Here's how the process works from a high level, according to the article, with some key notes included:

Clients use Argon2 to stretch the passphrase or PIN into a 32-byte key.
Two additional variables are generated from this stretched key: an authentication token, and (combined with a randomly generated input) a master key. This master key can then be used to derive additional application keys used to protect data stored in “the cloud.”
The master key incorporates c2 (256 bits of secure random data), which requires limited access to be resilient to offline brute force attacks.
auth_key, part of what is used to reconstruct the master_key, is put into a secure enclave, which is "isolated from the host operating system and kernel," with c2, which enforces a maximum failed guess count. "For example, if we set the maximum failed guess count to 5, then an attacker who obtained access to the service (or the service operator) would only get 5 password guesses rather than an unlimited number of guesses that they could attempt as fast as their hardware would allow."
Finally, because this is provisioned by SGX, and SGX supports remote attestation, "clients can transmit these values into the enclave over an encrypted channel with the assurance that they are actually being stored and processed by an enclave rather than someone pretending to be one."

The article goes further down the rabbit hole to address concerns that spring up with this approach, but this seems to me to be a good starting point.


How to create dictionary to prevent weak passwords? I've been tasked with adding a "dictionary check" against user's passwords to prevent weak passwords.  Unfortunately, that is about as much guidance as I've been given and I need some help deciphering what it means.  It would be super-easy to download a standard English dictionary file and compare the password to the words in the list, but of course the policy requires an 8 character minimum, 1 each upper- and lower-case letters, 2 numbers and 1 punctuation so no password would ever be found in the dictionary.

Rather than just malignantly comply and use a standard English dictionary, how should I interpret this in a sensible way?  Should I use it to disallow Tr0ub4dor&3-type passwords?  Should I reject passwords that contain dictionary words verbatim?  (That seems dumb because there go diceware passphrases...)

The actual "dictionary creation"

i.e. figuring out if your base dictionaries plus common rules results in the password they want

First and foremost, realize that when we're talking about password cracking, "dictionary" means a list of base password candidates, which can be used both by themselves, or - much more fruitfully - as part of a rules based attack.

The Hashcat forum has a list of wordlist locations.  To prevent link rot, a few of them are:

  http://www.skullsecurity.org/wiki/index.php/Passwords

Start here

the phpbb list is a really excellent, very small list of 184,389 words
the rockyou list is a good next step, at 14,344,391 words

there are also filtered rockyou variants in various places with different sizes and other criteria; look around if you want.

  http://hashcrack.blogspot.de/p/wordlist-downloads_29.html

includes links to the larger Purehate and Xploitz lists plus many sites

  http://packetstormsecurity.org/Crackers/wordlists/

lots of the old standby lists; toss them all together if you like, these have been around a long, long time.

  http://www.md5this.com/tools/wordlists.html

wordlists in several languages, plus a huge english wordlist in pieces.

For some guidance on what a rules back dictionary attack can do, take a look at Hashcat for the types of rules it supports, and note that when you have the plaintext user password, it's easy and very, very fast to apply many rules in "reverse"; i.e. given an actual password, could it have easily come from a base cracking dictionary word plus some number of rules?

For instance:

You can handle all the uppercase/lowercase rules with a simple UPPER() equivalent and an all-uppercase dictionary - if you find it, it's weak.  (JacQueLinE)
Appending/prepending numbers purely to meet length minimums is a simple pattern match - if the last/first N characters are numbers, and the remaining length isn't enough, it's weak. (Riddick123)
Remove N numbers from the beginning/end, uppercase it, and check the dictionary for the remainder (JacQueLine12)
The above, but N-1 numbers and/or symbols (#1JacQueLine)
The above, but date formats. (JacQueLine02121995)
If the last/first N-1 characters are numbers and the last/first is a symbol, and the remaining length isn't enough, it's weak. (!JacQueLine1)
Take out one character at a time, see if it matches the dictionary.  (jacqu$eline)
Combine some of these.
Reverse all of these.

Do a pattern-match for very common dictionary words as subsets, pull that substring out, then search again; figure out your limit for keyspace on combinatorial attacks

correcthorsebatterystaple

correct: 1813th most common English word, row 16828 on phpbb, row
9871 on Ubuntu american english small.
horse: 1291st most common English word, row 14820 on phpbb (horses is
at row 1723!), row 21607 on Ubuntu american english small.
battery: 3226th most common English word, row 7775 on phpbb, row 3644
on Ubuntu american english small.
staple: 6 characters, all lower case, not in the top 5000 most common
words. row 40524 on phpbb (staples is at row 3852!), row 42634 on
Ubuntu american english small.
Therefore, correcthorsebattery would get all three words pulled out by pulling the top 4000 English words out, and thus fits into a keyspace of 4000^3.  correcthorsebatterystaple passes that test, or even top 4000^4 (solely because of staple).

Many crackers start with brute force for tiny passwords, then small wordlists and large rulesets, then large wordlists - the largest I'm aware of is over 30GB, and includes almost every password found to have been cracked by anyone on a given popular forum, plus many, many other large wordlists.

Find yourself a happy medium - fast enough to be performant, large enough and with enough "rules" to cut out the first few fast passes of cracking software - if you are using PBKDF2 with enough (hundreds of thousands) of iterations, or BCrypt or SCrypt with a high enough work factor, then only small dictionaries + large rulesets and large dictionaries + small rulesets will be practical attacks for a few years.

Reducing the user revolt

You are going to anger the userbase to some degree, just the same as you did when you said they need to meet your complexity rules.

When you say "password", "Password", "P@$$w0rd", "P@$$w0rd1", "P@$$w0rd123", and even "P@$$w0rd123!" are bad passwords, you're going to annoy them. When you say "Jennifer2007" is a bad password, they're going to be frustrated (and perhaps Jennifer will be upset, too!). Manage their frustration as best you can, and simply accept some. Personally, I would recommend actually being explicit - tell them their password is a word in known cracking dictionaries plus two numbers, which is a normal cracking rule!

Note that one major purpose of adding this is to educate users on what a weak password is, so they have some understanding to mitigate their frustration.

As part of educating, perhaps show them some alternatives you generate that pass your own tests, if you flunk their password, so definitely let the users know which particular rule they hit, whether it was "password is a word in password guessing wordlists used by attackers" or "password is a word in password guessing wordlists used by attackers plus a toggle case rule plus a number on the end".

1) Fully random passwords

2) Fully random passwords translated into bubblebabble or another pronounceable subset

3) correcthorsebatterystaple type passwords, but with longer and uncommon words.  For instance, take the Ubuntu american english insane dictionary, subtract out all the words in the american english small dictionary, and select N words of at least 7 characters in length.  This leaves you without any really short words, and without the most common words.

4) a mix of 1, 2, and/or 3.

Then your users can, if they choose, simply pick something you showed them (over HTTPS with the best cipher suites you can get away with, of course).

Personally, I would also strongly suggest raising your length limit; about 14 is what I would recommend, but for most userbases that's just too long.  Try a minimum of 12 or even 10, enough so a fully random password might have a slight amount of value at the minimum length and character set.

Much of this was taken from my answer to Should I reject obviously poor passwords?, though that answer has signficantly more math and explanations of why involved.


How can I securely authenticate the client application sending me data? We have a web service logging/recording user data sent over https by our client application. Is there a way to securely ensure that the data is getting sent by the client application and not by a fake tool impersonating our app? Ideally, I wouldn't like to have to resort to things like hiding an obfuscated key in the client or other “security through secrecy” techniques…

You can't.  A server fundamentally can't trust a client (there are some exceptions - if the client machine is hardened (hardware verifies firmware, firmware verifies OS, OS verifies every application running), it might be possible to do that (but not really - someone with a soldering iron could always modify the hardware verification), but if you don't 100% control the client, you're kinda out of luck.

You need to ask yourself: What are the risks of the client uploading bogus data?  What are the consequences of not authenticating that it's your application uploading the data?  One hard question you should ask: Does the client have an incentive to upload bogus data?
If the user doesn't have an incentive to upload bogus data, they probably won't bother.

One thing that you can do: You can authenticate the user running the application (via any one of a number of authentication mechanisms) and then save the uploaded data along with the authenticated user ID (and IP address).  That way if the user does upload bogus data, you can track back who made the change.  Of course you've now made the data PII which may have privacy issues for your service.


Random check for SQLi/XSS - legal? I like the idea of white hat hacking. That's why I'd like to become a pentester in the future. But now I like to learn a bit and was wondering, if it's legal to search for SQL injection, XSS and some other Basic stuff for webapplications, with the intention to report them to the webmaster.

If this matters, I'm from Germany, we have the so called "Hackerparagraph" (§ 202c StGB) which criminalizes the attempt of trying to break into a system or even develop such code/tools. Theoretically, a successful injection would be an act of crime.

But what is, if this is for a good cause? Should I fear that the admin will report my action to the police?

E.g if i write the admin an email like this:

  Dear Admin,

  I found a vulnerability for an SQL Injection on yout Page XXX.
  I had/have no intention to share this vulnerability with somone except you.

http://domain.de/site.php?cat=1&s_id=4818&p_id=13807&r_id=4&nr_id=647568+%27and+%271%27=%272%27+union+select+1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,version(),7,8,9,0,1,2,3,4,5,6,7,8,9--+

  I'd recommend you to [explain various things about security].  I hope
  this helps you and your company to guarantee the safety of yours and
  your customers.

As other people have already mentioned the practices you mentioned should be avoided, to stay on the safe side of things.

However, some companies have bug bounty programs in place that basically encourage and reward the report of vulnerabilities discovered on their platform (e.g. Google.) Also, there are platforms like HackerOne that aggregate bug bounties from different companies.

Of course companies that set up these bug bounty programs are usually very robust, so you'll have to try much harder to discover potential vulnerabilities.


Is the double submit cookie pattern still effective? I ran across this OWASP paper and was frankly confused. I thought this pattern was still one of the cornerstone strategies against CSRF but the paper seems to say it's broken. Should this pattern still be used?

https://www.owasp.org/images/3/32/David_Johansson-Double_Defeat_of_Double-Submit_Cookie.pdf

Double-submit cookies was always a relatively weak CSRF protection, at least as typically implemented. Any attacker who can set a cookie - either via a cookie injection vulnerability in the app or via man-in-the-middle (MitM) attack - can defeat the typical implementation of double-submit cookies; this has been known for many years. It also requires that the CSRF-protection cookie be Secure-flagged, or a MitM attacker can usually steal it.

There is actually at least one thing that changed in recent years to make double-submit cookies less insecure than before. HSTS (HTTP Strict Transport Security) is a big help; with every major browser supporting HSTS and TLS performance becoming essentially a non-issue, there's less excuse than ever for not using HSTS. HSTS prevents most ways an attacker could steal or set cookies. You can also use the SameSite flag on your session cookies (with most browsers) to block most CSRF attacks; although not directly related to double-submit cookies, these techniques can be combined for additional defense in depth.

If you want to use double-submit cookies for CSRF protection, I recommend cryptographically tying the anti-CSRF token to the session token. A really simple way to do this is just to make your anti-CSRF token (sent in the request body) be an HMAC of the session token (using a secret key stored only on the server or in a hardware security module). This avoids even setting a second cookie specifically for CSRF protection, but an attacker cannot meaningfully spoof the token because changing the session cookie will break the user out of their own session. Alternatively, you can set an anti-CSRF cookie, and then have the token value be an HMAC of the cookie and some user identity data (such as a username or user ID); this means that your users will not need to update their anti-CSRF tokens every time their session token changes (which might be frequent, if using a short-lived JWT or similar) but an attacker won't be able to log in themselves, find a valid CSRF-cookie + CSRF-token combo, and plant those values in a victim's browser session (or rather, it won't work if they do, because it will be for the wrong user). Additionally, use HSTS (on all sites, including subdomains, and add it to the preload list) and, if you can, also use at least the "lax" SameSite flag. Neither of these will protect users on IE10- (or similarly old browsers), but you probably don't have many such users.


Web Service Authentication Using PBKDF2 and a Public Salt - Does the salt need to change on every request? I have implemented PBKDF2 authentication for some web services.

The client is given the following information, so they can duplicate the PBKDF2 function:

the hashing algorithm (SHA256)
a secret password that is 30 bytes long
the number of iterations (4096)
the hash length (32)

The client is expected to generate a cryptographically secure random salt and use it in the PBKDF2 function. The resulting PBKDF2 hash and a base64 encoding of the salt is then added to an X-Authorization header in every request.

e.g. X-Authorization: 882fac38qkf98ff1ed29W4bd2f95P214=&&=2c55a195

All requests are done over https://. I have always been under the impression that a new salt should be generated on every request, as this prevents rainbow table attacks... but is this really necessary?

Let's say someone breaks through the TLS layer, and so they can see the password hash and the salt that was used. They are intent on breaking this password and so they create a rainbow table using this visible salt. I doubt they are going to crack a 30 byte password, but if they do, they now have the password we sent to the client.

At this point, with the password, they can make any request they like. It doesn't matter if a new salt is used on future requests. There is no need to create another rainbow table to crack those ones, because we already have the password.

Is there something I'm overlooking or misunderstanding? Is there a benefit to generating a new salt and running the PKDF2 function on every request?

The point of using salt is to prevent brute force attacks against multiple passwords at once. If they all have different salts your dictionary or rainbow table is only valid for one specific salt.

So, indeed using different salts for the same password is not helpful.

N.B.: If somebody can break TLS connections they will probably attack something more interesting than your webapp. ;)


Which EAP connection is strong? Certificate based EAP connection or credentials based EAP connection? What difference we can observe when connecting using the certificate generated using the RADIUS and the credentials that we define in RADIUS like username & password.

Certificates are more secure.
With password submission, an opponent who succeed to impersonate the Radius identity will receive the challenge-response from the clients. He can bruteforce them to retrieve the original password which as possible as the password is strong.
With certificates, the private key can be bruteforced in a similar way. But bruteforcing an asymmetric key is not achievable as it is composed of many many more bits than a regular password.


Can password strength be enforced with PAKE protocols? Can a password strength policy i.e.:
must contain at-least 8 chars
must contain one uppercase letter
must contain one lowercase letter
must contain one number

Be enforced if a PAKE protocol is used, such as OPAQUE?
Is there any way with these protocols (eg, OPAQUE) to prove the password conforms to the above. As with PAKE the password never reaches the server, and client side checks can be easily bypassed. Does this mean with PAKE that users could use passwords with 3 or 4 characters (or lower, of course)?

I know I can check against commonly used passwords & specific passwords, such as historic user passwords, by encrypting and comparing outputs. But of course it is not feasible to check the output of every password combination up to 8 characters.

I want to check only the historic passwords & common passwords that conform to this policy.

Is there any-way on the server side to prove that the input on the client side conforms, with a protocol like OPAQUE? Given that the password is never actually seen by the server.

Does this mean the use of PAKE such as OPAQUE could potentially reduce password security?

EDIT:
I am aware that enforcing minimum character requirements (eg: one number, etc) is contested. The above policy is merely an exmaple.

No, you can't enforce a client-side policy via technical means.  As you mention, any limits you bake into an implementation could be bypassed by someone using a modified client.  But that presumes you have at least some users intent on using specially weakened clients, which seems unusual.  What reasons would your users have for avoiding your official client?

While you can't stop someone from doing an end-run around your system, you could use the policy stick to require people to use only approved clients.  You could audit their systems to make sure they have the official client installed.  You could use technical means such as code signing, application white listing, virus scanning, and/or file integrity monitoring to help ensure they don't install rogue clients.  If you find they're using an external website to do things like generate and exchange keys, add the website to your firewall's blacklist.  Make doing the wrong thing harder.

Perhaps you could require them to manage those specific passwords only from a bastion host running behind a firewall. The bastion hosts would be locked down and used only for those particular security operations, then any exchanged passwords would be copied back out to the client.  I'm not saying it's the most secure choice, only that it's potentially another way of controlling the users' behavior.  Similarly, you could provide a wrapper service in front of the PAKE system and use the wrapper to test for password conformity.  Of course, these approaches leave you with a bastion host or wrapper service that you have to secure, manage, and inspect, which could be a bigger and more expensive headache.

Sometimes all you can do is state your policy (and the scary penalties for non-compliance) and expect people to follow it.  Consider a policy-only approach until it's alleged (or proven) that users are circumventing it.


key escrow vs secure storage(software/TPM/HSM) From the definition of key escrow (a method to store important cryptographic keys providing data-at-rest protection), it sounds very similar to that of secure storage which could be basically software-based or hardware-based (TPM/HSM).
But, I could not figure out any differences or similarities between these two on the internet.
Are key-escrow and secure storage the one and the same or not? Or is it just a marketing terminology?

An escrow isn't a method, its more of an agreement. merriam webster defines the term escrow as

a deed, a bond, money, or a piece of property held in trust by a third party to be turned over to the grantee only upon fulfillment of a condition

So in the case of key escrows, you simply entrust your cryptographic keys to the key escrow provider to turn over to someone when a specific condition is fulfilled. In the case of a commercial key escrow, the condition is just that they confirm that the entity asking for the keys is authorized to access them. In case of a law enforcement key escrow, the condition would be that the LEOs have a valid warrant. Note that a key escrow by itself does not provide any protection. Protecting the keys is up to the key escrow provider.
An HSM on the other hand is a physical device that is designed to protect data (usually cryptographic keys). So, although a key escrow provider might be using an HSM to store escrowed keys, the two are fundamentally different things.


Do I need to use DNScrypt, or can I just set up DNS by myself? What's the point? So I'm not a fan of having lots of software on my PC, and I was thinking: do I actually need to use DNSCrypt or can I just type in DNS address of one of those private DNS services which do not log your actions manually in the network config (or on my router for that matter)?

Do I really need that extra program, does it add any type of extra security/privacy, or is it pointless if I am able to enter 123.456.789.012 after looking for a decent DNS provider? And if I do need it, can you explain why?

Thanks.

DNScrypt encrypts the communication between you and the DNS provider. It hides your DNS queries from anyone trying to wiretap your traffic, but it does not hide your queries from DNS provider itself. The primary benefits I see are in situations where you are on an untrusted network (e.g. public hotspot, censored connection, malicious ISP, etc.) and you suspect someone might try to tamper with DNS responses in attempts to redirect you to malicious webpages. This would provide pretty strong protection against that.

If it's privacy and not security you're looking for, then the main question is "Privacy from whom?" If it's privacy from the DNS provider you're looking for, DNScrypt won't help. If it's privacy from your ISP and other potential wiretappers, DNScrypt will protect your queries from being read or modified while traveling between you and the DNS provider.


Is using numeric passwords on Macs reasonable for average users? Is using a numeric password (similar to a PIN code on a phone) on Macs reasonable for regular users, considering they are the norm for passcodes on iOS devices?

Traditionally user accounts on Macs have been expected to use passwords which include letters, digits and other characters, to make the password harder to guess and find using brute force techniques. However, while you can use such passcodes on iOS devices too, Apple seems fine with most users using numeric passcodes on their iOS devices. So would it be reasonable for a regular user to also use a numeric password on their Mac?

To make it clear, this question concerns regular everyday users that want to make a reasonable trade-off between convenience and security — not a user that wants to maximize security.

The security requirements for passwords are independent from the operating system. It's the same for iOS as for any other operating system, because the usual attack vectors are the same.

There are best-practices available for what is considered state-of-the-art password strength. Normally, I would link to one of the standards here, but for a private user like you describe yourself, a simple guideline of 10 characters with a good mixture of letters, numbers and special characters will suffice to be on the safe side.

If you want to follow those guidelines, depends on your risk appetite. If you rather run the risk of getting compromised to avoid entering a more complex password, that's up to you. Companies may be bound to regulations and have to be compliant to certain standards. As an individual, you are free to decide how insecure you dare to be. But please, just for a minute, imagine how it would make you feel, if someone breaks into your system, gets access to all your data, monitors everything you do 24/7 or destroys all your data. Is usability still worth using a weak password? If it is, go ahead, no one is stopping you.

Having said that, limiting yourself to just numbers isn't necessarily bad, if you choose a long enough pass code. A 20 digit number is stronger than a password that uses an alphabet of 60 characters (upper and lower + some special chars) with only 10 characters. You can calculate it yourself, the number of potential passwords is simply the size of the alphabet to the power of password length.


Should I treat my SSH username like a secret? I'm trying to automate the deployment of my blog.

Most CI providers are using virtual machines/Docker containers with Linux, so I'm learning about shell scripts and SSH now, which is all new to me.

What I have

In order to deploy the finished site from the CI server to the webserver, I'm connecting via SSH like this:

rsync -rSlh --stats build/ my-ssh-user@example.com:/www/htdocs/blah/tar
ssh -o StrictHostKeyChecking=yes my-ssh-user@example.com 'bash -s' -- < deploy.sh /www/htdocs/blah/

(code copied & pasted from multiple blog posts and tutorials)

Authentication is done via a SSH public/private key pair.

My question

Apparently even though I'm authenticating with SSH keys, the user name is still needed (both lines of code above contain my-ssh-user@example.com).

Given that the code above will eventually end up in a public repository on Bitbucket (because that's where the source code of my blog is):

Security-wise, would publishing my SSH username be a problem?
I'm not sure whether I should treat it like a secret or not.

On one hand, the actual authentication is done via SSH keys, so the username is "not that important".
On the other hand, now everyone knows my username and could try to brute-force my password.

On the other hand, now everyone knows my username and could try to brute-force my password.

Assuming you don't use the same username for every last thing, what you would want to do in the case of SSH is to not allow credential-based authentication.  SSH can be configured to not accept credentials even if they are right, so that you are forced to use key-based authentication instead.

For this reason, you'd want to keep the key very very private. Your username is not nearly as important as the authentication method.

You could also add a "passphrase" to authenticate the key before the key is used to authenticate your user into the shell session, as additional security.

But, as symcbean mentioned in their comment, unless you're debugging something internally, StrictHostKeyChecking=no is a no-no.


How does ProtonMail manage search? There is a service called ProtonMail that encrypts email on the client, stores encrypted messages on their server and
sends it encrypted in some fashion (depending on what email service the recipient uses).

My question here is how do they manage to search through my data if it's encrypted when they get it?

I'm confused how they do this in a scalable fashion so it doesn't break when I have a couple of thousand emails stored.

According to their support page, it doesn't search in the body of the mail:

  At this time ProtonMail does not search the body of your email messages. This is due to the fact that they are encrypted on our servers, and therefore we currently do not have a means to search them.

Instead, it searches in these non-encrypted fields:

  Recipient email addresses
  Sender email addresses
  Subjects
  Date s message was sent/received
  Folder (Location)
  Attachments (only yes/no, not the name of the attachment)


How to encrypt all existing customer passwords I work for an online shop and since I worked here we have stored customer passwords in plaintext. I joined the company as a data inputter and when I discovered that we did this I flagged it up with management but they didn't seem interested or concerned. Several years later I am in charge of the website and I now want to encrypt all our customer's passwords.

What is the quickest and easiest way of encrypting all customer passwords on a .NET ecommerce website? Are there .NET libraries we can make use of?

Edit

I currently know next to nothing about encryption or password security. I have been accused of doing no research before posting this question. I have actually begun researching this topic today and this question is part of my research. I'm sorry if people are offended with my lack of knowledge but it isn't through laziness. I simply don't know anything about this field and I am now trying to find out. This question is part of that. I would really appreciate any help you can give me.

Passwords should be salted and hashed, not encrypted.  You should use a slow hash to mitigate precomputation attacks.  There is .NET code here: https://crackstation.net/hashing-security.htm

Edited to add:  If your number of accounts is low, you might be able to simply block login attempts while the hashing code runs.  However, it's designed to be slow, so you may have to allow logins while passwords are being hashed.  That's no problem.  Compare the plaintext password first; if there's no match, hash the offered password and compare again.

Do not forget that you have to store the salt as well as the hash.  If you're not changing your database schema, those can be concatenated and stored in the existing password field, assuming it's varchar.  Otherwise, you may have to add columns to the database and clear the plaintext column after the hash computation is complete and committed.

Check your password recovery mechanism.  When you've done this, you won't be able to tell users what their passwords are.  You'll need some other recovery mechanism.

Not relevant to the question, but if you're not using TLS for the login, you need to.


Backdoors after SQL injection? I just found an injection vulnerability on a live site of a client. It looks like this:

$sql = "SELECT * FROM users_dl WHERE Username = '" . $Uname . "' AND Password = '" .     $Pword . "'";

I successfully "hacked" it using wikipedia examples, so it ought to be pretty bad vulnerability.

The site has been like this for many years.

I know how to fix it, but since I don't know much sql, I am worried about backdoors.

Would I be still exposed after fixing this? What backdoors could there be left?

Eg could an attacker have already gained total access, like mysql user and pass and not even need injections in the future? Do I need to change user and pass? What else?

The Database gets used by multiple sites, so im pretty sure its cross domain enabled.

As @Adnan says, the worst is "Full compromise and the existence of a backdoor.". Why? While playing with SQL alon can't lead to any compromise of the system itself (just reload the datatabase from a backup and you ought to be set), the programs using SQL and interacting with the system have much higher capabilities.

For example, there's a chance that you have a table containing PHP template snippets. An attacker can edit that and add malicious code. If anything from the SQL tables is being executed (or even dumped to a file -- if the file can be dumped to the web folder, then an attacker could use it to inject and run his own PHP), then you may have a problem.

So find out where all the data in the tables is used. If, at any point, it is being saved or executed, see if this is exploitable (in the case of the former, it depends if the attacker can put arbitrary text in the web folder using it. In the case of the latter, it's almost always a problem). If so, there's a chance the system was compromised, and you may want to do a clean install.

If not, then just look for problems in the tables and fix them if present. Make sure you change your username/password (and check for rogue accounts)

An interesting thing to note is that in SQLite, the ATTACH DATABASE command can be used to directly introduce vulnerabilities.

Similarly, the SPOOL command in SQL* Plus can be used if the injection allows for multiple commands to be executed.

If you're using either of the above two, a clean install would be good regardless of how the data is being used.


Is it there any way to detect payloads generated by veil framework While pentesting, I used to generate a malicious payloads using the veil framework. The generated payload bypasses antivirus & infects the target system.

Is there any way to detect veil payloads in a victim machine? How can I secure my system from malicious payloads generated by veil?

Veil is actually not too good at creating payloads that evade AV. I've created numerous payloads and they're all detected upon upload to Virus Total.

You could try the following:

Write a script to create a hash checksum of every file on a fresh, untainted install of your OS
Run the same script on your machine (with the suspect Veil infected files)
Compare the hashes
Any hashes that don't match up, replace the files with the untainted versions

Alternatively and a more safer way to go would be to wipe your system and start from scratch.


Getting in to the security side of things Im a current student going for my Bachelors in Network Administration and would like to get in to the security side of things. I have my Network+, Security+ as well as the A+ and a MCTS.

I currently do IT support for two companies mostly supporting Exchange and iOS. What kind of skills are most sought after and required by employers? How do I get knowledge of real world scenarios and things like attack mitigation, pen testing, etc without any access to equipment, or would virtual labs be enough?

Security is a very very large field. What specific area of security are you interested about getting into?

It seems like you have a lot of experience in the administration world. You can use that as a starting point to get into security. Study up on hardening servers, networks and what have you. I know that Cisco and RedHat have security certifications about hardening their specific products. You can look into that.

If you like development work, learn about how to develop secure applications. Read up on common attacks like XSS, SQL injections and buffer overflows and try to minimize them in the code you write.

If you want to get into the offensive side of things, learn how to exploit the common vulnerabilities. There are many resources available that allows you to practice including hackthissite that allows you to hone your skills in a safe environment. Get familiar with the tools in Kali Linux/BackTrack, there are many useful ones in there. Pick up a scripting language like python or ruby, this will be immensely helpful when you need to automate task or write proof of concept exploits.

Certification wise, CISSP is the industry standard. OSCP is an excellent hands-on certification as well. I heard good things about the various SANS certificates but they are costly. Very costly.


Will I be 100% secure (anonymous) when using the "regular" web through Tor? If I use Tor to access "regular" internet sites, like Yelp, Amazon, and others to leave reviews, will I be I 100% anonymous? (Without changing my IP and MAC addresses?)

The short answer is "maybe". It depends on what you've done in the Tor browser, and what forms of anonymity you're trying to achieve.

For example, if you sign in to a site (say, to leave a review), the site won't be able to tell where you're signing in from (which it normally can deduce from your IP address), but it will certainly know who you are, at least to the level of your account details (because you just signed in with that account). If you avoid signing into anything, you will theoretically be anonymous, but if you move from one page to another, there's still always a risk of a pattern being recognized (even though the requests come from different IPs and in theory you won't be picking up tracking cookies or anything) if, for example, very few users would be likely to visit those specific pages using Tor within a narrow timeframe (Tor exit nodes - the IP addresses that servers see when you use Tor - are generally well-known, so you can hide which Tor user you are but you can't hide that you're using Tor). True anonymity is hard.

Not directly relevant to your question, I think, but you should be aware that security and anonymity are not the same thing. A breach of security (for example, due to a bug in the Tor browser, which has happened before) can lead to a breach of anonymity (for example, by fingerprinting your computer and sending that data to another server, or by sending a network request that is not routed through Tor and hence reveals your real IP address). Security breaches can also lead to other things, like logging keystrokes, accessing files on your machine, infecting other programs, sending email to all your contacts, and so on. The Tor project takes security quite seriously, but it's also a very tempting target - lots of people looking for ways to compromise it, and see what its users are up to - and there's no such thing as being "100% secure" with any piece of software as complicated as a modern web browser.