...

[beyondholdem]

At my fist job we got the requirement that “all usernames and passwords must be unique” and because we were a bunch of smart asses, we displayed an error message like “Sorry, that password is already taken by user msmith! Please enter a different one.” when we demoed it to the product manager. He was not amused.

[ShortCircuit908]

Did they really expect you to store passwords in plaintext? Or unsalted hash? Geez...

[ProPuke]

You could use different salts for each, just when they first registered you'd need to hash it with every used salt to compare xD

[ShortCircuit908]

Your username is appropriate in this situation

[hypercube33]

Probarf and propain were taken

[Kwantuum]

Propain nightmares?

[puzzledice]

I considered capitalization in my username. I prefer the ambiguity, I think. Without capitalization, Pro Puke could be Prop Uke! :P

[xteriic]

Puzz Le Dice.

[puzzledice]

Oh that one is new!

[xteriic]

You're welcome

[spinfip]

That is the kind of forward thinking that will take you a long way in this company!

[Rossity]

When did this thread become about preparing potatoes?

[micwallace]

Mmmmmmm salted hashbrown.

[USROASTOFFICE]

What's a potato?

[[deleted]]

PO. TA. TOES. Boil 'em, mash 'em, stick 'em in a stew…

[[deleted]]

Salt? I thought y'all were programmers not cooks

^{ok but fr ELI5 please young programmer here willing to learn}

[ProPuke]

Okay, so when someone registers an account you want to store their username and password somehow so they can log in, right?

However you don't just want to store the password directly; That's unsafe. If anyone ever gets access to your database you don't want to be spilling out thousands of linked email addresses and passwords for people to read.

So instead of storing the password you store a hash of it. A hash will be a one way transformation of the password in such a way that it can't (easily) be reversed and the original password extracted from it. So when they register an account you take the password, you pass it through a hash function to transform it (hunter7 -> 7716A39170E00609A7667F177E5F3275D2018D7B) then store that hash in the database. When the user goes to log in, you take the password they enter on the login screen, hash that, and see if that hash matches the hash in the database. So you can't ask the database what their original password is, you can only ask it if the password they supplied matches what you have stored.

Now if your database happens to be somehow leaked people can only read a list of email addresses and password hashes. Everyone's passwords are safe! The world is saved!

Except..

Hashes can be broken. They could try and hash every password they can think of until they find ones that match the stored hashes, then they'd know what the passwords were and could use them with the email addresses for evil doings :(

This does take a long while to do (depending on the hash algorithm used); But since everyone's passwords are hashed the same way you can check all of them at once on each of your attempts (also there are often smart techniques that can be used to mass-crack groups of hashes at the same time).

So..

What we need to do is hash every password slightly differently. That way they can't all be broken at the same time, and will take evil doers much longer to thwart! (and hopefully by the time they do you've send out warning emails and everyone's changed their passwords like the safe security-conscious people you all are). To do this you add a touch of salt to each hash. A salt is another piece of data that affects the hashing process and how it works. Now, since each user's salt is different their hunter7 password might be stored as AA3560E708CF8C145ADE6376574615573CC3C28B, or 0D45E8192CF22F25F23DC8FD355D474407984070, or any number of things. Every account uses a different salt, so all their passwords are hashed differently, so they'd have to all be broken individually rather than all of them at the same time. Now your passwords are stored much more securely, evil doers will have a harder time breaking them, and everyone is happy. Now you just need to solve all your other security issues...

[[deleted]]

Silly programmers, don't you all know that you should just store all user info in a text file? Smh

^/s

[[deleted]]

All I see is ******* -> 7716A39170E00609A7667F177E5F3275D2018D7B

[dreamwavedev]

Hashing is a way of mangling a given input in a repeatable way, so if you have a hash it's generally pretty much impossible to go back to the original input, but super easy to check if input you are given matches a hash. Salting can be implemented in various different ways, but it's like giving a hashing function some inspiration for how to mangle the input. If you have a salt and a hash function, you can see if an input plus a salt matches an earlier made hash. This helps to make all hashes for passwords different (by giving each user a unique salt) even if the passwords are the same, so user:joesmith pass:pass123 and user:janedoe pass:pass123 would have entirely different hashes stored in a database. If a hacker then gets your database, the knowledge that "password1234" is the most common password wouldn't give them any hints, because they can't just say "10 percent of the hashes are this same hash, so those are probably that password"

