@maaartinus depends if any related input attacks are ever determined

as long as there aren't any related input weaknesses then you should be ok, but using cryptographically secure random numbers as the salts will prevent related plain text attacks from becoming an issue

@maaartinus in theory if it can work against a single pass, it could be potentially extended to multiple passes, each pass is still deterministic

probably a bit less likely, but still an avoidable risk

@maaartinus client side hashing can never replace any cycles of server side hashing. An attacker will just attack the client hashed input rather than the actual password

@maaartinus this is the one arguably valid reason for client side hashing, but you are assuming that the client side hashing isn't more likely to lead to a compromise of the password than server side handling

and all it is protecting against is password reuse which is a bad practice on the user's part that is not going to be protected as well on literally any other site out there

but in general, client side hacks are far FAR more common and likely than server side, particularly if you've been careful about your security

but any number of factors could compromise the client

@AJHenderson Are you sure? If the attacker wants to try passw0rd!, they have to re-do the client's work. If they want to try XkK1aZSRjhPMDJjrHxcGQQ==, they surely don't, but....

@AJHenderson I forgot to mention that I care about JS-based single page applications only. So if someone hacks it, then it's hacked and the attacker can steal the credentials and the PW and everything. And PW hashing doesn't matter anymore.

@AJHenderson Generating and storing secure random numbers as the salts for every username... I see, but this means more overhead and I doubt that it's justified. The related input attack will probably work against a single hash function, but why shouldn't I run different hash functions when I have to iterate hashing a lot of times anyway? Or does the security decrease by combining them???

Actually, the advantage of the secure salt only comes to play, when 1. the DB gets stolen AND 2. an unimaginable major cryptographic breakthrough happens. These are two improbable conditions rather than only one, so I guess, the advantage is not worth much effort.

@maaartinus that's some protection I suppose, but I'd still highly recommend doing enough iterations on the server to avoid any possible issue and you still have to worry about the loss of client side protections that the password field offers

@maaartinus that's the standard practice for a reason. It's almost no additional storage in the scope of any system and offers greatly improved security

almost any system has far more data in other portions of a user's record, having a couple of bytes of random number that stays the same unless they change their password is hardly a large overhead

@maaartinus I wouldn't expect it to decrease the security, but then you are adding computation cost and would still have the same weakness on any iterations of the particular hash. The chances of a catastrophic issue are pretty low anyway, any attack being discovered would most probably be an entropy reduction kind of thing that just lowers the effort required to solve a hash.

@maaartinus the first isn't really that unlikely, but the second is the only one that's really a factor. You say it isn't likely, but computation speed increases rapidly and there have been numerous effort reduction issues found in many hashes, that's why we have the arms race we do to improve hashing algorithms

something truly random costs you a small prng call whenever a user changes a password and a couple bytes of storage per user

it's basically no cost, plus there are standard libraries that will do it for you in many languages

rolling your own is a good way to get in to trouble

@AJHenderson I don't mind storing a few bytes per existing user and doing some PRNG when they log in. But I'd have to store the salt even for potential users, i.e., for everyone entering their email. OK, I could expire them...

@AJHenderson I guess, you're not speaking about <input type="password" ...> (which has zero protection from JS), but rather about fields used for HTTP Authentication. I haven't seen anyone using it for ages. Everybody seems to send login data as JSON.

@maaartinus why would you be calculating it for every e-mail? You don't need a salt until you have a password

in fact, often the salt is just stored as a formatted part of the password field

@maaartinus oh, you are right. I don't normally do front end stuff I thought that was protected, but it isn't, so I rescind that part of what I was saying. Sorry about the error

I'm a backend framework/db guy. I let other people handle UI, particularly web UI as I can't stand javascript or the DOM in general

@maaartinus you also don't have to prng when they log in

only when they change passwords

o/ Hola folks.

@AJHenderson We're speaking about client-site hashing. But I see, the server generates a salt, sends it to the client and forgets about the story. When the client sends the hash PW, the salt is included. I see that there's no problem there.

@maaartinus oh true, for client side hashing the salt would be tricky as you'd need to know the user first

might be worth using something standardized from client input there since it's not a "real" security thing anyway, but I'd be sure to still use a crng salt on the server side

client side hash will always need the same salt to be used since it will have to match the midpoint of the user's "real" password (ie, the hash of the password they enter)

so your choice are either get the username first and send the salt back or do something where the client can determine it from the username

