Jump to content

Search the Community

Showing results for tags 'password'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Software & Hardware Discussions
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • OpenG
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help

Categories

  • *Uncertified*
  • LabVIEW Tools Network Certified
  • LabVIEW API
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
  • LabVIEW IDE
    • Custom Probes
  • LabVIEW OOP
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Company Website


Twitter Name


LinkedIn Profile


Facebook Page


Location


Interests

Found 3 results

  1. Hi, I would like to implement a Run-time license checking mechanism that will enable or disable some parts of my LabVIEW API depending on a license status. After reading numerous discussions here on the forum (We need a new password cracker :( , Low level VI data editor (warning: not for production use!) , I found some more hidden INI keys, Password Security in LabVIEW) I realised few things: - reverse engineering in a LabVIEW-related field seems to be a doable task for some smart people, - password protection on block diagrams does not protect your IP, it is more of a "read-only" or a "private property" sign, - removing block diagrams or compiling it into an executable are the ways to go, and finally, - there are few tools out there, that seem to have a potential to "unflatten" VI data and modify/extract its data even without block diagrams. Back to my task. I decided to remove block diagrams. Inside my protected VI I call an external library that does the actual license checking. So the code only gets this status and returns it back to other VIs. Then the VIs do not perform their main functions, and the user gets an error. Do you think I am safe here? Is it possible to extract sensitive string information out of my VIs (without BD)? Is there a way to change wiring rules/connector pane on my VIs? Should I worry about DLL hijacking? Does NI have some kind of a tutorial for protecting your run-time API? How do you protect your API knowing all that? Do you sleep well? Thanks
  2. I am trying to connect a PostgreSQL database (ver 9.6) with LabVIEW (2016) on Windows 10. I followed the following tutorial: https://decibel.ni.com/content/docs/DOC-30308 Without access to a cRIO, I have followed the steps to create the database, table and block diagram. Please see block diagram attached.The system exec.vi calls the psql.exe with SELECT command using database "lisam" and database user "postgres". When I execute the same code I am asked for the password for user postgres. When I type in the password, the box closes and reopens. This continues in a loop until I press abort. I get no errors and when I write the same script into the cmd - the password is accepted and the table is displayed, see attachment. PROBLEM: Password request from the psql.exe file when executing LabVIEW code Type password, psql.exe closes and opens again SELECT query works without while loop (password accepted once) but insert and clear does not without the loop condition What I've tried... Created a pgpass.conf file in a postgresql folder in %AppData% in the following format:- hostname:port:database:username:password, where lisam is the database, postgres is the user. Host name as localhost '127.0.0.1' - password still requested. 127.0.0.1:5432:lisam:postgres:password Host name as 'localhost' - psql.exe flashes continously and LabVIEW crashes. localhost:5432:database:username:password Host name as database client address '::1' - password loop with the psql.exe. ::1:5432:database:username:password Host name to '*' - *:5432:lisam:postgres:password Able to: Access the database through the cmd WITHOUT password C:/Program Files/PostgreSQL/9.6/bin/psql -c "SELECT * FROM demo1" lisam postgres Problems: Execution in Labview - psql.exe flashes continuously and the program crashes. Accessing database through psql.exe directly - password requested and ERROR received "psql: FATAL: password authentication failed for user C:\Program Files" 2.Changed the authentication method in pg_hba.conf to trust for: localhost (127.0.0.1)- a password is still requested. 127.0.0.1 AND ::1 - Can access the database on psql without a password, but the psql.exe LabVIEW completely crashes. I tried adding the host and port to the code C:/Program Files/PostgreSQL/9.6/bin/psql -c "%s" -h 127.0.0.1 -p 5432 lisam postgres And the psql.exe flashes continously and won't abort. The password is called at the system exec VI in the cmd. Tried concatenating the password (as a control) with space constant to the command line string inbetween the format into string and the system exec VI. But the password is given before it is called. In summary I am able to use .pgpass.conf to authenticate the password when using the cmd, but not in LabVIEW. Does anyone know a way around this? Or another way to define the password at the system exec VI? Your help is greatly needed. Lisa Info: database name: lisam database user: postgres IPv4 local connections- host all all 127.0.0.1/32 md5 IPv6 local connections- host all all ::1/128 md5 DB:lisam Client Address ::1 psql Client address 127.0.0.1
  3. On Stackoverflow someone posted a question on how to recover a VI's password To my surprise there was a thorough answer containing two methods: Look up the stored MD5 hash in a VI file I can understand this, and am not really concerned, this might be a valid method if you know a password is from a given list (choosing a password from a dictionary is dumb anyway). Modify the LabVIEW executable binary to ignore the password checking. I have not tried this on LabVIEW 2011, but if this works it basically means that passwords are just a sign that says 'Do not trespass' Can anyone verify the LabVIEW edit function in 2011. On a more general discussion, does this troubles you anyway? Ton
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.