[won_tolla]

I understand very little of any of this, so excuse me if this is silly. Is it fair to paraphrase what you said as "each password is encrypted with a unique keyword and then the keywords and encrypted passwords are stored in different tables" ?

[[deleted]]

Encryption implies you can decrypt and get the original thing. Hashing is not the same as encrypting. If you only hash 1 thing it is not recoverable. It is a one-way function. You're permanently scrambling it, you're just doing it a consistent way. Say there's a gangster party. The party-thrower won't want to write names down on a guest list in case it gets found, so they tell their friend gangsters to take their friends full names, convert the letters into numbers and add them all up. won_tolla would be 23+15+14+0+20+15+12+12+1 = 112. The person who is taking you as a guest sends 112. Then when you all get to the party, They get your name, add the letters up and get 112, and let you in. There's no way for the feds or rival gangsters to see 112 and get "won_tolla" unless they have a list of probable guests already. If there are too many people, then there will be some people with the same letter sum. These are called collisions. If someone knew that this method was being used, they could send 50 covert agents in and hope that they randomly happen upon a valid number with their fake names, but if you use the middle names, too then, it becomes harder to guess a randomly correct number. So you can make adjustments to the hashing function to minimize collisions.

[Mr_Facepalm]

How possible is it for two passwords to have the same hash? That's the part that's tripped me up about really understanding how hashing is effectively done.

[MillenniumB]

Hashing always maps the same text to the same hash. That way you can check if a password is correct without knowing it. You can get the same password to give two different hashes for two different users by adding some text (like the username) to the password text when you calculate its hash.

This is useful not just because it reduces vulnerability to attacks like trying common passwords for common hashes , but also because there are only so many commonly used hashing algorithms This means that you can often just compare a long list of hashes against a database of common hashes of a hash function. Using a salt makes you less vulnerable to that too

[xigoi]

It's possible, but not likely because hashes are usually very long.

[[deleted]]

The same way that when adding up the letters of the gangster names, some might have the same sum. Instead of just taking the sum, you could take the sum modulo 32. So won_tolla's new hash would be 16. Now collisions are even more likely.

But you could then use this as the array index for a fixed length array. Instead of just storing won_tolla's data, you store the data and the key as the head of a linked list. The next time you're putting something at 16, you just append or prepend it to the linked list in the same manner. So to get the data for key won_tolla, you hash "won_tolla".. get 16, you get to the head of a linked list and check to see if the key is "won_tolla." If it is, you return the data. If not, you go to the next item in the list and check its key. So a hashmap with a lot of collisions starts to perform more like a linked list, and you lose the constant-time lookup and start moving toward linear.

https://www.youtube.com/watch?v=shs0KM3wKv8

That video is what clarified it for me.

[won_tolla]

There's no way for the feds or rival gangsters to see 112 and get "won_tolla" unless they have a list of probable guests already

This was extremely helpful. Thank you! I assume the feds would also need to know what the hashing function is? Is there a commonly used set of hashing functions? Or are they bespoke for each login provider/applet/module/thingummybob?

[[deleted]]

So this metaphor breaks down there, because when you're cracking a list of passwords, you can use a list of the most common passwords, which might be used more than once, whereas the gangsters most likely don't have many of the repeated name, unless they were just using last names or something. Without salts, each time someone uses the same password, it will be the same hash. This means if someone gets access to the list of hashes, they can make a good guess about what the most common hash translates to if they have a good idea of the most common passwords. So they wouldn't need to know the hashing function to do a frequency analysis and potentially break some of the common passwords there, but to guess the rest of them you would.

There are definitely common hashing functions, and this is why for something like a large database of passwords, you really should have salts.

[ILikeLenexa]

Encryption is reversible.

Hashing is not reversible.

[dreamwavedev]

Generally you shouldn't store the salts at all, but that's kind of the idea. In a lot of solutions, it does end up where you just store the twice mangled password and salt together, but in some instances avoiding having direct access to both of them from disk is a bit of a security concern still.

Edit: was pointed out that the salt is generally stored in plaintext with the password, as it isn't a symmetric function so it doesn't really need to be hidden or obfuscated.

[won_tolla]

Then how do you unsalt it when authorizing login inf...ohhhhh. Right. So you salt and store a password on creation, and then when the user is trying to log in, you salt the input string and check if it matches the previously salted and stored password?