neither is particularly super, but I wouldn't count on either mechanism for the final security of your hashes either, so it doesn't really matter

@AJHenderson I see. I don't like JS either, but I do both client and server.

@maaartinus I'm lucky enough to work someplace where we have other people who have to deal with that stuff :)

@AJHenderson Yes, that was the reason why I proposed just the username plus some fixed string as the salt. This makes things simpler and there will be another hashing with another salt (this time really random) on the server, anyway.

I'm a framework dev/architect

@maaartinus yeah, I don't see any problem there. I'm somewhat dubious of the benefits vs the cost, but it's something and as long as you do your normal protection based around the result of the hash being the "password" and follow best practices for the server side, I can't see it hurting anything

@AJHenderson I'm unlucky enough to work mostly alone. Or lucky, it depends...

@maaartinus yeah, I hear you on that. The job I'm at now is pretty solid though. I more or less make up my own work

for the most part

of course, when the task that needs to be done sucks, I only have myself to blame

and the company I work with is solid, it's a major SAAS provider of PSA software for IT firms so we tend to have pretty good developers for the most part

Currently, I'm using scrypt(1<<14, 32, 1) on the server side, which seems to be an overkill as it takes 200 ms. It's a startup project with a currently 900 users who rarely log out. There's no expiration as we don't need much security (no really sensitive data and the problems an attacker could cause by misusing an account are just as big as they could cause without it :D).

I'm more worried about how trivial it is to DOS the server by fake logins. There are other ways, too, but fake logins are good enough to let a fast typist with one browser window take the server half down. :D

There's currently no throttling, just a user lockout after three failures (with an email recovery). Funny thing to be fixed some day.

@maaartinus yeah, that's your real fix there. Prevent spam creation of profiles and don't do the expensive stuff if you don't have a valid user being requested that isn't locked out

We had no spam-like problem or anything like that yet. It isn't a site for broad public and it's hardly known yet. Our users are actually customers of our customers (who are suppliers for our users :D).

I'm thinking about a login throttling scheme... something using both the IP (which is problematic) and the username (which is problematic for a different reason).

Maybe even the password... I've never heard about throttling by password, but it sounds like a good idea when protecting against dictionary attacks.

@maaartinus that's not a good idea

you'd have to keep track of passwords people attempt

Doesn't work. Its easy to avoid.

which would be a major security issue as people may typo minor mistakes to real passwords

and you couldn't effectively hash if you wanted to be able to detect the same password being used across multiple accounts

To explain: When (username, password) = (alice, 123) fails and some other conditions are met (so we can assume, someone is cracking), then (bob, 123) gets throttled.

You throttle ont IP/regional subnet (spammers use subnets) and independently on accounts.

@maaartinus right, but that means you are storing that alice tried 123 in a way that bob could also tell

You don't want plaintext access to a password, only a hash of the password.

and if alice's password is 124 that's bad

@AJHenderson I can, as this won't be persistent. I guess, keeping the plaintext PW in memory should be OK.

Actually, not even the plaintext PW, but a cheap hash of it.

@maaartinus but what do you gain from it. It's a compromise to your security model for no real gain

you can tell that an attack is going on if a ton of users start locking out

you don't need to know they are trying the same passwords over and over

It helps when someone tries the simplest PWs with everyone's account, doesn't it?

and ideally you shouldn't be confirming if people's accounts exist

I know. I'm not gonna confirm it.

if they have an offline list of users, they probably have the hashed passwords and can check for simple passwords offline

ultimately all you need to know is that there is someone carrying out an attack, you don't need to know the specific type really (or could even deploy additional logging in the event of an on-going attack to determine it without compromising your normal security model)

Or ratchet up delay times or lockout tries when an attack is ongoing.

yeah, that too

Our users are a specific group and there may be other ways to get a list of their usernames (=emails) than stealing our DB. Moreover, there's a place in our application allowing a logged-in user to find out if a given username exists. This is necessary for a given functionality, but there should be some throttling there, too.

Adjustable delays make little difference to individual users doing something a few times, but to an attacker doing it thousands or tens of thousands of times it adds up.

@this.josh Yes, but WHO do you want to delay? Those having the same IP? Those trying the same username? Both?

I'd still highly recommend against trying to determine if someone is using the same password on multiple accounts. It's increasing your attack surface area significantly with minimal advantage

IP address or IP subnet, use geolocation to find hotspots of IP sources

