I am trying to create a simple C++ brute forcing program to crack small passwords-maybe like 3-4 characters long, (as a science fair project) just to show people how it works, i.e. my topic is mainly about cyber security and data breach vulnerability and stuff.
So I got the brute forcing part covered, but what I want to change is that instead of asking users to enter their password within my program itself, I was wondering if it was possible to make a, say, an HTML page with a login screen, and the entered password is then saved to a txt file which I can then open from my program for the brute forcing part.
What I am trying to say is that most people trying this out wont be so convinced entering passwords into an output box. They might wonder if I had just printed out the password they entered. I saw other people's programs but all they did was cin>>password and then started the brute forcing part. The user does not know if his password was cracked or the programmer just did cout<< password.
So it would help me a lot by letting me know of methods in which I can achieve this(not just with HTML, anything is fine, as long as its not an output box).
Sorry for the long question! Just wanted to make sure I covered all the info.
Please help me!!!
P.S: I'm just a student (1 and a half years into C++ :)), so please try to keep it as simple as you can. Thanks in advance!!
I would simply print out as much internal information in the terminal/outputbox as possible. This way, people get a better understanding of the inner workings of your program. For example, you could print out every password that your program tried. On top of that, show your sourcecode to the people who are also interested in that.
Related
I'm writing web frontend for my go program that represents user input as ascii art characters. Something like this.
It makes sense for me to keep server and program that converts user input to ascii art representation in different .go files. I want to call my program from server.go, after I've taken FormValues from user. How can I accomplish this? I've already spent considerable time doing my research and cannot really find anything about it. I'm certain that this is possible.
Also how should I go about displaying my program output at webpage I've created? At the moment my program will store output inside []string and uses for loop to print out lines. It's easy for me to change output data type if that is required. Just looking for some insight to accomplish this in a smart way and not use something like fmt.Fprint() to display result.
Hope that my questions are clear and understandable. I've only been learning programming for weeks and feel like I'm missing an link from a chain at the moment.
I made a website for a free summer camp program (nothing fancy im barely 20 and only know python and C++ so i used weebly). I made an online form asking for info such as campers t-shirt size and name, and when the user fills that out, weebly sends me an email containing all of their answers.
The issue is, that will require BARE MINIMUM, for me to manually type hundreds of answers into some C++ program that could sort these people and put them in the right age groups. My question is, is there any way to get the contents of my email, or set up an email that automatically puts everything it receives into a database?
Im still inexperienced so if someone knows of a BETTER way to do this or something I am all ears. This is non-profit so really just trying to save time and manpower, i have a little budget for something such as a hosting fees or anything like that, but solutions like learning SQL arent really workable. I have looked at many services online but things such as sign up genius don't support this kind of camp style (you can choose multiple camps from a pool and when a pool reaches 50 we cannot accept more in that pool) weebly supports html embedding if that helps.
Thank you in advanced!
I would like to ask if it's possible for people to view code I can see in Microsoft debugger.
I'm probably just being paranoid, but can other people see my code using their debugger?
I can't see the password and login when I just enter view code, but I can in debugger. I'm pretty sure that I'm safe, but I cant afford to make a mistake.
In this case I Advice you for limit your client side codes and depend more on server side, Special for the valued algorithms and new ideas.
Php is a good simple way but if you want more security,
better to mix server side codes with ASP C# or java to have the ability of encryption, encoding, secured textString and ... cts.
Obfuscation could be another good option for you if you have client-side code you don't want easily viewed by others.
On the part where you can see login credentials: I believe you'll want to look into storing passwords as Salted Hashes. There are many other ways to ensure passwords stay confidential.
These are certainly not plug and play solutions by any means and I'd highly recommend doing your own research on these topics before doing so.
I hate writing error condition code. I guess I don't have a good approach to doing it:
Do you write all of your 'functional'
code first then go back in and add
error handling or vice versa?
How stupid do you assume your users
are?
How granular do you make your
exception throws?
Does anyone have sage advice to pass on to make this easier?
A lot of great answers guys, thank you. I had actually gotten more answers about dealing with the user than I thought. I'm actually more interested in error handling on the back end, dealing with database connection failures and potential effects on the front end, etc. Keep them coming!
I can answer one question: You don't need to assume your users are "stupid", you need to help them to use your application. Show nice prompts for things, validate data and explain why, so it's obvious to them, don't crash in their face if you can't handle what they've done (or more specifically, what you've let them do), show a nice page explaining what they can do instead, and so on.
Treat them with respect, and don't assume they know everything about your system, you are here to help them.
In respect to the first part; I generally write most error-handling at the time, and add a little bit back in later.
I generally don't throw that many exceptions.
Assume your users don't know anything and will break your system any way that it can possibly be broken.
Then write your error handling code accordingly.
First, and foremost, be clear to the user on what you expect. Second, test the input to verify it contains data within the boundaries you expect.
Prime example, I had a form with an email field. We weren't immediately using that data so we didn't put any checking on it. Result: about 1% of the users put in their home address. The field was labeled "Email Address" Apparently the users were just reading the second word and ignoring the first.
The fix was to change the label to simply say "Email" and then test the input. For kicks we went ahead and logged what the users were initially typing in that field just to see if the label change helped. It did.
Also, as a general practice, your functions should test the inputs to verify they contain the data you expect. Use asserts or their equivalent in your language of choice.
When i code, there will be some exceptions which i will expect, i.e. a file may be missing, or some xml serialisation may fail. Those exceptions i know will happen ahead of time, and i can put in handling for them.
There is a lot you cannot anticipate though, and nor should you try to. Put in a global error handler and logger, so that ultimately everything gets caught and logged. Then as your testers and/or users find situations that cause exceptions (i.e. bad input) then you can decide whether you want to put further handling in specifically for it, or maybe leave it as it was.
Summary: validate your input, but don't try to gaze into the crystal ball too much, as you will never anticipate every issue that the user may come up with. Have a global handler and logger, and then refine as necessary.
I have two words for you: Defensive Coding
You have to assume your users are incredibly stupid. Someone will always find a way to give you input that you thought would never happen.
I try to make my exception throws as granular as possible to provide the best feedback when something goes wrong. If you lump everything together, you can't tell which error case caused the problem.
I usually try to handle error cases first (before getting functional code), but that's not necessarily a best practice.
Someone has already mentioned defensive programming. A few thoughts from a user experience perspective, though.
If the user's input is invalid, either (a) correct it if you're reasonably sure you knew what they meant or (b) display a message in line that tells them what corrective action they should take.
Avoid messages like, "FATAL SYSTEM ERROR CODE 02382981." Users (a) don't know what this means, even if you do, and (b) are intimidated and put off by seeing things like this.
Avoid pop-up messages for every—freaking—possible—error you can come up with. You shouldn't disrupt user flow unless you absolutely need them to resolve a problem before they can do anything else.
Log, log, log. When you show an error message to the user, put relevant information that might help you debug in either (a) a log file or (b) a database, depending on the type of application you're creating. This will ease the effort of hunting down information about the error without making the user cry.
Once you identify what your users should and should not be able to do, you'll be able to effectively write error handling code. You can make this easier on yourself with helper methods/classes.
In terms of your question about writing handling before/after/during business logic, think about it this way: if you're making 400,000 sandwiches, it might be faster to add all the mustard at the same time, but it's probably also a lot more boring than making each sandwich individually. Who knows, though, maybe you really like the smell of mustard...
My organization has a form to allow users to update their email address with us.
It's suggested that we have two input boxes for email: the second as an email confirmation.
I always copy/paste my email address when faced with the confirmation.
I'm assuming most of our users are not so savvy.
Regardless, is this considered a good practice?
I can't stand it personally, but I also realize it probably isn't meant for me.
If someone screws up their email, they can't login, and they must call to sort things out.
I've seen plenty of people type their email address wrong and I've also looked through user databases full of invalid email address.
The way I see it you've got two options. Use a second box to confirm the input, or send an authentication/activation email.
Both are annoyances so you get to choose which you think will annoy your users less.
Most would argue that having to find an email and click on a link is more annoying, but it avoids the copy/paste a bad address issue, and it allows you to do things like delete or roll back users if they don't activate after say 48 hours.
I would just use one input box. The "Confirm" input is a remnant form the "Confirm Password" method.
With passwords, this is useful because they are usually typed as little circles. So, you can't just look at it to make sure that you typed it correctly.
With a regular text box, you can visually check your input. So, there is no need for a confirmation input box.
I agree with you in that it is quite an annoyance to me (I also copy and paste my address into the second input).
That being said, for less savvy users, it is probably a good idea. Watching my mother type is affirmation that many users do not look at the screen when they type (when she's using her laptop she resembles Linus from Peanuts when he's playing the piano). If it's important for you to have the user's correct email address then I would say having a confirmation input is a very good idea (one of these days I'll probably type my email address wrong in the first box and paste it wrong into the second box and then feel like a complete idiot).
While the more tech-savvy people tend to copy and paste, not technical people find it just as annoying to have to type something twice. During a lot of user testing I've down, the less tech-savvy - the more annoyed they seem with something like this... They struggle to type as it is, when they see they have to type their email in again it's usually greeted with a strong sign.
I would suggested a few things.
Next to the input box write the style of the information you are looking for so something like (i.e. user#domain.com). The reason this is important is you would be surprised how many of the less tech-savvy don't really understand the different between a website and an email address, so let them know visually the format you want.
Run strong formatting test in real time, and visually show a user that the format is good or bad. A green check box if everything is okay comes to mind.
Lastly, depending on your system architecture I often use a library to actually wrong a domain in the background. I don't necessarily try to run a VRFY on the server - I often use a library to check to make sure the domain they entered has MX records in it's DNS record.
I agree with Justin, while most technical folks will use the copy, paste method, for the less savvy users it is a good practice.
One more thing that I would add is that the second field should have the auto-complete feature disabled. This ensures that there is human input from either method on at least one of the fields.
Typing things twice is frustrating and doesn't prevent copy&paste errors or even some typos.
I would use an authenticate/activate schema with a roll back to the old address if the activation is not met within 48 hours or if the email bounces.
As long as a field is viewable, you do not need a confirm box. As long as you do some form validation to be sure that it is at least in valid format for an email address let the user manage the rest of the issues.
I'd say that this is ok but should only be reserved for forms where the email is essential. If you mistype your email for your flight booking then you have severed the two-way link between yourself and the other party and risk not getting the confirmation number, here on StackOverflow it would only mean your Gravatar would not be loaded ...
I'd consider myself fairly techie but I always fill in both fields /wo cut-paste if I regard it to be important enough.
I tend to have it send a verification code to the email address specified (and only ask for it once), and not change the email address until the user has entered the code I sent them.
This has the advantage that if they try to set it to a dozen different addresses in quick succession, you'll know which ones work by which verification code they put in.
Plus, if I am presented with a "confirm email address" box, I just copy and paste from the previous one, and if I'm guilty of that, I'm sure that other less careful users will do the same.