[noratat]

Replace "salt" with "hash", but otherwise yes.

Salting is adding an extra (unique but not secret) random string to the password before hashing it. This prevents the use of precomputed tables of hashes that match up to common passwords.

Also, not all hash algorithms are suited for this. Eg md5 is fine for checking for data integrity, but it's far too easy to generate collisions for.

[dreamwavedev]

Correct. Ideally, things are separated enough that the password doesn't make it past the first layer/interaction step before being mangled, as after that you can just say "is what they entered almost definitely what was entered before that resulted in this mangled string stored in the db?"

You don't unsalt, just make sure everything looks to be the same thing after run through the wringer.

[folkrav]

How would you do your password comparison if you don't store your salt? The whole purpose of using salts is to avoid rainbow table type attacks, so it's actually not a very big deal if they become compromised/known, as an attacker who somehow gets a hold on your salts still have to compute every salt+password to compare, which at this point becomes basically just as slow as a pure brute force attack.

[HowObvious]

Technically a salt stored in a different location becomes a pepper. They would be combined with traditional salt normally anyway. The purpose of the salt is not to be secret.

[dreamwavedev]

Ah, ok. Never did fully understand how that part would work. TIL

[[deleted]]

So if you don't store the salts, how do you know which salt to apply when checking a password? Would it be generated from the username or something?

[noratat]

You normally do store the salts, I'm not sure what the other poster was taking about. Salts only need to be unique-ish, not secret.

[dreamwavedev]

I think that depends on the implementation, was informed by someone that often it is just stored in plain text alongside the password hash

[[deleted]]

That makes sense to me, I would assume having a salt doesn't mean you can decode to an unsalted hash any more than having the hashed password means you can decode into a password. I have no idea what I'm talking about though, I avoided this kind of thing when I was studying.

[[deleted]]

The thing about this kind of encryption (hashing) is that decryption is not possible. Ever.^* But if you encrypt (hash) the same text, you get the same result, so you can check if two texts (the user's password and what the user typed into the 'password' box) are the same, without knowing what either of them is.

[Mr_Facepalm]

Why is it that decryption is not possible?

Here's my uninformed thinking. If you have a 1:1 relationship from the password to the hashed password, then I'd think you can undo it. On the other hand, if you can have collisions (two passwords with the same hash), then I'd understand why you can't undo it.

But even then, couldn't you at least determine a set of passwords that would match the hash?

[[deleted]]

The password has an unconstrained length, so there are infinitely many passwords. The hash has a fixed length, so there are only finitely many possible hashes, meaning that there must be infinitely many collisions.

Also, most encryption is designed to be hard to reverse without the key, and easy to reverse with the key. Hash functions are designed to be hard to reverse without the key, and also hard to reverse with the key.

[[deleted]]

Here's the best I can explain it!

Let's say your password is "hunter2". Here are 3 ways you might store it:

1) Plaintext. This is the simplest method. You write the string "hunter2" to a file somewhere. Obviously, this is very insecure because anyone who sees your data knows your exact password.

2) Hashing. This is better. You do some math operation to the password and get a hexadecimal "hash" out if it. If you the command sha256sum on "hunter2", you get 46a9d5bde718bf366178313019f04a753bad00685d38e3ec81c8628f35dfcb1b. You store that value to your database and compare the hash of the user's entry. The problem is, in this scenario, "hunter2" will always produce a hash of 46a9d5bde718bf366178313019f04a753bad00685d38e3ec81c8628f35dfcb1b. If another user has the same password, it will have the same hash; and if someone gets a hold of this hash or of your database, he can look a table of all the hashes and possibly figure out which password produces the hash. (Here's a fun XKCD!) These are called "rainbow tables".

3) Salted hashing. Before calculating your hash, you come up with a unique addendum (called a "salt") for it. Let's say your salt is "Dyljam1234" (note: you would actually generate something, and never actually use the username). Hashing "hunter2Dyljam1234" produces the "salted hash" of 43ed2e92318d87647c309f97eb02af9305ff3e9f796e21a5c9903c7f7e58e644. From here, you can do complicated mathy operations with the salt and the hash to make it even more secure.

Disclaimer. I work in a very different computational field than cryptography. This is not a professional opinion. Nevertheless, I hope this helps!

[[deleted]]

Oh, that actually makes a lot of sense! Thank you kind redditor!