@this.josh I know. It was just yesterday when I read everything I could find about it.

well I need to head to bed, but was nice chatting

When an unusual amount of traffic from a region of the world you usually se little of, thats a good indicator.

@AJHenderson It was nice to chat with you.... I really should go to bed, too.

I was using UUIDs as Session IDs until I did some research on UUID.

@this.josh Yes. What do you think about giving regular users a "white cookie" which gives them some advantage when throttling? I mean something like smaller throttling delays. When they fail a few attempts, then the cookie gets invalidated.

@ATaco ???

For a website, my Session ID for connected clients was a stock standard UUID, UUID v4, although has a low chance of collision, is highly predictable, with very low entropy.

@maaartinus Your site allows your users very long sessions?

Otherwise you would need to login to establish a new session. Then the cookie wouldn't be much use.

Some sites use fingerprinting and require additional authentication when the fingerprint doesn't match, but then you need additional barriers to use as a penalty for a changing fingerprint.

@this.josh Yes. It's a usability feature, bad for security, but we have nothing really sensitive.

@this.josh Anyway, I meant a non-session cookie, which you get when you successfully log in, but which is otherwise unused... and not cleared on logout.

@maaartinus And the impact would be that users with white non-session cookies arn't subject to login delay?

There's the question of how easy they are to forge or guess, but as long as you could apply the impact selectively, and it has no impact on authentication itself, it might be of some benefit.

Attackers will look for hidden or disregarded value in features and often find the value that you didn't know was there.

Or combinations of features that you havn't considered or tested.

No, everyone gets delays, but the users with the cookie get some small advantage. For example, a shorter delay. When under attack, there may be no chance to process all login attempts, so such users would get preference.

Yes, the process itself won't get changed. It just that the probability of someone with such a cookie being a legitimate user is higher.

Probably the bigest misconception is that your site isn't valuable or interesting to potential attackers. This thinking is confusing the physical world with the network world. On a world-wide always-available network (the internet), anyone with a device on that network might be interested in your site merely because it is on the network.

OK, but I'm speaking about application level attacks. Having an account on our site gives you nothing, unless you belong to our target audience. To be able to misuse out network, you'd need to hack in on the system level.

Its quite difficult to give an HTTP/S request priority in processing unless you are implementing processing queues directly. It seems like you are trying to sovle the DDoS problem by selectively allocating bandwith through request priority.

Having a valid account gives you access to resources on your site. Resources have value. Attackers are attempting to take value from you without compensation. Even valid users may try to abuse your system.

I haven't meant the packet priority or alike. If someone mildly powerful wants to DDos us, then we're toasted. Or we need a different solution. I'm concerned here about login only. Someone wants to online crack PW or DDos us (with few resources) and this can be done rather easily because of the slow PW verification. At the servlet level, when there are 100 incoming login requests in the queue, I can chose which ones I want to process first/last/drop.

Thats what I thought, you bump priority for white cookies. You will still need some kind of expiration on the cookie even though it's not tied to a session. It would also be good to make it tied to a specific user, maybe even a user on a specific device.

Just make sure your white cookie priority won't cause non-white cookie starvation.

Agreed. Binding to a user is a sure thing as two users improbably share a browser. Binding to a device should also work but would require fingerprinting which may be just too much work for the limited gain.

Binding to a device is usually more painful than it's worth.

Concerning starvation, I expect that the vast majority of legitimate user will have the cookie, so reserving 10% for the others should do.

Don't you know Security Types love pain?

Or less. There won't be many legitimate users logging in at the same time (they usually stay logged in all the time).

???

You don't mean safe BDSM, do you? :D

Why else would we spend uncountable hours evaluating solutions only to have our recomendations sidelined?

What's your safe word, mine's "2324332a151c7dc5a4cbd802bd8ed7f6"

My safe word is the lnverse log of my ECDSA key

If anyone went to go full crypto nut on that key, it's literally just 16 random bytes.

@this.josh plus, if you are successful you will end up kicking your own butt for early bad decisions you end up having to try to retrofit later once you have a bigger target on your back

Do you have a link to a free TSL-stripping proxy that I can use to log all traffic sent to/from my phone and to/from the computer the proxy is running on? I'm trying to get a trace of a network-related bug in a desktop/android app so I can file a proper bug report. I don't know how to reproduce it, but it happens daily so I want it fixed badly.

@JeremyBanks: thx, I completed the form!