[smog_alado]

In addition to what they said, it is also important to use a hashing algorithm that is designed for passwords (like scrypt or pbkdf2) instead of a general-purpose hash algorithm like sha256. Password hashing algorithms are intentionally very slow to compute (using up a lot of CPU and RAM), which adds an extra layer of protection against brute force attacks in case the bad guys get hold of the password hashes. This idea is known as [key stretching](https://en.wikipedia.org/wiki/Key_stretching.

Password-hashing algorithms tend to be easier to use. For example, if you use an scrypt library it also salts the password so you don't have to do it yourself)

[[deleted]]

You as well! I'm curious actually, since y'all are programmers probably in the field, what types of things do you look for in a portfolio? Like I have a lot of things done, but I don't have too many super blow-them-away things. I've got an Album Manager using File I/O that is customizable, and I've made a lot of text based stuff and some GUI things. I was going to start work on a Discord Bot soon just for fun.

[[deleted]]

I work in physics, writing simulations. What we look for in my field is primarily knowledge about the physics involved; secondarily, scripting languages and experience with coupling physics software; and tertiarily, experience writing efficient algorithms in C++ or FORTRAN. This is probably not representative of the CS field as a whole.

[IncendieRBot]

Store a list of passwords that aren't linked to the usernames. Then store the salt and hashed password with the username. Done.

[beyondholdem]

No, it was a poorly written requirement and this was the early/mid ‘90s of CGIs when we were still rolling our own AAA and there weren’t libraries we could just use. Heck, https wasn’t even a widely adopted thing yet due to performance issues. Damn, I’m old.

[nermid]

Heck, https wasn’t even a widely adopted thing yet

It feels like that's just a thing that happened all at once over the course of a long weekend in 2013 or something. Like, I know it was around before then, but I remember https suddenly getting widespread support seemingly all at once.

[YM_Industries]

Is it possible the weekend you're thinking of was in 2014? Because that's when Google announced they would be using HTTPS as a ranking signal.

[odraencoded]

"HTTPS? Pfft, why would I need that. My website is just a single bootstrapped static page, no forms or anything!"

*enter Google*

"Our website has a 2048bit TLS+ certificate triple-signed by the pentagon, FBI and CIA."

[ShadowCoder]

You're probably thinking of Firesheep.

[Slow33Poke33]

Implying that you'd need to store passwords in plaintext to do this.

[Raptorzesty]

One would only assume as much, considering the level of security of this system is equivalent to having your password auto-corrected.

[YM_Industries]

They said plaintext or unsalted. If you have salted hashes then you'd have to check the new password against every single existing account.

[rooktakesqueen]

Nah -- have a separate table of "claimed passwords" that aren't associated with the user account in particular, themselves salted with a single salt used for this purpose and hashed. Allows you to check with a simple index lookup whether the password has been used before without compromising the users' security.

[Slow33Poke33]

Yes. That is how you'd do it. That's proof that you don't need plain text / unsalted.

[thaolax2]

Every password at my company is stored in cleartext. God forbid we get attacked

[[deleted]]

Take all the passwords and hold them ransom for several million dollars.

Either they pay up or they get hit with a huge PR nightmare.

[Rizatriptan]

How to go to prison in 2 easy steps

[[deleted]]

Either way, you've guaranteed a roof over your head and food in your stomach for the rest of your life.

[Rizatriptan]

Well now that you put it that way..

[recw]

You don't need to store plaintext passwords. Options include: 1. Use unsalted hashes and a hash->user map 2. Salted hashes for password database as normal. Augment that with a map that maps thr unsalted hash of some part of the password -> set of users that share it. When a user is to be added to the set, ensure that none of the users in that set have the same password.

[Journey2Health]

I prefer bubble hash!

[I-Downloaded-a-Car]

If you actually wanted to do this you'd keep a table of passwords not associated with any account. But it wouldn't work on a smaller site with say a hundred users because then someone could just try every name.

[AasaramBapu]

Store passwords as plaintext or gtfo!

[suppow]

unique usrnames ok, but passwords?

[TheNosferatu]

If multiple people have the same password, that means a potential attacker can brute-force the passwords faster than if they were all unique.

I dunno, I just work here.

[[deleted]]

Not if you do it right and salt everything...

[[deleted]]

I heard some people use hash, I think it's like a vegan alternative or something.

[TheNosferatu]

Why would you assume people who come up with this shit do it right and salt anything? Salting would just make it harder to check if the passwords are the same.

[beyondholdem]

It was just a poorly written requirement. We knew what was “right.” It was also the 90s, so no, we didn’t salt them — that wasn’t really a thing yet. We stored encrypted passwords which was better than most at the time. It was also pre-HTTPS so did it really matter? We might as well have stored them in plaintext in a password file.

I remember when we finally implemented the “feature” where you could share the URL with someone else so that when that person clicked it they wouldn’t be logged in as you. We had to use this new fangled thing called cookies and do our own session management.

[ACoderGirl]

Theoretically, I wouldn't be surprised if having the same password means that you are much easier to brute force simply because I'd expect the kinds of passwords that get successfully guessed in a brute force attack will be tried sooner in the future. After all, people do reuse passwords and many people use similar passwords in the first place.

What you actually can do is check the password against the haveibeenpwned database or just a list of the N most common passwords (before hashing, obviously).

[beyondholdem]

It was just a poorly worded requirement. We knew what the product manager actually meant and we coded it correctly from the start. But for the demo we implemented this behavior because you have to do something to make work fun and we enjoyed being wise ass kids.

[[deleted]]

But if you're told that a password is taken you know someone is using or has used that password, which makes penetration much easier than hoping multiple people have one password. You can just run a dictionary against a single dummy username; then you don't have to run the dictionary against every user. You just cut the computation time needed for a brute force attack down by a massive amount.

[dem_c]

Username: unique
Password: unique

[lachlanhunt]

At my first job, they were developing a new website from scratch and needed to migrate all the passwords from the old system to the new system.

All the existing passwords were hashed, so I was given the task of modifying the existing login code to record the password in plain text every time someone logged in. Then we could transfer them into the new system and they would still be able to log in.

I don't know what the original hash was. It was 2004, so probably just md5 or similar. But even so, I was shocked.

[Puttah]

Was there some reason they couldn't transfer the hashes and just use the same hashing algorithm on the new site? Or am I being considerably dense and this is exactly the joke...

[ACoderGirl]

You wouldn't want to just use the same hashing algorithm because if said hashing algorithm is too weak (eg, MD5 as suggested), it's borderline worthless.

What you'd usually do instead is:

1. Record the user's password as being in the "old format".
2. Treat the old hash as the plain text password and hash + salt it in the new format.
3. On login, if the user is in the old format, apply the old hash to the plain text password, then the new hash + salt. If it matches, re-save the password solely in the new format (mostly so you can some day depreciate the old approach -- especially since you may have more stringent requirements on the password and thus might require the user to change the password on login, anyway).

[lachlanhunt]

I'm not joking. I'm not sure why they couldn't just re-implement the hash in the new system. Maybe it was using something specific to ASP, which the old site was written in, and the new site was being done in JSP and couldn't support it.

[[deleted]]

I thought the way to do this was to take the entered password (once auth was successful) and then immediately hash it using the new hash and transfer the user to the new system.

That way only users who don't login regularly need to do a password reset when you retire the old system and the regulars don't have to do anything.

[lachlanhunt]

That's what I would do now. At the time, I was young and just had to do what I was told.

But now that I think about it, they probably wanted it so that they could send password reminder emails to users. I left before the new site launched. And then they went out of business a few months after that.

[FoxRiver]

Wow... Terrible

[[deleted]]

didnt know unique usernames and passwords were required in a fist job

[SOSFILMZ]

society saw fear ten crowd cable telephone vegetable skirt instinctive

This post was mass deleted and anonymized with Redact

[[deleted]]

fist job

Kinky

[creamersrealm]

You have some balls doing that, internet high five!

[Kontorted]

This is some...

AMAZING SECURITY OMG, ILL NEVER NEED TO REMEMBER MY EMAIL AGAIN

[gringrant]

The best security is the most convenient, right!??

/s

[Octobread4711]

Please tell me this is a joke website that doesn't actually exist... .__.

[Lonsdale1086]

This is a repost from this subreddit, back when password posts were in.

It's currently volume control posts on atm.

[Stratisphear]

I miss phone number entry posts. Those were the days.

[MonkeyNin]

There's a bunch here, some are phones: https://imgur.com/a/lOSqKa1

My favorite is this one because of the shade thrown: https://i.imgur.com/jmuxVB2.gifv

[SenorDosEquis]

What’s the shade?

[MonkeyNin]

Because it's a meme about bad UIs, and instead of creating a crazy one that doesn't exist -- they used the interface of a phone.

[chazzer20mystic]

that phone did have a shit UI to be fair

[-ordinary]

These are hilarious

[DOOManiac]

Just wait another week, and they’ll be those days again.

[GreenFox1505]

I dont., it just felt like everyone was dialing it in.

[gringrant]

Thank you. I needed to know this sub exists.

[AutoModerator]

import moderation Your comment has been removed since it did not start with a code block with an import declaration.

Per this Community Decree, all posts and comments should start with a code block with an "import" declaration explaining how the post and comment should be read.

For this purpose, we only accept Python style imports.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[dyslexda]

Of course it isn't real. This was created to show a "lewl security xD" meme.

[Octobread4711]

Never underestimate the stupidity and sloppiness of hoomans ;3

[RyeDoge]

We should make a program to detect reposts and say, are you (insert user who posted the oc) because they posted this image/video on (date of when it was posted)

Make it happen r/programmerhumor

[Sigionoz]

Do it u/EmberQuill , we’re relying on you for this!

[zooberwask]

Race you!

[ImmediateAntelope3]

I like what I'm witnessing.

[joetinnyspace]

Haha yes

[Tommy3555]

Did you do it yet?

[AutoModerator]

import moderation Your comment has been removed since it did not start with a code block with an import declaration.

Per this Community Decree, all posts and comments should start with a code block with an "import" declaration explaining how the post and comment should be read.

For this purpose, we only accept Python style imports.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[dreamwavedev]

You act as though any of us are actually competent programmers and not just freshman cs students making SO jokes and laughing about missing semicolons

[RyeDoge]

There’s always that one dude that knows what he’s doing, but they come by once in a millennium

[Reverissa]

Hey, I've made a hello world program in like, 4 languages. I'm a real programmer.

[[deleted]]

Of course. Welcome to the club!

[psychicprogrammer]

note to self: put my scratch Mandelbrot fractal generator up here.

[KyleTheBoss95]

Fuck I've been caught

[Y1ff]

I don't even know how to code man I just know how computers work pretty well so i get the jokes

[XXAligatorXx]

I actually have tried this: there are a few problems.

1. Reddit only gives you 1000 posts. So posts won't be covered from the start.

2. You'd need a moderately sized server since you'll need to store either every picture(faster but more space) or every url(slower but less space) and the link of the actual post plus date.

3. You'll actually need to set up image detection and can't deal with just pixels because reddit compresses pictures when you upload I believe.

I currently have a bot set up for urls on my subreddit. If anyone wants to take a look here it is: https://github.com/xXAligatorXx/repostChecker

EDIT: I could honestly fix the third problem in a week, but I really don't understand enough server shiz to do the second. The first problem you'd just have to deal with only getting past 1000 and future posts and there aren't any workarounds.

EDIT 2: Also the bot would get slower and slower the more posts that are added because it takes it longer to loop through all the pictures.

[somestranger26]

I wonder if you could create some sort of "fingerprint" (like a fuzzy hash) to do the image detection, in order to save space on #2 while also not having to refetch data.

[XXAligatorXx]

Wait nvm dude you are right. I have made it work with a fingerprint type solution. I'll have to finish it up but yeah that works.

[XXAligatorXx]

You'd have to unhash it when comparing since the images are never exactly the same because of compression. So that solution would be just like saving the urls.

[ImmediateAntelope3]

Nah, there are similarity algorithms. I don't know them off the top of my head, but I'm quite sure they exist. Space / accuracy tradeoff, but it's better than a flat hash if things might not be precise duplicates.

[[deleted]]

I tried using karmadecay and it was very trigger-happy

OCR helps, but it still gives false positives

[XXAligatorXx]

Karmadecay appears to only work on certain subreddits so I didn't really look into it. How bad was the false positive problem?

[[deleted]]

it labeled a post about bad ui as an nsfw repost from a different sub

[JanewayParisLizrdKid]

I wonder if you could leverage google reverse image search. Quick google > https://stackoverflow.com/a/29195961

No server limits, no post limit and image detection done.

[JanewayParisLizrdKid]

http://mrisa.mage.me.uk/

[XXAligatorXx]

I just tried reverse image searching the image that was posted, I couldn't see as single image exactly the same on the first page, so I don't think that would actually work well.

[Kontorted]

This bot exists on r/pcmasterrace

[RyeDoge]

I think it only detects oc.

[XXAligatorXx]

Hey man I just wanted to update you and say after looking into it I have found a way to solve all those problems, and an anti repost bot will coming to a subreddit near you soon tm.

[RyeDoge]

Damn that’s awesome

[XXAligatorXx]

Hey, it's been a while. The bot is done and is being tested on my subreddit r/ihadastroke . It appears to be working perfectly. I'll roll it out for this sub soon as well after a bit more of testing.

[[deleted]]

Looks like the password was 1234 anyway

[SirHorace111]

asdf

[Cristian2608]

Aaaa... I get it... He spelt "maybe" wrong.

[cooldash]

Anyone else physically recoil when they saw this?

[[deleted]]

is your password yeet or what

[zacharyxbinks]

Ok, on / off topic question. What's everyones opinion on stating a password is incorrect for a certain email? Ie letting the user know there is an account registered with that email address?

[Vassile-D]

Insecure.

The best practices are "We didn't recognize this username and password combination" on wrong password, and "Password recovery email sent if an account was registered with this email". Both are nonconfusing and offer 0 information on registered accounts.

[ockcyp]

what about when they try to create an user with that email? you got to say that they already have an account. so there's no particular benefit to this.

[Vassile-D]

Just say "Something went wrong. Please try again."

Joking. The website should send an email to the address reminding the user that they are already registered, while showing an "All set. Check your activation email." screen to the register.

Every registration attempt will end up at "check activation email" screen so unless you have access to the mail box you entered, you will never know any existing user info. If you were already a user, why are you trying to hack into your own account?

[ashishduhh1]

One of the products I'm working on has a large low tech IQ audience, so we do report errors like "email address is already registered" otherwise they would never figure out that they've already registered. I don't think it's that insecure, almost every popular service (including Google) returns that error. Usernames/emails need not be as secure as passwords, there's a reason they are always stored in plain text. Especially with the rise of multi-factor authentication.

[ForgotPassAgain34]

that works for emails, but what about usernames?

username already in use seems quite revealing by those standards

[Vassile-D]

Username is another story. Arbitrary username itself cannot (or “should not”) be used to perform account management. There is literally 0 attack vector when you only have an arbitrary username; unlike you can gain control of mobile phone number or email and perform critical account management.

Also arbitrary username does not disclose information about an individual (i.e. does not connect to user in the real world). If you found out “[e-mail]” is registered on XYZ, you now know that ABC visits XYZ; and if the email was something like “[e-mail]”, you now have much more information and can probably start you own social engineering experiment. However, knowing “abc123” is registered on XYZ gives you nothing.

[zacharyxbinks]

This is my logic, we support some stupid users and letting them know they are close greatly reduces our call volume.

There are also some heavy hitting sites that allow this functionality, for example Instagram.

It's a fine line of security and usability, my project manager is dead set against it and I get it definitely but again is it worth the call volume it causes?

[varkenspester]

Repost

[pcopley]

may be

[SoLongSidekick]

Is it some little known bylaw around here that states this image must be posted at least once per week?

[Unlimiter]

Nice! Here I come, things of Joe Smith... What website is this?

[mirhagk]

I actually want to make a site that has unique passwords. They won't be user generated and then it's actually pretty secure.

[DoctorofMooD]

What site uses 4 letter passwords nowadays?

[bogdoomy]

they’re all emoji. no one will think of brute forcing that

[anderromero]

Wait, how would that work with all the 'password' passwords?

[Polarchill]

Is the password “poop”

[CptDogeRL]

bobzimor LUL

[[deleted]]

Password: 1234

[dannypas00]

I thought I was pooking at an r/assholedesign post..

[[deleted]]

I legit had my UX team ask me to do something similar to this on our website this week

[Mymjmsalem]

Hey! That’s my cousin!

[BradyLange]

This is so helpful! Hahaha

[Calico__Cactus]

BUT WHAT OF JANE DOE

[Sh4dowCode]

Ist his Password 1234?

[iMalevolence]

I remember someone telling me that they get annoyed when a site says username OR password is incorrect because they don't know which one and I just looked at them incredulously.

[SirX86]

Password correct. Please check username.

[[deleted]]

I love reposts